The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
2 ISP + 4 GRE + OSPF, !*! Aneye, 06-Дек-15, 20:47  [смотреть все]
Всем привет. Нужен совет.

Есть Центральный Офис (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 отрабатывает на ура, практически без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.  

  • 2 ISP + 4 GRE + OSPF, !*! cant, 14:06 , 07-Дек-15 (1)
    >[оверквотинг удален]
    > каждом. Настроены пинговалки и переключалки на случай падения основных каналов.  
    > Проложены четыре GRE-туннеля: каждый провайдер соединен с каждым. Поверх GRE запущен OSPF
    > с разной метрикой для приоретизации маршрутов.
    > Так держится около 7-10 секунд, а дальше канал отваливается. Через некоторое время
    > канал появляется вновь, и так по кругу.
    > При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты,
    > хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически
    > без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не
    > было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в
    > маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.

    Да, похоже в маршрутизации.

    Например: gre-туннели привязаны к белым-публичным адресам провайдеров. Нельзя допускать чтобы пакеты полетели через бэкапного провайдера имея src-ip основного провайдера. Так будет работать только на симуляторах.

    • 2 ISP + 4 GRE + OSPF, !*! puffnuttin, 15:26 , 07-Дек-15 (2)
      >[оверквотинг удален]
      >> канал появляется вновь, и так по кругу.
      >> При создании подобной ситуации в GNS3 - все работает отлично. Переключаешь дефолты,
      >> хоть в ЦО, хоть в филиале: OSPF отрабатывает на ура, практически
      >> без потерь пакетов. Однако, на реальной сети ситуация другая. Пока не
      >> было возможности "заснифить" этот момент. Я подозреваю, что засада где-то в
      >> маршрутизации, но может и нет. Хотелось бы узнать ваши мнения.
      > Да, похоже в маршрутизации.
      > Например: gre-туннели привязаны к белым-публичным адресам провайдеров. Нельзя допускать
      > чтобы пакеты полетели через бэкапного провайдера имея src-ip основного провайдера. Так
      > будет работать только на симуляторах.

      Как указан маршрут на пиров (белые адреса) статикой? Когда падает канал, то роутер начинает отправлять пакеты с "неправильным" соурсом через канал друго провайдера. На Циске можно разрулить VRF-ами, как на Микротике не знаю, не имел дела с ним. Либо настраивать только 2 туннеля, выбрав каких провайдеров попарно склюшить с обоих концов.

  • 2 ISP + 4 GRE + OSPF, !*! ShyLion, 15:28 , 07-Дек-15 (3)
    Поставить исходящие аксес-листы на интернет-интерфейсах, разрешающих пакеты только с IP этих интерфейсов.
    Как уже заметили ранее, некоторые провайдеры пропускают траффик с IP от другого провайдера (чем кстати "нарушают" RFC).
    • 2 ISP + 4 GRE + OSPF, !*! Aneye, 16:19 , 07-Дек-15 (4)
      VRF не рассматривали, потому как перекраивать продакшн-роутер ради этого дела - слишком толсто.

      Да, видимо загвоздка действительно в правилах пропуска пакетов через провайдера. В данный момент отказались от промежуточных туннлей, оставив только два - между основными провайдерами и между дополнительными. Пока полет нормальный, OSPF cost отрабатывает верно и при FULL-соседствах по двум туннелям, роуты стоят только по одному. Завтра будем проверять сценарий отказа одного из провайдеров.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру