BGP и BFD на Cisco

Bidirectional Forwarding Detection (BFD) - протокол, позволяющий быстро обнаруживать проблемы связности маршрутизаторов на IP уровне и тем самым обеспечивающий быструю сходимость протоколов маршрутизации.
BFD - двусторонний протокол, оба  маршрутизатора генерируют BFD пакеты, а также отвечают на BFD пакеты посланные соседом. Протокол BFD практически не влияет на производительность CPU, поэтому интервал между BFD пакетами может быть сокращен до 50 мс, что обеспечивает быструю сходимость.
BFD пакеты инкапсулируются в unicast UDP. BFD payload control пакеты используют в качестве  destination port 3784 и в качестве  source port 49152.
BFD Echo пакеты используют destination port 3785 и source port 3785.

BFD может работать в 2-х режимах:
1.  BFD Async  - в этом режиме маршрутизаторы обмениваются только control пакетами.
2.  BFD Echo - в этом режиме маршрутизаторы обмениваются помимо control еще и  echo пакетами. Echo пакеты отличаются от control тем, что имеют адрес назначения равный адресу источника. Попадая на соседнюю систему они проходят весь обычный forwarding path, таким образом обеспечивая более полное тестирование работоспособности системы. По умолчанию на Cisco маршрутизаторах BFD Echo mode включен (отключается командой no bfd echo на интерфейсе). При использовании echo mode необходимо указывать no ip redirects на интерфейсе во избежание перегрузки CPU. Частота control пакетов может быть в этом режиме снижена (команда bfd slow-timers в режиме глобальной конфигурации позволяет настраивать интервал генерации control пакетов).



Рассмотрим на примере:

Маршрутизаторы, соединенные непосредственно друг с другом, быстро обнаруживают проблему. Падение интерфейса на одном конце мгновенно будет обнаружено соседом на противоположном, что приведет к оперативному удалению недействительного маршрута из таблицы маршрутизации.

Однако, ситуация меняется, если между маршрутизаторами появляется коммутатор:

В этом случае падение интерфейса на маршрутизаторе ISP никак не будет обнаружено маршрутизатором CE1. Удаление недействительного маршрута полностью зависит от таймеров используемого протокола маршрутизации (до 3 минут у BGP).

В этой ситуации спасет использование BFD. Между маршрутизаторами устанавливаем двустороннюю BFD сессию:

 Настраивается на интерфейсах обоих маршрутизаторов :

interface FastEthernet0/1
 bfd interval N1 min_rx N2 multiplier  interval-multiplier

 no ip redirects  

N1 -  интервал генерации control пакетов (в миллисекундах), от 50 до 999

N2 - минимальный интервал между входящими control пакетами, от 50 до 999

 interval-multiplier - количество последовательно пакетов, которые BFD может пропустить прежде чем информировать Layer 3 о проблеме.

После чего  привязываем используемый нами протокол маршрутизации (в данном случае BGP) к состоянию BFD сессии.

router bgp 200
 neighbor 3.3.3.2 fall-over bfd

Настройка должна быть выполнена на обоих маршрутизаторах, иначе эффективность предпринятых телодвижений стремится к нулю :)
Также возможна привязка статического маршрута к BFD сессии.


В результате при обнаружении падения BFD сессии (несколько сотен миллисекунд), маршрутизатор разрывает BGP сессию и оперативно удаляет  недействительные маршруты из таблицы маршрутизации.

Пример 1. Работа без BFD

Роняем интерфейс F0/1 на ISP.

ISP1#sh logg

000068: Dec 29 18:36:52.068 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

CE1#sh logg
*Dec 29 18:39:33.453 Moscow: %BGP-5-ADJCHANGE: neighbor 3.3.3.2 Down BGP Notification sent
*Dec 29 18:39:33.453 Moscow: %BGP-3-NOTIFICATION: sent to neighbor 3.3.3.2 4/0 (hold time expired) 0 bytes
*Dec 29 18:39:33.453 Moscow: %BGP_SESSION-5-ADJCHANGE: neighbor 3.3.3.2 IPv4 Unicast topology base removed from session  BGP Notification sent

Разница между падением интерфейса на ISP  и удалением недействительных маршрутов на CE1,  2 минуты 41 секунда. 

Пример 2. Работа c BFD

На обоих маршрутизаторах выполнены команды
interface FastEthernet0/1
 bfd interval 50 min_rx 50 multiplier 4

Роняем интерфейс F0/1 на ISP.

ISP1#sh logg

000064: Dec 29 18:25:45.295 Moscow: %BGP-5-ADJCHANGE: neighbor 3.3.3.1 Down BFD adjacency down
000065: Dec 29 18:25:52.123 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

CE1#sh logg

*Dec 29 18:25:45.497 Moscow: %BGP-5-ADJCHANGE: neighbor 3.3.3.2 Down BFD adjacency down
*Dec 29 18:25:45.497 Moscow: %BGP_SESSION-5-ADJCHANGE: neighbor 3.3.3.2 IPv4 Unicast topology base removed from session  BFD adjacency down

Разница между падением интерфейса на ISP  и удалением недействительных маршрутов на CE1, как и должно быть согласно заданным параметрам, порядка 200 миллисекунд. 

Стандартная реализация ВFD в Cisco не позволяет поддерживать сессии с промежуточными IP узлами между соседями:

 Соответственно, не получится поднять BFD сессию для multihop eBGD или iBGP с использованием Loopback'ов.
Однако с версии 15.1(3)S появилась фича multihop BFD, позволяющая обойти это ограничение:

Troubleshooting:

show bfd neighbors

show bfd neighbors details

Multihomed BGP

Задача:

Имеются собственные PI адреса (1.1.1.0/24), собственная AS (AS100) и подключение к 2-м провайдерам.  Один провайдер основной(ISP1), второй резервный(ISP2). Необходимо обеспечить резервирование выхода в интернет на уровне железа.

Ограничения:

Одна железка(CE1) держит BGP full view, другая(CE2) нет. Слабая железка CE2 имеет только 2 интерфейса FastEthernet.

Решение:

Поднимаем eBGP сессии с провайдерами и iBGP между своими маршрутизаторами. Сильный маршрутизатор CE1 получает Full View от основного провайдера, слабый CE2 только дефолт от запасного. Оба маршрутизатора анонсируют свою сеть (1.1.1.0/24) и модифицируют атрибуты так, чтобы  обратный трафик с большей вероятностью возвращался через основного провайдера.  Между собой маршрутизаторы устанавливают iBGP сессию, CE2 отдает дефолтный маршрут, полученный по eBGP от ISP2, на сильный маршрутизатор CE1. CE1 не отдает на CE2 ничего. Сеанс устанавливаем на реальные адреса, т.к. путь друг до друга у CE1 и CE2 один. Со стороны локальной сети между CE1 и CE2 поднят HSRP с виртуальным адресом 1.1.1.1/24 (на схеме не обозначено). Приоритет HSRP выставлен так, что CE1 является Active.

Настройка

CE1:

interface FastEthernet0/0
 ip address 1.1.1.3 255.255.255.0
 no ip redirects - Cisco рекомендует выполнять эту команду при использовании BFD, т.к. в противном случае будет грузиться CPU
 standby 4 ip 1.1.1.1 - Конфигурируем виртуальный HSRP адрес
 standby 4 timers 1 3
 standby 4 priority 200 - Делаем этот маршрутизатор Active
 standby 4 preempt
 bfd interval 50 min_rx 50 multiplier 4 - поднимаем BFD
end

 router bgp 100
  bgp log-neighbor-changes
  bgp dampening
  network 1.1.1.0 mask 255.255.255.255
  neighbor 1.1.1.2 remote-as 100 - формируем iBGP сессию
  neighbor 1.1.1.2 next-hop-self  - при пересылке маршрутов на 1.1.1.2 менять значение next-hop на свой адрес. По умолчанию для iBGP сессий этого не происходит.
  neighbor 1.1.1.2 soft-reconfiguration inbound - сохраняет все полученные от соседа маршруты в памяти, что позволяет применять различные фильтры на входящие апдейты от соседа без переустановки bgp сессии, а также видеть результаты крайне полезной команды show ip bgp neighbors Х.Х.Х.Х received-routes
  neighbor 1.1.1.2 prefix-list DEFAULT_ROUTE in - на вход от CE2 разрешаем только дефолт
  neighbor 1.1.1.2 prefix-list NOTHING out - и ничего не отправляем на CE2
  neighbor 3.3.3.2 remote-as 300 - формируем eBGP сессию
  neighbor 3.3.3.2 fall-over bfd - функция обеспечивает быструю сходимость протокола BGP. Необходимо настраивать на обоих маршрутизаторах, участвующих в сессии. Устанавливается двусторонняя UDP сессия. Поскольку нагрузку на CPU почти не дает,  интервалы обмена сообщениями могут быть очень маленькими, от 50 мс. Таким образом, при пропадании доступности соседнего IP hop BGP сессия рвется сразу, не выдерживая таймаута в 3 минуты.
 Для настройки BFD сессии между маршрутизаторами, находящимися на расстоянии через 1 и более IP узлов, например, multihop eBGP или iBGP с промежуточным маршрутизатором между соседями, требуется multihop BGP feature, доступная только с версии 15.1(3)S.
  neighbor 3.3.3.2 soft-reconfiguration inbound - сохраняет все полученные от соседа маршруты в памяти, что позволяет применять различные фильтры на входящие апдейты от соседа, а также видеть результаты крайне полезной команды show ip bgp neighbors Х.Х.Х.Х received-routes
  neighbor 3.3.3.2 prefix-list OUR_PI out - анонсируем только свои PI адреса, дабы не превратиться в транзитную систему.
  no auto-summary

ip prefix-list OUR_PI seq 5 permit 1.1.1.0/24

ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0

ip prefix-list NOTHING seq 5 deny 0.0.0.0/0

CE2:

Практически все то же самое

interface FastEthernet0/0
 ip address 1.1.1.2 255.255.255.0
 no ip redirects
 bfd interval 50 min_rx 50 multiplier 4
 standby 4 ip 1.1.1.1
 standby 4 timers msec 500 1
 standby 4 preempt

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 bgp dampening
 network 1.1.1.0 mask 255.255.255.0
 neighbor 1.1.1.3 remote-as 100
 neighbor 1.1.1.3 next-hop-self
 neighbor 1.1.1.3 soft-reconfiguration inbound
 neighbor 1.1.1.3 prefix-list NOTHING in - ничего не берем с CE1
 neighbor 1.1.1.3 prefix-list DEFAULT_ROUTE out - отправляем на CE1 только дефолт
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 fall-over bfd
 neighbor 2.2.2.2 soft-reconfiguration inbound
 neighbor 2.2.2.2 prefix-list DEFAULT_ROUTE in - принимаем от ISP2 только дефолт
 neighbor 2.2.2.2 prefix-list OUR_PI out - отправляем только свои PI адреса, чтобы избежать транзита
 neighbor 2.2.2.2 route-map AddASnumbers out - добавляем дополнительные экземпляры номера своей AS для того, чтобы сделать этот маршрут менее предпочтительным для обратного трафика
 no auto-summary

ip prefix-list OUR_PI seq 5 permit 1.1.1.0/24

ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0

ip prefix-list NOTHING seq 5 deny 0.0.0.0/0

route-map AddASnumbers permit 10
 set as-path prepend 100 100 100 100

Как это работает:

В тестовых целях на ISP1 подняты Loopback 1-3 (которые анонсируются по BGP) для имитации Full View,   Loopback0 (который не анонсируется) для тестирования маршрута по умолчанию. На ISP2 поднят Loopback0(анонсируется). Кроме того, на ISP прописан статикой маршрут до 99.99.99.99. Тестовая рабочая станция в AS100 имеет адрес 1.1.1.112.

1. Нормальный режим.

Исходящие пакеты
В штатном режиме  исходящие пакеты будут всегда попадать на CE1 (HSRP Active). При наличии маршрута в full view, они уйдут на ISP1, иначе уйдут через default route, полученный с CE2,  на CE2 и оттуда на ISP2.

Проверка:
 Основной трафик c хоста в локальной сети AS100

Tracing the route to  66.66.66.66 

  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  66.66.66.66

Проверка дефолта c хоста в локальной сети AS100
Tracing the route to  99.99.99.99
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  1.1.1.2
  3    <1 мс    <1 мс    <1 мс  2.2.2.2
  4    <1 мс    <1 мс    <1 мс  99.99.99.99


Входящие пакеты
 Большая часть трафика возвращается через основной канал ISP, поскольку CE2 при анонсе маршрута  дополнительно вставляет в атрибут as-path несколько  номеров своей AS, таким образом влияя на принятие решения о выборе лучшего маршрута маршрутизаторами за пределами своей AS (AS100). Однако, это влияние не может быть абсолютным и администраторы других AS могут применять политику маршрутизации, не учитывающую длину AS PATH, таким образом некоторая часть трафика может возвращаться через запасного провайдера ISP2.

Проверка:
Большинство пакетов с маршрутизатора ISP2

Tracing the route to 1.1.1.112
  1 4.4.4.1 0 msec 4 msec 0 msec
  2 3.3.3.1 0 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 0 msec 0 msec 0 msec

2. Падение интерфейса F0/0 маршрутизатора CE1 

Исходящие пакеты
Виртуальный адрес HSRP будет перехвачен маршрутизатором CE2 и затем уйдут по дефолту на ISP2.

Проверка:

C хоста в локальной сети AS100 

Tracing the route to 66.66.66.66

  1    <1 мс    <1 мс    <1 мс  1.1.1.2
  2    <1 мс    <1 мс    <1 мс  2.2.2.2
  3    <1 мс    <1 мс    <1 мс  66.66.66.66

Входящие пакеты

Проверка:

С маршрутизатора ISP1 

ISP1#traceroute 1.1.1.112

  1 4.4.4.2 0 msec 0 msec 0 msec
  2 2.2.2.1 4 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 4 msec 0 msec 0 msec

3.Падение F0/1  на CE1 или F0/1 на ISP1

Исходящие пакеты
При падении F0/1  на CE1 или F0/1 на ISP1  пакеты приходят сначала на CE1, потом с него на CE2, потом на ISP2. Для ускорения переключения CE1 на дефолтный маршрут между ISP1 и CE1 поднята BFD сессия и BGP настроен реагировать на ее состояние.

Проверка:

C хоста в локальной сети AS100 
Tracing the route to  66.66.66.66
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  1.1.1.2
  3     1 ms    <1 мс    <1 мс  2.2.2.2
  4    <1 мс    <1 мс    <1 мс  66.66.66.66





Входящие пакеты

Проверка: 
С маршрутизатора ISP1   
Tracing the route to 1.1.1.112
  1 4.4.4.2 0 msec 4 msec 0 msec
  2 2.2.2.1 0 msec 4 msec 0 msec
  3 1.1.1.112 [AS 100] 0 msec 4 msec 0 msec


4. Падение F0/0, F9/1 на CE2 или F0/1 на ISP2.

Исходящие пакеты
При падении любого из интерфейсов CE2 или F0/1 на ISP2 начинают теряться только те пакеты, маршрут к которым отсутствует в Full View на CE1.

Проверка:

Основные маршруты с хоста в локальной сети AS100 
Tracing the route to  66.66.66.66
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2    <1 мс    <1 мс    <1 мс  66.66.66.66


Маршрут по умолчанию с хоста в локальной сети AS100 
Tracing the route to  99.99.99.99
  1    <1 мс    <1 мс    <1 мс  1.1.1.3
  2  1.1.1.3  сообщает: Заданный узел недоступен.
 

Входящие пакеты

Проверка:
С маршрутизатора ISP2  

Tracing the route to 1.1.1.112
  1 4.4.4.1 0 msec 0 msec 4 msec
  2 3.3.3.1 0 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 0 msec 4 msec 0 msec



Troubleshooting

1. Быстро посмотреть настройку BGP  в конфиге:
R#show running-config | section bgp



2. Посмотреть состояние BGP сессий:
R#show ip bgp summary

3. Посмотреть на список BGP маршрутов, получаемых от конкретного соседа:
R#show ip bgp neighbors 4.4.4.1 received-routes

4. Посмотреть список маршрутов от  конкретного соседа после применения всех фильтров:
R#show ip bgp neighbors 4.4.4.1 routes

5. Посмотреть список маршрутов, анонсируемых конкретному соседу:
R#show ip bgp neighbors 4.4.4.1 advertised-routes

6. Посмотреть таблицу BGP маршрутов на маршрутизаторе
R#show  ip bgp

7. Посмотреть таблицу маршрутизации
R#show ip route


8. Посмотреть состояние HSRP
R#show standby

9. Посмотреть состояние BFP
R#show bfd neighbors