Кросспостинг, оригинальная публикация OSFP, будучи link-state протоколом, исключает петли в топологии за счёт  построения дерева кратчайшего пути в рамках одной зоны с помощью  алгоритма Дейкстры. Однако поведение OSPF между зонами напоминает скорее  поведение distance-vector протоколов, которые обмениваются всего лишь  префиксами и соответствующими метриками без каких-либо данных о  фактической топологии; по этой причине некоторые авторы могут называть  OSPF гибридным протоколом маршрутизации. Механизм защиты от петель  маршрутизации между зонами, однако, довольно прост: все зоны должны  обмениваться маршрутной информацией через backbone зону, зону 0, прямой  обмен маршрутами между зонами невозможен. Впрочем, тёмный гений изобрёл инструмент  разрушения стройной идеи OSPF – речь о функции OSPF Virtual Link (VL).  Даже маленькие инженеры знают, что использовать VL – плохая затея; все  согласны с тем, что VL оправдан только в крайних случаях для временного и  быстрого исправления критичной ситуации. Однако обнаружить подробное  объяснение, чем же именно VL так плох помимо дополнительного уровня  сложности, оказалось не так-то просто. Сложность инженерам не помеха,  поэтому давайте поищем более весомые аргументы против VL. Нет ничего лучше чашки кофе с утра,  рабочей лабы и широкополосного доступа к google.com. Для эмуляции  топологии в GNS3 были использованы образы Cisco 7200: На каждом маршрутизаторе в  соответствующей зоне настроен виртуальный интерфейс (loopback0) для  назначения OSPF RID и других инфраструктурных задач; loopback на ABR  находятся в зоне 0. Схема адресации: 192.168.xy.x|y/24 для соединения Rx  и Ry (например, 192.168.12.1 на интерфейсе f0/1 R1). Помимо штатной  настройки OSPF, между R1 и R3 создан VL. Если у читателя много свободного  времени, можно убедиться в доступности всех префиксов из любой точки  сети; я же сконцентрируюсь на связности R1 и R5: Трафик следует по кратчайшему маршруту, как и задумывалось. Перейдем к гвоздю сегодняшней программы: Transit area capability – это способность OSPFv2 выбрать более  оптимальный маршрут для трафика, следующего по VL. Идея довольно проста:  необходимо взять префикс, доступный через VL, и сравнить его с  имеющимися LSA3; если найдено полное совпадение и маршрут через LSA3  оптимальнее, то следует использовать оптимальный маршрут. OSPFv1 не обладал такой функцией, и весь трафик следовал по тому же пути, что и  VL. Если читатель хочет глубже погрузиться в данную тему, могу порекомендовать статью Петра Лапухова. А мы продолжаем: Изменения есть, но они некритичны: теперь R1 выбирает путь вдоль VL в  полном соответствии с поведением OSPFv1 без transit capability. Где же обещанная петля? Добавим нашей топологии некоторой пикантности: Ухудшили плохой маршрут, и что с того? Дамы и господа, это – петля. Теперь взглянем на проделанную работу: VL между R1-R3; Transit capability отключена; Метрика R2-R3 увеличена. Последний пункт стоит отметить особо: в результате изменения метрики R1 является next-hop для 5.5.5.5/32 с точки зрения R2: Выбор маршрута R2 выглядит довольно естественно; выбор R1 же может показаться странным на первый взгляд: Однако такое поведение вполне соответствует правилам выбора маршрута в OSPFv1: 5.5.5.5/32 доступен через VL в зоне 0; трафик следует по тому же пути, что и VL. R2 ничего не знает ни про VL, ни про  transit area; он всего ли маршрутизирует пакеты согласно таблице  маршрутизации, построенной на основе LSA3. На данном этапе может показаться, что  причина всех бед – transit capability, а не VL. Впрочем, разрешается  этот вопрос довольно просто: подобная проблема была обнаружена в OSPFv1 и  решена в OSPFv2 посредством transit area. Читатель может заметить, что  описанное поведение родственно по природе микропетлям, возникающим в  ходе перестроения дерева, и с ним трудно не согласиться. Впрочем,  разница есть и существенная: микропетли представляют собой переходное  состояние, тогда как петли из-за VL в OSPFv1 носили постоянный характер. Немного английского оригинала из OSPFv2 RFC про отличия от OSPFv1: “When summarizing information into a virtual link's transit area,  version 2 of the OSPF specification prohibits the collapsing of multiple  backbone IP networks/subnets into a single summary link.” Section F.2.3, RFC 1247 Проблема, завуалированная авторами RFC в  этой фразе, очень похожа по характеру на рассматриваемую в статье. Если  бы маршруты зоны 0 можно было бы суммаризовать на ABR, то полученный  префикс в LSA3 не смог бы быть использован маршрутизатором с VL.  Передача трафика была бы нарушена вследствие разного представления о  топологии маршрутизаторами зоны: Маршрутизатор с VL выбрал бы маршрут из зоны 0; из-за отсутствия точно совпадающего LSA3 был бы выбран путь вдоль VL; Остальные же маршрутизаторы использовали бы суммарный маршрут из LSA3. В нашем случае, если бы R3 суммаризовал маршрут до 5.5.5.0/24, то R2 выбрал бы более точный маршрут 5.5.5.0/25 через R4, что привело бы к петле маршрутизации. Решение? Нужно  обеспечить всем маршрутизаторам зоны равный доступ к маршрутной информации из зоны 0, запретив изменение последней, т.е. суммаризацию. Стоит отметить, что это не относится к маршрутам из других зон, поскольку эти суммарные маршруты будут одинаковы как в зоне 0, так и других зонах; только ABR зоны-источника могут суммаризовать информацию о  топологии из LSA1/2 в простой LSA3. Более того, запрещена только суммаризация префиксов из зоны 0, фильтрация же не ограничена. Последняя  не изменяет сам префикс; в результате у маршрутизаторов зоны будет меньше пар LSA1-LSA3 для выбора более оптимального маршрута, что не может привести к описанной в статье проблеме. Вывод: некоторые малоизвестные настройки по умолчанию лучше не трогать. P.S. Существует не менее интересный способ выстрелить себе в ногу. Помогали редактировать статью: Анастасия Куралёва, Максим Климанов.  Системный инженер