<?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[BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста]]></title><description><![CDATA[<p dir="auto">Здравствуйте, сообщество! Я столкнулся с очень странной проблемой BFD при развертывании Cisco SD-WAN (IOS-XE 17.05.04c). Хотя большинство наших сайтов, использующих один и тот же шаблон и транспорт, работают отлично, два конкретных сайта испытывают состояние BFD DOWN через частный транспорт MPLS. Настройка: Оборудование:<br />
C1121-4P (WAN Edge) и C8300 (DC WAN Edge).<br />
Транспорт 1:<br />
private2<br />
(L2VPN MPLS).<br />
Транспорт 2:<br />
biz-internet<br />
(Интернет).<br />
Конфигурация:<br />
Края TYPE-1 используют один<br />
и тот же шаблон устройства<br />
. Около 40 устройств на шаблон.<br />
Проблема:<br />
BFD<br />
private2<br />
к<br />
концентратору 1<br />
не работает. BFD<br />
private2<br />
к<br />
концентратору 2<br />
(тот же интерфейс/цвет/подсеть) работает. BFD<br />
biz-internet<br />
к<br />
концентратору 1<br />
работает. BFD<br />
biz-internet<br />
к<br />
концентратору 2<br />
работает. Проблема возникает только с двумя сайтами в одном городе и одним и тем же провайдером MPLS L2VPN ISP.<br />
private2 Данные по устранению неполадок: Доступность подстилающего уровня:<br />
ICMP Ping между IP-адресами TLOC успешен (размер 1400, бит DF установлен) и с DSCP.<br />
Парадокс трафика:</p>
<ul>
<li>Edge<br />
show sdwan tunnel statistics<br />
показывает<br />
увеличение инкапсуляции (tx-pkts)<br />
.<br />
Hub 1<br />
monitor capture<br />
на<br />
физическом интерфейсе (VPN 0 ingress)<br />
показывает<br />
НУЛЕВОЕ количество пакетов,<br />
поступающих с этих краев.<br />
Счетчики:<br />
SdwanImplicitAclDrop<br />
присутствуют, но<br />
не увеличиваются<br />
. Это не несоответствие TLOC/SPI.<br />
Аномалии в графическом интерфейсе vManage:<br />
При использовании инструмента<br />
«Устранение неполадок» -&gt; «Обнаружение подстилающего<br />
уровня» vManage не видит «Remote Transport Private2» для этих конкретных пар (от края к концентратору 1 и наоборот).<br />
Классификация SLA:</li>
<li>Вывод<br />
show sdwan tunnel remote-system-ip * sla<br />
для<br />
работающего<br />
Hub 2 показывает все сопоставленные классы SLA (<br />
Realtime, Business-Critical<br />
и т. д.).<br />
Однако для<br />
неработающего<br />
Hub 1 отображается только<br />
<strong>all_tunnels</strong><br />
. Это подтверждает, что BFD никогда не был достаточно работоспособным, чтобы политика App-route могла даже оценить соединение.<br />
Контекст масштабирования:<br />
Многие другие маршрутизаторы на разных сайтах используют того же<br />
private2<br />
провайдера и тот же Hub 1 без каких-либо проблем. Ограничения:<br />
Клиент указывает на успешный ICMP-ping как доказательство того, что провайдер MPLS не виноват. Однако многие другие сайты используют тот же шаблон/провайдера/Hub и работают отлично. Вопросы: Как Edge может сообщать об успешной инкапсуляции/TX, если физический интерфейс Hub ничего не видит?<br />
Почему vManage Underlay Discovery не работает, если существует базовая IP-доступность?<br />
Есть ли какие-либо известные ошибки на уровне ASIC в C1121-4P, из-за которых он не может передавать инкапсулированные пакеты на физический провод при определенных условиях MTU/L2VPN? Буду очень благодарен за любую помощь!</li>
</ul>
]]></description><link>https://sla247.ru/forum/topic/602/bfd-down-на-mpls-инкремент-инкапсуляции-но-физическая-запись-на-hub-пуста</link><generator>RSS for Node</generator><lastBuildDate>Fri, 15 May 2026 16:04:25 GMT</lastBuildDate><atom:link href="https://sla247.ru/forum/topic/602.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 12 Feb 2026 14:31:07 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:14 GMT]]></title><description><![CDATA[<p dir="auto">Привет, @Cristian Matei<br />
, я думал точно так же, поэтому я попробовал вернуться к предыдущим IP-адресам. К сожалению, сеанс BFD сразу же прервался, как только я вернулся к прежним настройкам. Такое поведение наблюдается на обоих маршрутизаторах, которые находятся географически близко друг к другу (в радиусе 5 км) и используют одного и того же интернет-провайдера с L2VPN. Я попробовал очистить кэш ARP, но это не помогло. Я также проверил, что нет дублирования IP-адресов: когда старые адреса не назначены моим интерфейсам, они не отвечают на ping. Интересно, что я выполнил несколько других миграций в разных регионах с тем же интернет-провайдером L2VPN, с тех пор используя тот же шаблон и процесс, и эта проблема нигде больше не возникала. С уважением,<br />
Дмитрий Ратошнюк</p>
]]></description><link>https://sla247.ru/forum/post/3959</link><guid isPermaLink="true">https://sla247.ru/forum/post/3959</guid><dc:creator><![CDATA[N9Kway]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:14 GMT</pubDate></item><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:13 GMT]]></title><description><![CDATA[<p dir="auto">Привет, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/n9kway" aria-label="Profile: N9Kway">@<bdi>N9Kway</bdi></a><br />
Рад, что вы исправили это. В то же время, если у вас было IPv4-соединение в подслое между спицей и концентратором со старым IPv4-адресом, это не имеет никакого смысла, кроме как ошибка, что-то застряло, и изменение IPv4-адреса просто очистило состояние состояния машины. Если у вас есть такая возможность, можете ли вы теперь вернуть его к прежнему состоянию и посмотреть, появится ли он? Спасибо, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/3958</link><guid isPermaLink="true">https://sla247.ru/forum/post/3958</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:13 GMT</pubDate></item><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:12 GMT]]></title><description><![CDATA[<p dir="auto">Привет, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/n9kway" aria-label="Profile: N9Kway">@<bdi>N9Kway</bdi></a><br />
Что касается версии ПО, было немного странно, что вы использовали 17.5, но теперь все стало понятно. Ни в коем случае не переходите с версии, которую вы используете в настоящее время, на более новые версии, включая 17.18, поскольку они совершенно не стабильны. Для обновления дождитесь 17.18.x MD и используйте ее только в том случае, если в течение 3-6 месяцев не будет выпущена другая версия MD. Просто хочу прояснить кое-что, прежде чем двигаться дальше. Вы говорите, что именно эта модель HW / SW с точно такой же конфигурацией способна построить туннель и сессию BFD к HUB1 через тот же транспорт? И только 1-2 сайта не могут этого сделать? Можете ли вы повторно развернуть шаблоны/группы конфигурации как на работающем, так и на неработающем устройстве, а затем использовать функцию<br />
предварительного просмотра<br />
, чтобы скопировать отправленную конфигурацию для обоих устройств, после чего сравнить их и убедиться, что нет никаких различий в отправленных функциях и возможностях? Развертывание прошло успешно для обоих сайтов, работающего и неработающего? Спасибо, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/3957</link><guid isPermaLink="true">https://sla247.ru/forum/post/3957</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:12 GMT</pubDate></item><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:11 GMT]]></title><description><![CDATA[<p dir="auto">Привет, Кристиан, Спасибо за предложение. Прошу прощения за опечатку в моем первоначальном сообщении относительно версии программного обеспечения; я не хотел вводить вас в заблуждение. На самом деле мы используем версию<br />
17.15.04c<br />
, которая в настоящее время является<br />
рекомендуемой версией<br />
. После первоначальной проверки подключения и подтверждения того, что другие сайты с идентичными параметрами работают правильно в рамках этого шаблона, я перезагрузил как WAN Edge филиала, так и WAN Edge ЦОД, но проблема осталась. Что касается вашей рекомендации по поводу<br />
17.16.8a MD<br />
, я заметил, что в настоящее время для загрузки доступна только версия<br />
17.16.1a (ED)<br />
. Учитывая, что это версия раннего развертывания, я немного сомневаюсь, стоит ли переходить на нее в производственной среде, если она не решает конкретно эту проблему с BFD/UDP. Поскольку я уже использую самую последнюю версию (17.15.x), как вы думаете, это может быть регрессионная ошибка, или мне следует более тщательно изучить пересылку ASIC на этой конкретной платформе? С уважением,<br />
Дмитрий Ратошнюк</p>
<p dir="auto"><img src="/forum/uploads/files/cisco/b63a5c7dbf4e099906c71a4b8249f1486c127bcd.png" alt="" class=" img-fluid img-markdown" /></p>
]]></description><link>https://sla247.ru/forum/post/3956</link><guid isPermaLink="true">https://sla247.ru/forum/post/3956</guid><dc:creator><![CDATA[N9Kway]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:11 GMT</pubDate></item><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:10 GMT]]></title><description><![CDATA[<p dir="auto">Привет, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/n9kway" aria-label="Profile: N9Kway">@<bdi>N9Kway</bdi></a><br />
Что касается описанного поведения, я бы сказал, что, скорее всего, вы столкнулись с ошибкой. Думаю, вы уже пробовали перезагрузить устройство, верно? Если нет, попробуйте. Если у вас установлена версия 17.05.04c, то она больше не доступна для загрузки, что говорит о многом, а именно о том, что это была не очень удачная версия. В ней было много ошибок, связанных с BFD. Поскольку обновления SDWAN сопровождаются как исправлениями, так и дополнительными проблемами, я предлагаю попробовать обновить удаленное/филиальное устройство до первой версии MD после 17.5, а именно 17.16.8a MD или 17.9.8 MD. Спасибо, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/3955</link><guid isPermaLink="true">https://sla247.ru/forum/post/3955</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:10 GMT</pubDate></item><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:09 GMT]]></title><description><![CDATA[<p dir="auto">Привет, <a class="plugin-mentions-user plugin-mentions-a" href="/forum/user/n9kway" aria-label="Profile: N9Kway">@<bdi>N9Kway</bdi></a><br />
Обычно я не отхожу от таких сценариев, не выяснив причину, поскольку это может повлиять на меня в будущем. Я лично видел такое постоянное поведение на SDWAN, поэтому один из вариантов заключается в том, что на этом уровне что-то застряло (единственный способ выяснить это — удалить конфигурацию маршрутизатора и настроить его заново). В противном случае, может быть что-то на стороне транспорта, связанное с этим конкретным IP. Удачи, Кристиан.</p>
]]></description><link>https://sla247.ru/forum/post/3954</link><guid isPermaLink="true">https://sla247.ru/forum/post/3954</guid><dc:creator><![CDATA[Cristian Matei]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:09 GMT</pubDate></item><item><title><![CDATA[Reply to BFD DOWN на MPLS: инкремент инкапсуляции, но физическая запись на HUB пуста on Thu, 12 Feb 2026 14:31:08 GMT]]></title><description><![CDATA[<p dir="auto">Привет,<br />
@Cristian Matei.<br />
У меня есть новости — проблема наконец-то<br />
решена<br />
. Я решил изменить настроенный IP-адрес на физическом интерфейсе TLOC для<br />
private2<br />
, и сразу после этого изменения сеанс BFD заработал. Честно говоря, это довольно странно, потому что для перехода на новую платформу мы выделили совершенно<br />
новую подсеть IPv4<br />
, поэтому, по логике, не должно было быть никаких конфликтов или дубликатов IP-адресов. Я также проверил записи ARP на наличие устаревших. Однако изменение IP-адреса явно устранило любую существующую блокировку. Большое спасибо за ваше время и помощь в процессе устранения неполадки! С уважением,<br />
Дмитрий Ратошнюк</p>
]]></description><link>https://sla247.ru/forum/post/3953</link><guid isPermaLink="true">https://sla247.ru/forum/post/3953</guid><dc:creator><![CDATA[N9Kway]]></dc:creator><pubDate>Thu, 12 Feb 2026 14:31:08 GMT</pubDate></item></channel></rss>