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

Мониторинг трафика на маршрутизаторе Cisco в реальном времени

Самым удобным способом  отслеживания трафика на интерфейсах маршрутизатора в реальном времени является  настройка Netflow. 

Справка из википедии:

  

NetFlow — сетевой протокол, предназначенный для учёта сетевого трафика, разработанный компанией Cisco Systems. Является фактическим промышленным стандартом и поддерживается не только оборудованием Cisco, но и многими другими устройствами (в частности, Juniper и Enterasys). Также существуют свободные реализации для UNIX-подобных систем.

Для сбора информации о трафике по протоколу NetFlow требуются следующие компоненты:

1. Сенсор. Собирает статистику по проходящему через него трафику. Обычно это L3-коммутатор или маршрутизатор, хотя можно использовать и отдельно стоящие сенсоры, получающие данные путем зеркалирования порта коммутатора.

2. Коллектор. Собирает получаемые от сенсора данные и помещает их в хранилище.

3. Анализатор. Анализирует собранные коллектором данные и формирует пригодные для чтения человеком отчёты (часто в виде графиков).

Маршрутизатор в данных терминах  будет сенсором Netflow, а без коллектора и анализатора можно обойтись, если нам не нужно хранить данные и  делать развесистые отчеты.

Настройка проста:

1. Обе команды можно выполнить или в глобальном режиме или в режиме конфигурации интерфейса.

  ip flow ingress - собирает статистику по входящему трафику

  ip flow egress  - собирает статистику по исходящему трафику

2. Настройка примитивного отчета в глобальном режиме.

  ip flow-top-talkers
   top 30
   sort-by bytes
   cache-timeout 30000

3. Настроим таймеры  в глобальном режиме:

   ip flow-cache timeout inactive 10
   ip flow-cache timeout active 5

После этого командами

show ip flow top-talkers

sh ip cache flow

можно увидеть наиболее активные хосты и типы трафика.

Если есть необходимость хранить историю загрузки и выводить красивые отчеты для начальства, можно воспользоваться  таким инструментом, как PRTG.

Автоматический Backup конфигурации в маршрутизаторах Cisco

Настроить автоматическое (по таймеру, допустим раз в неделю) сохранение конфигурации маршрутизатора Cisco на tftp или ftp сервер можно:

1. Повесив на крон выполнение команды «show run» с редиректом.

1.Сначала определим, ЧТО хотим делать.
kron policy-list Backup
     cli show run | redirect tftp://10.10.10.10/Cisco_autobackup.conf

2. Потом обозначим ПЕРИОДИЧНОСТЬ, с которой будем выполнять действие.
kron occurrence Backup at 23:00 Sun recurring
     policy-list Backup




Если хотим бэкапить по ftp, то возможны проблемы. На некоторых версиях IOS  есть баг, в результате которого при редиректе на ftp создаются файлы нулевой длины.

R(config)#file prompt quiet -- чтобы маршрутизатор не задавал лишних вопросов.

Чтобы этого избежать, можно переписать задание так:

R(config)#kron policy-list Backup
R(config-kron-policy)#cli write

R(config-kron-policy)#cli copy startup-config ftp://user:password@10.10.10.10/Cisco_autobackup.conf
R(config-kron-policy)#exit


2. С помощью настройки archive:

1. Определим параметры коннекта:

R(config)#ip ftp username user

R(config)#ip ftp password password
R(config)#ip ftp source-interface fastEthernet 0/0 - если есть какие-то ограничения по IP

2. Настроим archive
R(config)#archive
R(config-archive)#path ftp://10.10.10.10/cisco/R_autobackup.conf
R(config-archive)#time-period 10080 -- раз в неделю.




 

Фиксация и определение номера интерфейса в IOS

При использовании систем управления удобно иметь возможность ссылаться на интерфейсы по номеру, который сохраняется даже после перезагрузки устройства. Начиная с Cisco IOS Release 12.1(5) эту возможность обеспечивает Interface Index Persistence feature.

Для включения данной функциональности нужно выполнить либо глобальную команду:

R(config)# snmp-server ifindex persist

Либо локальную на интерфейсе:

R(config)# interface type slot/port
R(config-if)# snmp ifindex persist

Определить номер интерфейса можно командой
R# show snmp mib ifmib ifindex type slot/port 

===============================
Useful links
Cisco SNMP Object Navigator