Кратко

  • Обычно BGP считает локальный ASN в AS_PATH доказательством петли. allowas-in меняет решение получателя, а as-override меняет путь до принятия решения.
  • Оба механизма применимы для площадок с общей ASN, но не аутентифицируют префикс и не доказывают пересылку. Route Target, Site of Origin и авторизация решают разные задачи.
  • Проверяемое исключение сохраняет путь до и после изменения, ограничивает соседа, AFI/SAFI и число вхождений, проверяет контроли площадки и префикса и следует до Loc-RIB, FIB, пакетов и отката.

Правильный отказ

Рассмотрим условную схему, не реальную аварию. Площадки A и B используют один клиентский ASN за сетью провайдера. A объявляет префикс, провайдер доставляет его к B. Маршрутизатор B видит собственный ASN в AS_PATH и отвергает маршрут. Сессия установлена, PE знает маршрут, но площадка им не пользуется.

Это штатная защита. RFC 4271 исключает из Decision Process маршрут с локальным ASN и прямо выводит настройку приёма собственного номера за пределы спецификации. Путь предупреждает: информация уже проходила через этот домен маршрутизации. RFC 4271

Обычно предлагают два решения. Клиент допускает ограниченное число собственных ASN на приёме через allowas-in или allow-own-as. Либо провайдер заменяет вхождения ASN клиента перед объявлением обратно клиенту с помощью as-override.

Это не взаимозаменяемые ручки. Первый вариант сохраняет путь, но меняет вердикт получателя. Второй меняет доказательство, чтобы стандартный запрет не сработал. В одном случае исключением распоряжается клиент, в другом провайдер принимает на хранение историю пути.

AS_PATH — доказательство, а не подпись

AS_PATH помогает обнаруживать петли и выбирать маршрут, но не подписывает физическую трассу. RFC 4272 отмечает, что speaker прежде всего проверяет собственный ASN, а не каждую заявленную передачу; ложный или укороченный путь способен изменить выбор и допустить петлю. Ценность такого свидетельства требует сохранять его до изменения. RFC 4272

allowas-in меняет приём. Реализация может ограничивать число вхождений, соседа, группу, семейство адресов, origin или route-map. FRRouting документирует несколько вариантов. RFC 7938 описывает широко доступную, но нестандартизованную функцию в Clos с повторно используемыми частными ASN. Безопасность относится к конкретной топологии и не задаёт универсальное число. Документация BGP FRRouting, RFC 7938

as-override меняет отправку. FRRouting и Junos документируют замену вхождений, совпадающих с peer ASN, локальным ASN провайдера. Junos также указывает, что повторения от клиентского prepend заменяются. Длина может остаться похожей, но идентичность, объяснявшая позиции, исчезнет. Документация BGP FRRouting, Junos as-override

Поэтому снимок после изменения слаб. Нужно сохранить исходное объявление CE, приём PE, предполагаемый экспорт до мутации, фактический экспорт и принятую картину удалённого CE. Без цепочки разрешённую замену нельзя отличить от неожиданной потери истории.

Членство, происхождение площадки и право на префикс

В RFC 4364 Route Target определяет, какие VPN-маршруты можно импортировать. Site of Origin отмечает площадку обучения и при корректном применении не позволяет вернуть маршрут CE той же площадки. Авторизация префикса отвечает отдельно: имело ли подключение право объявлять эту сеть. RFC 4364

RT не заменяет потерянный self-AS: он может аккуратно распространить циркулирующий маршрут всем заданным членам. SoO ближе к петле площадки, однако работает только при последовательной установке и проверке на всех нужных подключениях. Он не аутентифицирует клиента или префикс.

Актуальная документация IOS XR предупреждает в описанном L3VPN-процессе, что AS override теряет информацию и может вызвать петли, поэтому применяет SoO как компенсацию. Это свидетельство конкретной схемы, а не гарантия любой сети. Документация Cisco IOS XR BGP

RFC 9835 также моделирует as-override, allow-own-as, максимум вхождений и Site of Origin раздельно. YANG не гарантирует одинаковую семантику продуктов, но подтверждает четыре самостоятельных решения. RFC 9835

Полная цепочка маршрута

Сначала фиксируется строгий режим: Adj-RIB-Out A, Adj-RIB-In PE, путь удалённого PE до экспорта и rejected-route B с причиной self-AS. Для VPN RD и RT записываются как параметры сервиса, но не как доказательство происхождения.

Для исключения на приёме проверяется эффективная политика после наследования: точный сосед, AFI/SAFI, лимит, возможный origin-only, префиксные и route-map условия. Контрольный маршрут вне области должен оставаться отклонённым.

Для переписывания на отправке сравнивается каждый элемент AS_SEQUENCE до и после. Повторный prepend клиента может измениться целиком. Оригинал хранится вне изменяемого маршрутизатора, потому что итоговое объявление не восстановит стёртую идентичность.

Затем отдельно проверяются право на префикс, RT, SoO, параллельные подключения, route reflector и redistribution, способные обойти контроль. RFC 6368 напоминает о недостатках перенумерации и приёма собственного ASN, когда клиент использует BGP и для внутренних задач; эффект не обязательно ограничен PE–CE. RFC 6368

Принять — не значит доставить. Проверяются выбор Loc-RIB, рекурсия, FIB или аппаратная запись и контролируемый трафик в обе стороны. Безопасная проверка отказа должна выявлять повторный вход без создания опасной циркуляции. RFC 7705 показывает при миграции ASN, что изменение истории может пропустить маршрут, который остановил бы self-AS. Это не спецификация as-override, но важное предупреждение против критерия «маршрут появился». RFC 7705

Откат восстанавливает защитное свойство, а не только удаляет команду. Self-AS canary снова отвергается там, где задумано, при этом разрешённая связность, FIB и пакеты возвращаются к проектному состоянию.