https://opennet.dev/openforum/vsluhforumID6/1871.html Всем привет. Нужен совет. <br><br>Есть Центральный Офис (Cisco 2921) и Филиал (Mikrotik), по два провайдера в каждом. Настроены пинговалки и переключалки на случай падения основных каналов. Проложены четыре GRE-туннеля: каждый провайдер соединен с каждым. Поверх GRE запущен OSPF с разной метрикой для приоретизации маршрутов. <br><br>Когда оба основных провайдера в двух точках работают: все штатно. Мы получаем от них их сети по OSPF, они от нас получают наши. Теперь, имитируем отказ основного провайдера в филиале: переключаем дефолт на дополнительного провайдера, и на нашей стороне видим вот такую картину:<br><br>Neighbor ID Pri State Dead Time Address Interface<br>10.54.54.1 0 EXCHANGE/ - 00:00:31 10.192.54.6 Tunnel541 (это основной туннель, который как бы упал)<br>10.54.54.1 0 FULL/ - 00:00:34 10.192.54.2 Tunnel542 (это бэкапный, от нашего основного провайдера до их второстепенного). <br><br>Так держится около 7-10 секунд, а дальше канал отваливается. Через некоторое время канал появляется вновь, и так по кругу. <br><br>При создани https://opennet.dev/openforum/vsluhforumID6/1871.html#7 Tue, 08 Dec 2015 05:18:47 GMT &gt;&gt; Кстати, на тему того, что провайдеры "нарушают" RFC. Номер RFC не подскажете?<br>&gt;&gt; Интересно почитать.<br>&gt; https://www.ietf.org/rfc/rfc3704.txt <br><br>"нарушают" в кавычках потому что провайдеры никому ничего не должны, и RFC это рекомендация. Просто правило хорошего тона.<br> https://opennet.dev/openforum/vsluhforumID6/1871.html#6 Tue, 08 Dec 2015 05:12:56 GMT &gt; Кстати, на тему того, что провайдеры "нарушают" RFC. Номер RFC не подскажете? <br>&gt; Интересно почитать.<br><br>https://www.ietf.org/rfc/rfc3704.txt<br> https://opennet.dev/openforum/vsluhforumID6/1871.html#5 Mon, 07 Dec 2015 13:22:38 GMT Кстати, на тему того, что провайдеры "нарушают" RFC. Номер RFC не подскажете? Интересно почитать. <br> https://opennet.dev/openforum/vsluhforumID6/1871.html#4 Mon, 07 Dec 2015 13:19:58 GMT VRF не рассматривали, потому как перекраивать продакшн-роутер ради этого дела - слишком толсто. <br><br>Да, видимо загвоздка действительно в правилах пропуска пакетов через провайдера. В данный момент отказались от промежуточных туннлей, оставив только два - между основными провайдерами и между дополнительными. Пока полет нормальный, OSPF cost отрабатывает верно и при FULL-соседствах по двум туннелям, роуты стоят только по одному. Завтра будем проверять сценарий отказа одного из провайдеров. <br> https://opennet.dev/openforum/vsluhforumID6/1871.html#3 Mon, 07 Dec 2015 12:28:25 GMT Поставить исходящие аксес-листы на интернет-интерфейсах, разрешающих пакеты только с IP этих интерфейсов.<br>Как уже заметили ранее, некоторые провайдеры пропускают траффик с IP от другого провайдера (чем кстати "нарушают" RFC).<br> https://opennet.dev/openforum/vsluhforumID6/1871.html#2 Mon, 07 Dec 2015 12:26:22 GMT &gt;[оверквотинг удален]<br>&gt;&gt; канал появляется вновь, и так по кругу.<br>&gt;&gt; При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты, <br>&gt;&gt; хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически <br>&gt;&gt; без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не <br>&gt;&gt; было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в <br>&gt;&gt; маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.<br>&gt; Да, похоже в маршрутизации.<br>&gt; Например: gre-туннели привязаны к белым-публичным адресам провайдеров. Нельзя допускать <br>&gt; чтобы пакеты полетели через бэкапного провайдера имея src-ip основного провайдера. Так <br>&gt; будет работать только на симуляторах.<br><br>Как указан маршрут на пиров (белые адреса) статикой? Когда падает канал, то роутер начинает отправлять пакеты с "неправильным" соурсом через канал друго провайдера. На Циске можно разрулить VRF-ами, как на Микротике не знаю, не имел дела с ним. Либо настраивать только 2 туннеля, выбрав каких провайдеров попарно склю https://opennet.dev/openforum/vsluhforumID6/1871.html#1 Mon, 07 Dec 2015 11:06:12 GMT &gt;[оверквотинг удален]<br>&gt; каждом. Настроены пинговалки и переключалки на случай падения основных каналов. <br>&gt; Проложены четыре GRE-туннеля: каждый провайдер соединен с каждым. Поверх GRE запущен OSPF <br>&gt; с разной метрикой для приоретизации маршрутов.<br>&gt; Так держится около 7-10 секунд, а дальше канал отваливается. Через некоторое время <br>&gt; канал появляется вновь, и так по кругу.<br>&gt; При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты, <br>&gt; хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически <br>&gt; без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не <br>&gt; было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в <br>&gt; маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.<br><br>Да, похоже в маршрутизации.<br><br>Например: gre-туннели привязаны к белым-публичным адресам провайдеров. Нельзя допускать чтобы пакеты полетели через бэкапного провайдера имея src-ip основного провайдера. Так будет работать только на симуляторах.<br>