Всем привет. Нужен совет.Есть Центральный Офис (Cisco 2921) и Филиал (Mikrotik), по два провайдера в каждом. Настроены пинговалки и переключалки на случай падения основных каналов. Проложены четыре GRE-туннеля: каждый провайдер соединен с каждым. Поверх GRE запущен OSPF с разной метрикой для приоретизации маршрутов.
Когда оба основных провайдера в двух точках работают: все штатно. Мы получаем от них их сети по OSPF, они от нас получают наши. Теперь, имитируем отказ основного провайдера в филиале: переключаем дефолт на дополнительного провайдера, и на нашей стороне видим вот такую картину:
Neighbor ID Pri State Dead Time Address Interface
10.54.54.1 0 EXCHANGE/ - 00:00:31 10.192.54.6 Tunnel541 (это основной туннель, который как бы упал)
10.54.54.1 0 FULL/ - 00:00:34 10.192.54.2 Tunnel542 (это бэкапный, от нашего основного провайдера до их второстепенного).Так держится около 7-10 секунд, а дальше канал отваливается. Через некоторое время канал появляется вновь, и так по кругу.
При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты, хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.
>[оверквотинг удален]
> каждом. Настроены пинговалки и переключалки на случай падения основных каналов.
> Проложены четыре GRE-туннеля: каждый провайдер соединен с каждым. Поверх GRE запущен OSPF
> с разной метрикой для приоретизации маршрутов.
> Так держится около 7-10 секунд, а дальше канал отваливается. Через некоторое время
> канал появляется вновь, и так по кругу.
> При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты,
> хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически
> без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не
> было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в
> маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.Да, похоже в маршрутизации.
Например: gre-туннели привязаны к белым-публичным адресам провайдеров. Нельзя допускать чтобы пакеты полетели через бэкапного провайдера имея src-ip основного провайдера. Так будет работать только на симуляторах.
>[оверквотинг удален]
>> канал появляется вновь, и так по кругу.
>> При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты,
>> хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически
>> без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не
>> было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в
>> маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.
> Да, похоже в маршрутизации.
> Например: gre-туннели привязаны к белым-публичным адресам провайдеров. Нельзя допускать
> чтобы пакеты полетели через бэкапного провайдера имея src-ip основного провайдера. Так
> будет работать только на симуляторах.Как указан маршрут на пиров (белые адреса) статикой? Когда падает канал, то роутер начинает отправлять пакеты с "неправильным" соурсом через канал друго провайдера. На Циске можно разрулить VRF-ами, как на Микротике не знаю, не имел дела с ним. Либо настраивать только 2 туннеля, выбрав каких провайдеров попарно склюшить с обоих концов.
Поставить исходящие аксес-листы на интернет-интерфейсах, разрешающих пакеты только с IP этих интерфейсов.
Как уже заметили ранее, некоторые провайдеры пропускают траффик с IP от другого провайдера (чем кстати "нарушают" RFC).
VRF не рассматривали, потому как перекраивать продакшн-роутер ради этого дела - слишком толсто.Да, видимо загвоздка действительно в правилах пропуска пакетов через провайдера. В данный момент отказались от промежуточных туннлей, оставив только два - между основными провайдерами и между дополнительными. Пока полет нормальный, OSPF cost отрабатывает верно и при FULL-соседствах по двум туннелям, роуты стоят только по одному. Завтра будем проверять сценарий отказа одного из провайдеров.
Кстати, на тему того, что провайдеры "нарушают" RFC. Номер RFC не подскажете? Интересно почитать.
> Кстати, на тему того, что провайдеры "нарушают" RFC. Номер RFC не подскажете?
> Интересно почитать.
>> Кстати, на тему того, что провайдеры "нарушают" RFC. Номер RFC не подскажете?
>> Интересно почитать.
> https://www.ietf.org/rfc/rfc3704.txt"нарушают" в кавычках потому что провайдеры никому ничего не должны, и RFC это рекомендация. Просто правило хорошего тона.