<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[обнаружение цикла перераспределения IOS XE и XR]]></title><description><![CDATA[<p dir="auto">Как мы знаем, при взаимном перераспределении с двумя или более маршрутизаторами возникнет петля, если мы не будем использовать тег на одном маршрутизаторе перераспределения и блокировать обратное изучение маршрута на другом. Однако даже без настройки тегов и блокировки IOS XE и XR могут каким-то образом автоматически обнаруживать петлю и не учиться обратно маршруту на другом маршрутизаторе? Я осуществлял перераспределение между ISIS и OSPF. Один маршрутизатор, осуществляющий перераспределение, учит маршрут, исходящий из ISIS, через OSPF, но другой учит через ISIS, и я вижу, что его OSPF RIB не учит перераспределенный маршрут. Было ли обновление поведения цикла перераспределения IOS XE и XR?</p>
]]></description><link>https://sla247.ru/forum/topic/890/обнаружение-цикла-перераспределения-ios-xe-и-xr</link><generator>RSS for Node</generator><lastBuildDate>Fri, 15 May 2026 14:48:04 GMT</lastBuildDate><atom:link href="https://sla247.ru/forum/topic/890.rss" rel="self" type="application/rss+xml"/><pubDate>Fri, 13 Feb 2026 19:57:56 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:58:05 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте, Верно. В области протоколов маршрутизации не появилось ничего нового, связанного с предотвращением циклов (новые атрибуты/флаги, специфичные для протокола, или новые функции). То, что вы видите в топологии, является ожидаемым поведением, обусловленным порядком операций. Однако, несмотря на то, что обратная связь по маршруту сама по себе нарушается встроенными функциями IS-IS и OSPF, вам необходимо учитывать условия гонки, когда каналы связи нестабильны и могут возникать временные/переходные петли, которых вы не хотите; по этой причине вы должны всегда предотвращать обратную связь маршрутов, используя тегирование маршрутов в точках перераспределения (лучший вариант), и неявно контролировать желаемые маршруты, которые будут использоваться, или, иными словами, неоптимальную маршрутизацию, что означает, что вы всегда хотите, чтобы маршрутизатор, выполняющий взаимное перераспределение, маршрутизировал через соединения OSPF для префиксов OSPF и через соединения ISIS для префиксов ISIS (что в вашем случае не происходит, поскольку вы не реализовали решение с ручной обратной связью маршрутов). Спасибо, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/5713</link><guid isPermaLink="true">https://sla247.ru/forum/post/5713</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:58:05 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:58:04 GMT]]></title><description><![CDATA[<p dir="auto">![<img src="https://sla247.ru/forum/assets/plugins/nodebb-plugin-emoji/emoji/android/1f410.png?v=bf4cb1bda7d" class="not-responsive emoji emoji-android emoji--goat" style="height:23px;width:auto;vertical-align:middle" title=":goat:" alt="🐐" />]<br />
Объяснение уровня «бог». tldr: 1. Маршрутизатор A перераспределяет префикс, созданный ISIS, в OSPF. 2. Маршрутизатор B узнает этот префикс через OSPF и заменяет тот же префикс, который он узнал из ISIS. 3. Маршрутизатор B больше не имеет этого префикса как ISIS в своем RIB, поэтому он не может перераспределить его в OSPF. 4. Маршрутизатор A не может узнать этот префикс через OSPF. ![Untitled.png] Поэтому, похоже, это не связано с проверкой работоспособности или чем-то подобным.</p>
<p dir="auto"><img src="/forum/uploads/files/cisco/0825251ef161f8e4695e6975dc987329abbf9968.png" alt="" class=" img-fluid img-markdown" /></p>
<p dir="auto"><img src="/forum/uploads/files/cisco/e3ddb7d41e299d816894a32e095a78ca6a2a3f7e.png" alt="" class=" img-fluid img-markdown" /></p>
]]></description><link>https://sla247.ru/forum/post/5712</link><guid isPermaLink="true">https://sla247.ru/forum/post/5712</guid><dc:creator><![CDATA[daniel ng]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:58:04 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:58:03 GMT]]></title><description><![CDATA[<p dir="auto">Итак, OSPF имеет встроенный механизм предотвращения петли, но как обстоят дела с ISIS и BGP?</p>
]]></description><link>https://sla247.ru/forum/post/5711</link><guid isPermaLink="true">https://sla247.ru/forum/post/5711</guid><dc:creator><![CDATA[daniel ng]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:58:03 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:58:02 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте,<br />
@daniel ng<br />
, &gt;&gt; Я осуществлял перераспределение между ISIS и OSPF. Один маршрутизатор, осуществляющий перераспределение, узнает маршрут, созданный ISIS, через OSPF, а другой — через ISIS, и я вижу, что его OSPF RIB не узнал перераспределенный маршрут. OSPF имеет проверку работоспособности для LSA типа 5: если адрес пересылки, присутствующий в LSA типа 5, известен через другой внешний маршрут, текущий LSA типа 5 игнорируется и не устанавливается в таблицу маршрутизации IP. Поэтому я бы предложил проверить поля LSA типа 5. Надеюсь, это поможет Джузеппе</p>
]]></description><link>https://sla247.ru/forum/post/5710</link><guid isPermaLink="true">https://sla247.ru/forum/post/5710</guid><dc:creator><![CDATA[Giuseppe Larosa]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:58:02 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:58:01 GMT]]></title><description><![CDATA[<p dir="auto">Да, два маршрутизатора перераспределения. Но, как сказал Джузеппе, OSPF, похоже, способен подавлять LSA типа 5 с петлей. Я пытаюсь выяснить, есть ли у ISIS и BGP аналогичный механизм. PS: политика маршрутизации необходима только для EBGP.</p>
]]></description><link>https://sla247.ru/forum/post/5709</link><guid isPermaLink="true">https://sla247.ru/forum/post/5709</guid><dc:creator><![CDATA[daniel ng]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:58:01 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:58:00 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте,<br />
просто хочу уточнить, у вас есть двойные точки выхода для перераспределения границ?<br />
Если да, то я не знаю ни одной встроенной функции предотвращения циклического перераспределения на IOS/XR, которая бы<br />
исключала обратную передачу маршрутов. Ее нужно применять вручную, возможно, другие читатели этого поста знают о ней. Что касается языка политики маршрутизации XR (RPL), он необходим, особенно для BGP, даже для рекламирования/получения маршрутов. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.<br />
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.<br />
С уважением,<br />
Пол</p>
]]></description><link>https://sla247.ru/forum/post/5708</link><guid isPermaLink="true">https://sla247.ru/forum/post/5708</guid><dc:creator><![CDATA[paul driver]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:58:00 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:57:59 GMT]]></title><description><![CDATA[<p dir="auto">не создана карта маршрута или политика маршрута.</p>
]]></description><link>https://sla247.ru/forum/post/5707</link><guid isPermaLink="true">https://sla247.ru/forum/post/5707</guid><dc:creator><![CDATA[daniel ng]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:59 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:57:58 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте.<br />
Интересно, происходит ли перераспределение из XR rtr — создали ли вы для этого какую-либо политику RPL? Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.<br />
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.<br />
С уважением,<br />
Пол</p>
]]></description><link>https://sla247.ru/forum/post/5706</link><guid isPermaLink="true">https://sla247.ru/forum/post/5706</guid><dc:creator><![CDATA[paul driver]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:58 GMT</pubDate></item><item><title><![CDATA[Reply to обнаружение цикла перераспределения IOS XE и XR on Fri, 13 Feb 2026 19:57:57 GMT]]></title><description><![CDATA[<p dir="auto">Здравствуйте, Существует зависимость как от используемых протоколов маршрутизации, будь то маршрутизация на основе 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, а также, возможно, более четкое объяснение того, что, по вашему мнению, должно произойти, но не происходит. Спасибо, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/5705</link><guid isPermaLink="true">https://sla247.ru/forum/post/5705</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Fri, 13 Feb 2026 19:57:57 GMT</pubDate></item></channel></rss>