Хорошо

BGP: оптимизация сходимости средствами BFD (Bidirectional Forwarding Detection) Популярное

Последний ответ июн 02, 2021 12:28:08 619 2 8 0 1

Всем доброго дня!

В данном посте я хотел бы донести нюансы по оптимизации времени сходимости сети (с BGP) внешним универсальным средством проверки состояния IP-линка:

BFD (Bidirectional Forwarding Detection).

    Предпосылка к данному посту:

- наличие поста по данной тематике, НО, на мой взгляд "вырванной" из сети, точнее - продолжаю мысль докладчика (ниже - ссылка на "базу");

- повторяю теорию/практику, если получается НЕ сразу - то, делюсь...

- желание сделать пост все-в-одном по выбранной проблематике.

    Итак, мы знаем, что BGP - неторопливый, очень серьездный протокол - это его "ПЛЮС",
но и минус в том-же: возникают техники, нацеленные на ускорение процессов BGP или экономию ресурсов...в случае 1, 2, 3.
    Если схема сети предполагает принятие решение о НЕдостижимости пути/маршрута/соседа ранее, чем это делают таймеры протоколов маршрутизации, то нам на помощь приходит BFD: методика, при которой мы (маршрутизатор) достоверно мониторим линк/IP/интерйейс с периодом не секунды/минуты, а МИЛИсекунды и принимаем решение на основе этой доступности линка быстрее-выше-сильнее.

Исходя, из сказанного, техника BFD (в от личии от IP SLA) = двусторонняя настройка.

    Предлагаю "обкатать" падения линков/каналов на схеме:

BGP_BFD_1

Естественно, считаем, что все настроено и работает = OSPF (R1-R2-R3), BGP (между R1 и R2).
На R1 LoopBack0 = 1.1.1.1, НА R2 = 2.2.2.2 (через них "пиримся").
Желающим проверить - прикреплю файл-настройку eNSP (+ листинги команд, т. к. замечено, что после сохранения конфиги могут "исчезнуть" :( )
Работоспособность доказываю кратко - часть таблички маршрутизации с R2 =
[~R2]display ip routing-table
...
         Destinations : 17       Routes : 17        

Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface

        1.1.1.1/32  OSPF    10   2             D   192.168.23.3    Ethernet1/0/2
        2.2.2.2/32  Direct  0    0             D   127.0.0.1       LoopBack0
     10.10.10.0/24  EBGP    255  0             RD  1.1.1.1         Ethernet1/0/2
     20.20.20.0/24  Direct  0    0             D   20.20.20.1      Ethernet1/0/1

...
+
для работы BGP (линк через коммутаторы) имеем статику на R1, R2 (она приоритетом ниже, чем OSPF - ее нет в RFIB), вывод с R2=

[~R2]display current-configuration | include ip route-s
...
ip route-static 1.1.1.1 255.255.255.255 172.16.12.1

__Приступим к испытаниям__

1) Отключаем путь через R3 (локальные интерфейсы на R1-R2 "дергать" не спортивно):

[R3]int GigabitEthernet 0/0/0
[R3-GigabitEthernet0/0/0]
sh

Смотрим маршруты (был через OSPF, стал = static, моментально):

[~R2]display ip routing-table
...

Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface
        1.1.1.1/32  Static  60   0             RD  172.16.12.1     Ethernet1/0/0
        2.2.2.2/32  Direct  0    0             D   127.0.0.1       LoopBack0
     10.10.10.0/24  EBGP    255  0             RD  1.1.1.1         Ethernet1/0/0

Т. е. промежуточный вывод = OSPF = отличный метод анализа линка и для нашей ситуации связанности AS.

НО, увы, теория-практика говорит, что маловероятна "динамика" между AS.

Т. е. после отключения OSPF, продолжаем изыскания.

1-1) Отключаем линк между коммутаторами SW1-SW2 (дело в том, что отключение интерфейсов напрямую на R1-R2 приведет к моментальной перестройке - не интересно, да и не жизненно: вероятность, что между нами активное L2 устнойство - огромная):

[Huawei]int gi 0/0/2
[Huawei-GigabitEthernet0/0/2]sh

Смотрим - что с сетями на R2? Сразу дам ответ, который изучен-переучен: еще примерно 2,5 минуты BGP-спикер будет имет данные о сетках, которые не доступны.

Нужно подсказать маршрутизаторам - как сделать быстрее решение о недостижимости.

Решаем методом, описанным в интернете (и в посте, который я проверял), поэтому далее - кратко,
на R1 и R2:

[~R1]bfd  (включаем глобально)

затем в направлении BGP-соседа:

bgp 100
 peer 2.2.2.2 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
 peer 2.2.2.2 bfd enable

Где,
min
-tx-interval – интервал генерации control пакетов (в миллисекундах).

min-rx-interval – минимальный интервал между входящими controlпакетами.

detect-multiplier – количество пакетов, которые BFD может пропустить прежде чем информирует о неполадках с подключением.

То же самое настраиваем на R2. Включаем линк. Проверяем:

[~R2]display bgp bfd session all
--------------------------------------------------------------------------------
  Local_Address      Peer_Address       Interface
  2.2.2.2            1.1.1.1            Unknown
  Tx-interval(ms)    Rx-interval(ms)    Multiplier  Session-State
  100                100                4           Up
  Wtr-interval(m)
  0                  

--------------------------------------------------------------------------------
[~R2]

Т. е. результатом настройки будет создание двусторонней сессии проверки BGP-соседей методом(протоколом) BFD.

И тут самое главное (для моего поста): а это еще не все!

В таблице RFIB нет BGP-сетей, но есть статика, которая жива и пользуется: некрасиво:

        1.1.1.1/32  Static  60   0             RD  172.16.12.1     Ethernet1/0/0

Ее тоже нужно "подчищать", ну и раз "катаю" технику BFD, то тем же методом, а именно:

Создается правило опроса IP-адресов для установки UDP (как я понял из RFC 5881 и 5883) сессии, на основе этого опроса мы не только BGP шлифуем, но и статический маршрут наблюдаем.
Думаю, что команды (делаются и на R1 и на R2) скажут сами за себя,
для R1:

bfd bgp_bfd bind peer-ip 172.16.12.2
 discriminator local 10
 discriminator remote 20

и привязываем к статике (напомню, что она уже была, но без BFD) =

ip route-static 2.2.2.2 255.255.255.255 172.16.12.2 track bfd-session bgp_bfd

Для R2:

bfd bgp_bfd bind peer-ip 172.16.12.1
 discriminator local 20
 discriminator remote 10

ip route-static 1.1.1.1 255.255.255.255 172.16.12.1 track bfd-session bgp_bfd

Проверим BFD сессию:

[~R1]display bfd session all
(w): State in WTR
(*): State is invalid
--------------------------------------------------------------------------------
Local      Remote     PeerIpAddr      State     Type        InterfaceName
--------------------------------------------------------------------------------
10         20         172.16.12.2     Up        S_IP_PEER         - Это, то что сделано для статики
16390      16386      2.2.2.2         Up        D_IP_PEER         - Это сессия для BGP
--------------------------------------------------------------------------------
    Total UP/DOWN Session Number : 2/0
[~R1]

Финальная проверка: отключаем линк между коммутаторами и сразу смотрим таблицу маршрутизации на R1-R2:

[~R1]display ip routing-table protocol static
[~R1]

[~R1]display ip routing-table protocol bgp
[~R1]

Ни BGP-сетей, ни статики, моментально (ну, 0,4 секунды, если точно следовать настройкам).

Первоисточники:

1) Пост о BFD

2) RFC =
https://datatracker.ietf.org/doc/html/rfc5883 и
https://datatracker.ietf.org/doc/html/rfc5881

3) BFD для статики






У статьи есть другие ресурсы

Требуется войти для загрузки или просмотра. Нет аккаунта? Register

x

Пост синхронизирован: BGP лабораторияТестируем в eNSP

  • x

Vasyo
Админ Опубликовано 2021-6-2 12:18:20
Это проприетарная или открытая технология, можете подсказать? Тестировали ли вы ее на другом известном вендоре?
Развернуть
  • x

mkabanov
HCIE MVE Author Опубликовано 2021-6-2 12:28:08
Это открытая техника - пока я "повторяю" только такие :)
Да, проверял, но лет 10 назад: дело в том, что BFD Можно "прикручивать" ко многим механизмам, поэтому применимость, считаю, обеспечена на реальных сетях.
Развернуть
  • x

Комментарий

Выполните вход в систему, чтобы ответить на пост. Вход | Регистрация
Отправить

Внимание! В целях защиты правовых интересов Вас, сообщества и третьих лиц, не публикуйте любой материал, содержащий политические высказывания, порнографию, упоминание азартных игр, употребление наркотиков, а также материал, нарушающий коммерческую тайну или содержащий персональные данные пользователей. Также не предоставляйте данные от вашей учетной записи. Вы будете нести ответственность за все действия, выполняемые под вашим аккаунтом. Подробная информация: “Пользовательское соглашение.”

My Followers

Авторизуйтесь и пользуйтесь всеми преимуществами участника!

Вход

Заблокировать
Вы уверены, что хотите заблокировать этого пользователя?
Пользователи из вашего черного списка не могут комментировать ваши посты, не могут упоминать вас, не могут отправлять личные сообщения.
Напоминание
Пожалуйста, привяжите свой мобильный номер чтобы получить бонус за приглашение.