обнаружение цикла перераспределения IOS XE и XR
-
Как мы знаем, при взаимном перераспределении с двумя или более маршрутизаторами возникнет петля, если мы не будем использовать тег на одном маршрутизаторе перераспределения и блокировать обратное изучение маршрута на другом. Однако даже без настройки тегов и блокировки IOS XE и XR могут каким-то образом автоматически обнаруживать петлю и не учиться обратно маршруту на другом маршрутизаторе? Я осуществлял перераспределение между ISIS и OSPF. Один маршрутизатор, осуществляющий перераспределение, учит маршрут, исходящий из ISIS, через OSPF, но другой учит через ISIS, и я вижу, что его OSPF RIB не учит перераспределенный маршрут. Было ли обновление поведения цикла перераспределения IOS XE и XR?
-
Здравствуйте, Существует зависимость как от используемых протоколов маршрутизации, будь то маршрутизация на основе PE-CE / VRF или чистый IP, так и от топологии уровня 3, поэтому для полного описания всего этого потребуется написать немало страниц. Исходя из вашего описания сценария, моя логика того, что происходит, не связана с какими-либо изменениями в поведении цикла (я даже не знаю о таких, скажем, новых функциях, поскольку протоколы не изменились в этой области), а скорее с ожидаемым поведением: 1. Изначально, до начала любого перераспределения, оба маршрутизатора A и B предпочитают маршрутизировать через ISIS для префиксов, объявленных в домене ISIS, и через OSPF для префиксов, объявленных в домене OSPF. 2. В какой-то момент вы сначала выполняете взаимное перераспределение между ISIS и OSPF, скажем, на маршрутизаторе A. Для маршрутизатора A предпочтения маршрутизации не изменяются, он по-прежнему маршрутизирует через ISIS для префиксов ISIS и через OSPF для префиксов OSPF. Однако на маршрутизаторе B происходит изменение; теперь маршрутизатор B получает префиксы ISIS как через ISIS, так и через OSPF, поэтому на маршрутизаторе B и ISIS, и OSPF отправляют в RIB одни и те же префиксы (происходящие из домена ISIS), и RIB будет предпочитать путь OSPF из-за более низкого AD, поэтому вы увидите, что все префиксы домена ISIS маршрутизируются через OSPF в RIB; кроме того, маршрутизатор B получает префиксы OSPF как через ISIS, так и через OSPF, поэтому на маршрутизаторе B как ISIS, так и OSPF отправляют в RIB одни и те же префиксы (происходящие из домена OSPF), и RIB будет предпочитать путь OSPF из-за более низкого AD, поэтому вы увидите все префиксы домена OSPF, маршрутизируемые через OSPF в RIB; конечным результатом будет то, что маршрутизатор B больше не будет иметь никаких записей ISIS в RIB, а только записи OSPF. 3. Когда вы теперь выполните взаимное перераспределение и на маршрутизаторе B, маршрутизатор B не будет перераспределять никаких префиксов ISIS в OSPF (только префиксы, присоединенные к подключенным каналам, обращенным к домену ISIS), поскольку маршрутизатор B не имеет записей ISIS в RIB, поэтому вы не увидите никаких перераспределенных префиксов ISIS / LSA типа 5 (предполагая, что это не область NSSA) в OSPF LSDB, вы увидите только соединенные ссылки ISIS как LSA типа 5 в OSPF LSDB. Маршрутизатор B, поскольку он имеет только записи OSPF в RIB, будет перераспределять все эти записи в ISIS, поэтому вы должны увидеть оба префикса домена OSPF, перераспределенные в ISIS маршрутизатором B. Если мое объяснение недостаточно ясно, дайте мне знать, в чем именно. Было бы также полезно, если бы вы могли предоставить логическую схему уровня 3, а также, возможно, более четкое объяснение того, что, по вашему мнению, должно произойти, но не происходит. Спасибо, Кристиан.
-
Здравствуйте.
Интересно, происходит ли перераспределение из XR rtr — создали ли вы для этого какую-либо политику RPL? Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол -
не создана карта маршрута или политика маршрута.
-
Здравствуйте,
просто хочу уточнить, у вас есть двойные точки выхода для перераспределения границ?
Если да, то я не знаю ни одной встроенной функции предотвращения циклического перераспределения на IOS/XR, которая бы
исключала обратную передачу маршрутов. Ее нужно применять вручную, возможно, другие читатели этого поста знают о ней. Что касается языка политики маршрутизации XR (RPL), он необходим, особенно для BGP, даже для рекламирования/получения маршрутов. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол -
Да, два маршрутизатора перераспределения. Но, как сказал Джузеппе, OSPF, похоже, способен подавлять LSA типа 5 с петлей. Я пытаюсь выяснить, есть ли у ISIS и BGP аналогичный механизм. PS: политика маршрутизации необходима только для EBGP.
-
Здравствуйте,
@daniel ng
, >> Я осуществлял перераспределение между ISIS и OSPF. Один маршрутизатор, осуществляющий перераспределение, узнает маршрут, созданный ISIS, через OSPF, а другой — через ISIS, и я вижу, что его OSPF RIB не узнал перераспределенный маршрут. OSPF имеет проверку работоспособности для LSA типа 5: если адрес пересылки, присутствующий в LSA типа 5, известен через другой внешний маршрут, текущий LSA типа 5 игнорируется и не устанавливается в таблицу маршрутизации IP. Поэтому я бы предложил проверить поля LSA типа 5. Надеюсь, это поможет Джузеппе -
Итак, OSPF имеет встроенный механизм предотвращения петли, но как обстоят дела с ISIS и BGP?
-
]
Объяснение уровня «бог». tldr: 1. Маршрутизатор A перераспределяет префикс, созданный ISIS, в OSPF. 2. Маршрутизатор B узнает этот префикс через OSPF и заменяет тот же префикс, который он узнал из ISIS. 3. Маршрутизатор B больше не имеет этого префикса как ISIS в своем RIB, поэтому он не может перераспределить его в OSPF. 4. Маршрутизатор A не может узнать этот префикс через OSPF. ![Untitled.png] Поэтому, похоже, это не связано с проверкой работоспособности или чем-то подобным.
-
Здравствуйте, Верно. В области протоколов маршрутизации не появилось ничего нового, связанного с предотвращением циклов (новые атрибуты/флаги, специфичные для протокола, или новые функции). То, что вы видите в топологии, является ожидаемым поведением, обусловленным порядком операций. Однако, несмотря на то, что обратная связь по маршруту сама по себе нарушается встроенными функциями IS-IS и OSPF, вам необходимо учитывать условия гонки, когда каналы связи нестабильны и могут возникать временные/переходные петли, которых вы не хотите; по этой причине вы должны всегда предотвращать обратную связь маршрутов, используя тегирование маршрутов в точках перераспределения (лучший вариант), и неявно контролировать желаемые маршруты, которые будут использоваться, или, иными словами, неоптимальную маршрутизацию, что означает, что вы всегда хотите, чтобы маршрутизатор, выполняющий взаимное перераспределение, маршрутизировал через соединения OSPF для префиксов OSPF и через соединения ISIS для префиксов ISIS (что в вашем случае не происходит, поскольку вы не реализовали решение с ручной обратной связью маршрутов). Спасибо, Кристиан.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти