Общеизвестно, что существуют несколько версий протокола OSPF. Однако не только лишь все знают о том, что для OSPFv2 есть несколько вариантов RFC; подавляющая часть реализаций OSPF соответствуют RFC 1583 или RFC 2328. Пикантность ситуации в том, что эти RFC несовместимы между собой, о чём говорит и показывает вендор-которого-нельзя-называть. Ну и зачем же тогда IETF заморочилось созданием второго стандарта? Ответ прост: RFC 1583 содержит архитектурные недостатки, которые могут привести к образованию в сети петель маршрутизации. Одно из наиболее ярких отличий между стандартами – вычисление метрики суммарного маршрута на ABR. When the range's status indicates Advertise, a Type 3 advertisement is generated with Link State ID equal to the range's address (if necessary, the Link State ID can also have one or more of the range's "host" bits set; see Appendix F for details) and cost equal to the smallest cost of any of the component networks. Вольный перевод: Если агрегированный префикс подлежит анонсу, необходимо создать LSA3, Link State ID которого равен анонсируемому маршруту (…), а вес – наименьшему весу из входящих в него префиксов. RFC 1583, раздел 12.4.3 When the range's status indicates Advertise, a Type 3 summary-LSA is generated with Link State ID equal to the range's address (if necessary, the Link State ID can also have one or more of the range's "host" bits set; see Appendix E for details) and cost equal to the largest cost of any of the component networks. Вольный перевод: Если агрегированный префикс подлежит анонсу, необходимо создать LSA3, Link State ID которого равен анонсируемому маршруту (…), а вес – наибольшему весу из входящих в него префиксов. RFC 2328, раздел 12.4.3 Долгое время это изменение казалось мне бессмысленным, что сделали именно так, потому что гладиолус. Однако раздел RFC 2178 весьма доходчиво описывает, где именно собака зарыта: There are two manifestations of this problem. The first, discovered by DennisFerguson, occurs when an aggregated forwarding address is in use. In this case, the desirability of the forwarding address can change for the worse as a packet crosses an area aggregation boundary on the way to the forwarding address, which in turn can cause the preference of AS-external-LSAs to change, resulting in a routing loop. Вольный перевод: Есть два проявления описанной проблемы. Первое, обнаруженное Дэннисом Фергюсоном, возникает при агрегировании forwarding address, когда предпочтительность маршрута до forwarding address ухудшается при пересечении границы зоны, что в свою очередь может изменить приоритет LSA5, в конечном счёте приводя к петле маршрутизации. Если буйная фантазия после прочтения этого объяснения выдала BSOD – добро пожаловать в клуб. Впрочем, показательный сценарий придумать действительно несложно. Зоны 1 и 2 включают в себя в том числе и внешние интерфейсы ASBR, чтобы заполнить поле Forwarding Address в LSA5. ABR суммаризуют внешние префиксы, соответствующие этим интерфейсам, при передаче в зону 0. Освежим в памяти алгоритм выбора лучшего внешнего маршрута по версии RFC 1583: внутренние маршруты лучше внешних; Тип-1 (E1) лучше Типа-2 (E2); меньшая метрика имеет больший приоритет; только для E2: наименьшая метрика до Forwarding Address побеждает. Относящиеся к делу настройки маршрутизаторов: Проверим, что у R1 есть связность до R6: Оба внешних маршрута имеют тип E2, так что R1 выбирает лучший из них на основе веса маршрута до Forwarding Address: Добавим на ASBR2 сущий пустяк – интерфейс loopback с адресом из диапазона 10.2.0.0/16: И уезжаем пить пиво на дачу вечером пятницы: Упс, SLA для связности в сети начал неумолимо тикать. А виной всему… Заглянем в мозги R1: Очевидно, что R1 поменял своё мнение касательно лучшего маршрута до 6.6.6.6/32, переключившись с ASBR1 на ASBR2. А что происходит в палате №6 голове ABR2? ABR2 добросовестно сравнивает вес маршрутов до обоих ASBR и решает, что ASBR1 ему нравится больше, отсюда и петля. Самое время включить на ABR2 режим совместимости с RFC 2328 – это позволит назначить суммарному маршруту худшую из входящих префиксов метрику. Таким образом, маршрут до Forwarding Address может только улучшиться по пути пакета, но никогда наоборот. Вуаля – R1 снова использует первый маршрут через ABR1: Лепота ситуации в том, что огромный парк сетевых устройств работает по правилам RFC 1583, включая Cisco IOS, Juniper JunOS, Huawei VRR. Ежу понятно, что это сделано в целях обратной совместимости (более свежие устройства используют RFC 2328 по умолчанию, например, Arista EOS, Cisco NX-OS), однако легкость реализации радикального джихада на своей собственной сети лично меня впечатляет. Впрочем, решение тоже весьма простое: или использовать RFC 2328, или использовать OSPF в максимально простом виде aka KISS: никаких virtual link, NSSA, FA и других CCIE-примочек. Спасибо за обратную связь: Куралёвой Анастасии  Системный инженер