Протокол bfd – Cisco ASR 9000 Series Aggregation Services Router Routing Configuration Guide, Release 4.3.x — Implementing BFD [Cisco IOS XR Software (End-of-Sale)]

alexxlab

Коротко о BFD | Netwild.ru

Коротко о BFD.

Все более важной особенностью сетевого оборудования становится быстрое обнаружение неисправности связи между смежными системами, в целях более быстрого создания альтернативных путей. Есть ситуации, когда используемые протоколы маршрутизации не сразу обнаруживают нарушение смежности, в результате чего, при большой нагрузке на сеть, подобная «неторопливость» может сказаться на качестве сервиса. Bidirectional Forwarding Detection (BFD) – это протокол, работающий поверх других протоколов, позволяющий сократить время обнаружения  проблемы до 50мс. BFD является двусторонним протоколом, т.е. требует настройки  обоих маршрутизаторов (Оба генерируют BFD пакеты и отвечают друг-другу). Рассмотрим на примере, когда может возникнуть эта «неторопливость».

Допустим, у нас есть 2 маршрутизатора, соединенные прямым линком.

Рис 1.

Обрыв линка приведет к падению интерфейса, в результате чего оба маршрутизатора быстро обнаружат проблему и удалят недействительные маршруты. Однако,  роутеры не всегда соединены прямым линком. Очень часто, например, на интернет площадках (IX), соединение происходит через промежуточный коммутатор.

Рис 2.

В данном случае, при падении линка между вторым роутером и коммутатором это  не будет обнаружено первым роутером. Именно в таком случае удаление маршрута из таблицы маршутизации будет зависеть от настроек используемого протокола. Например, если взять протокол BGP, то это время может достигать 2-х минут.

Как работает протокол BFD.

Каждый из смежных маршрутизаторов, на которых настроен протокол BFD, периодически посылает «Hello» сообщения своему соседу. Получение данного сообщения означает работоспособность канала в одном определенном направлении, неполучение «Hello» сообщения говорит о неработоспособности канала, что и фиксирует протокол BFD. По умолчанию, на неработоспособность канала указывают 3 подряд не полученных  пакета «Hello». Количество пакетов и их интервал отправки может быть изменен при конфигурации протокола.

 

Настройка BFD на Juniper MX

Наверное, это самое простое, что вам приходилось в жизни настраивать.

Т.к. потребность в BFD возникает в основном при использовании протокола BGP, настроим BFD поверх BGP.

Для того, чтобы включить его работу, надо вбить команду:

[edit protocols bgp group <Имя Группы>]

shamash@host:X# set bfd-liveness-detection minimum-interval 1000

 

Здесь мы устанавливаем минимальный интервал в милисекундах, при котором маршрутизатор передает «Hello» пакеты.

Для того, чтобы проверить, работает ли протокол:

shamash@host:X> show bgp neighbor | match bfd
Options: <BfdEnabled>
  BFD: enabled, up
  Trace file: /var/log/A/bgp-bfd size 131072 files 10
  Options: <BfdEnabled>
  BFD: enabled, up
  Trace file: /var/log/A/bgp-bfd size 131072 files 10

Чтобы протокол заработал, требуется, чтобы на смежных маршрутизаторах интервал отправки hello-пакетов совпадал.

Включение лога для диагностики:

[edit protocols bgp group <Имя Группы>]
shamash@host:X # set traceoptions file bgp-bfd
shamash@host:X # set traceoptions flag bfd detail

В итоге должно получиться что-то типа этого:

shamash@host:X# show protocols
    bgp {
         group <Имя Группы> {
               type internal/external;
               traceoptions {
                     file bgp-bfd;
                     flag bfd detail;
               }
               local-address <Ip-Adress>;
               export <Политика на экспорт>;
               import <Политика на Импорт>;
               bfd-liveness-detection {
                     minimum-interval 1000;
               }
               neighbor <Ip-Adress>;
               neighbor <Ip-Adress>;
        }
    }

Также следует отметить, что для работы bfd должны быть открыты порты 3785, 3784, 4784, соответственно, если у вас настроен firewall, то надо их открыть:

term BFD {
    from {
        protocol [ udp tcp ];
        port [4784 3785 3784  ];
    }
    then accept;
}

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

ПРИМЕНЕНИЕ ПРОТОКОЛА BFD И PATH PROTECTION В MPLS TE

В продолжение статьи: “Применение VPLS Martini в MPLS TE” [1], будут рассмотрены способы обеспечения надежности и быстрой сходимости на сети, например, при выходе из строя промежуточного оборудования или обрыва линий.

Использование MPLS TE хорошо зарекомендовало себя на сети. Протокол MPLS является удобным для формирования VPN, который повышает безопасность и масштабируемость сети. Технология Traffic Engineering совмещает использование протоколов уровней L2 и L3[2], что позволяет применять такие протоколы, как BFD (Bidirectional Forwarding Detection), RRPP (Rapid Ring Protection Protocol — похож на протокол STP). Также MPLS TE поддерживает две опции для повышения стабильности и уменьшения времени сходимости — это Path Protection и Local Protection. Указанные протоколы обеспечивают высокую оперативность в выявлении проблем на сети и в быстром перестроении маршрутов. В данной статье будут рассмотрен протокол BFD и опция Path Protection.

Первое что рассмотрим – Path Protection (Защита пути). Основным преимуществом является контроль над каналом, который был построен по основному маршруту (Primary LSP), в случае обрыва или выхода из строя маршрутизатора осуществляется перенаправление трафика на заранее созданный резервный маршрут (Secondary LSP). Резервный маршрут также можно разделить на два состояния[3]:

  1. Standby — всегда наготове: путь заранее вычислен и LSP сигнализирован.
  2. Non-standby — путь заранее вычислен, но LSP не сигнализирован.

Сигналом того, что Primary LSP путь больше не функционирует, будет поступление уведомления от RSVP-TE или BFD (протокол BFD рассмотрен ниже).

Коротко о RSVP TE — (Resource ReSerVation Protocol в Traffic Engineering): он позволяет строить основной и резервный LSP маршрут, резервировать ресурсы на всех узлах, обнаруживать аварии на сети, строить заранее обходные пути, делать быстрое перенаправление трафика (Best Effort) [4].

Рассмотрим сеть, изображенную на рисунке 1, где используется: R1, R4 (Provider Edge), R2,R3,R5…R8, (Provider), CE1 – CE2, (Customer Edge).

 

Рисунок 1. Схема сети

 

Для настройки Path Protection необходимо произвести базовые конфигурации по примеру предыдущей статьи, в которой был настроен Martini VPLS.

Для создания явного маршрута используется команда explicit-path path-name, next hop ip-address [ include [ strict | loose ] | exclude ] – указывает путь следующего прыжка, используется IP адрес интерфейса. Количество созданных направлений не ограниченно. Для удобства рекомендуется выбирать аналогичный обратный маршрут, при создании явного маршрута. [5]

При настройке туннеля необходимо добавить командой созданный ранее маршрут: mpls te path explicit-path path-name, тем самым указывается путь основного канала, для организации резервного пути создается дополнительный маршрут и применяется командой: mpls te path explicit-path path-name secondary, при этом необходимо прописать mpls te backup { hot-standby [ wtr interval ] | ordinary } – что заранее сконфигурирует режим резерва CR-LSP. На рисунке 2 изображен пример вывода команды display explicit—path lsp—attribute, он показывает, что создан основной и резервный путь и какие используются интерфейсы. [5]

 

Рисунок 2. Вывод команды explicit-path lsp-attribute

 

Если произойдет сбой, как на основном, так и на резервном CR-LSP маршруте, то необходимо задать дополнительные настройки туннеля для построения резервного динамического пути командой: mpls te backup ordinary best-effort. В результате получаем основной канал и два резервных маршрута: статический и динамический, как показано на рисунке 3.

 

Рисунок 3. Распределение основного и резервных маршрутов

 

Для проверки конфигурации используем команду display mpls te hot-standby state {all [verbose] | interface tunnel interface-number}[5], что позволяет посмотреть: в каком состоянии находится туннель Primary LSP, Hot-standby LSP или Best-Effort LSP.

Следующее что мы рассмотрим, это протокол BFD (Bidirectional Forwarding Detection) – сетевой протокол, используемый для быстрого обнаружения неисправностей.

Принцип работы: два устройства согласовывают и устанавливают BFD сессию, отправляя друг другу hello-сообщения. Если hello-сообщения перестают поступать от соседа, BFD-сессия разрывается и система оповещается о неполадках, например, оповещает протокол маршрутизации, и после этого протокол маршрутизации может предпринять необходимое действие. BFD может определить неисправность линка менее чем за 1 секунду. Также преимуществом BFD является возможность обнаружить неисправность для статических маршрутов[6]. Поддерживаемые протоколы OSPF, IS-IS, RIP, BGP, RSVP, PIM.

Рассмотрим применение данного протокола. В уже имеющуюся сеть добавим коммутатор, как показано на рисунке 3. На LSW1 настроем интерфейсы в сторону GE 0/0/1 и GE 0/0/2 в режиме trank, пропуская все метки vlan. Первоначальные конфигурации (настроенные выше) остаются неизменны.

Допустим такой случай: произошел обрыв между LSW1 и R2, как показано на рисунке 4. Маршрутизатор R1 не фиксирует пропадания связи с коммутатором LSW1 и продолжает слать пакеты в сторону LSW1, коммутатор добросовестно принимает пакеты и, не зная куда их отправлять, отбрасывает.

 

Рисунок 4. Обрыв кабеля между LSW1 и R2

 

Во избежание данной проблемы применяется протокол BFD. BFD является двусторонним протоколом, т.е. требует настройки обоих маршрутизаторов (оба генерируют BFD пакеты и отвечают друг другу). [6]

Для включения протокола BFD на маршрутизаторе потребуется:

  1. Включить протокол BFD глобально: в режиме конфигурирования команда: bfd.
  2. Привязать bfd сессию на LSP маршруте: для этого необходима команда: bfd cfg-name bind mpls-te interface tunnel interface-number te-lsp [ backup ].
  3. Команда: discriminator local discr—value указывает локальный дискриминатор.
  4. Команда: discriminator remote discr-value указывает удаленный дискриминатор.

После того как установили дискриминаторы, необходимо убедится, что локальный дискриминатор на локальном конце совпадает с удаленным дискриминатором на другом конце; в противном случае сеанс BFD не подымится.

  1. Команда: min-tx-interval interval минимальный интервал отправленных пакетов.
  2. Команда: min-rx-interval interval минимальный интервал принятых пакетов.
  3. Команда: detect-multiplier multiplier указывает на локальный множитель. По умолчанию локальный множитель обнаружения равен 3. [5]

После поднятия сессий BFD между маршрутизаторами, командой display bfd session all, можно проверить его состояние. При State – UP, протокол BFD проблем не фиксирует. После обрыва линка на участке LSW1 и R2, протокол BFD фиксирует пропадание связи, не получая hello-сообщения, тем самым состояние сессий изменяется на, State – Down. В таком случае будет изменен маршрут с основного на резервный (пример рисунок 3).

Команды для проверки:

display bfd configuration mpls—te interface tunnel interface—number [verbose] для проверки конфигураций BFD на туннеле

display bfd statistics session mpls—te interface tunnel interface-number te-lsp чтобы проверить статистику сеанса BFD, который обнаруживает ошибки в CR-LSP.[5]

 

Список литературы:

  1. Клименко К.В. ПРИМЕНИЕНИЕ VPLS MARTINI В MPLS TE. // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. LXIV междунар. студ. науч.-практ. конф. № 4(63). URL: https://sibac.info/archive/technic/4(63).pdf
  2. Введение в MPLS, TE и QoS. [электронный ресурс] — Режим доступа. — URL: http://book.itep.ru/4/4/mpls17.htm (дата обращения: 15.03.2018)
  3. Path protection. [электронный ресурс] — Режим доступа. — URL: https://en.wikipedia.org/wiki/Path_protection (дата обращения: 15.04.2018)
  4. MPLS Traffic Engineering [электронный ресурс] — Режим доступа. — URL:https://linkmeup.ru/blog/302.html#PATH-PROTECTION (дата обращения: 14.03.2018)
  5. Configuration Guide — MPLS Configuration. //Техническая документации — 2012. — [электронный ресурс] — Режим доступа.—URL: http://support.huawei.com/enterprise/en/doc/DOC1000009832?section=j001 (дата обращения: 05.04.2018)
  6. Bidirectional Forwarding Detection (BFD) [электронный ресурс] — Режим доступа. — URL: http:// http://blog.sbolshakov.ru/6-2-4-ha-bfd/ (дата обращения: 10.04.2018)

Применение протокола VRRP+BFD на L3 коммутаторах Raisecom ISCOM3048G-4C-PWR / Статьи / RAISECOM.SU

При выборе L3 коммутатора большое значение играют поддерживаемы механизмы обеспечения доступности сети. В частности, к таким механизмам относятся BFD и VRRP. В статье описывается настройка данных протоколов на L3 коммутаторах Raisecom ISCOM3048G-4C-PWR и ISCOM3024G-4C.

(BFD)Bidirectional Forwarding Detection protocol – протокол, предназначенный для быстрого обнаружения неисправных линков. При использовании протокола BFD два устройства устанавливают и согласовывают BFD сессию, обмениваясь hello-сообщениями. Если один из соседей обнаруживает, что hello-сообщения перестают поступать – BFD сессия разрывается. Стоит отметить, что протокол BFD может определить разорвавшийся линк менее чем за 1 секунду.

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

Про VRRP

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

Протокол VRRP объединяет несколько маршрутизаторов для создания группы резервного копирования. Путем настройки виртуального IP-адреса для группы резервного копирования можно настроить шлюз по умолчанию на виртуальный IP-адрес, чтобы устройства в локальной сети всегда обменивались данными с внешней сетью.

VRRP помогает повысить надежность сети, предотвращая прерывание соединения, вызванное сбоем одной из линий связи,  и предотвращает изменение настроек маршрутизации из-за сбоя связи.

Алгоритм настройки VRRP на коммутаторах Raisecom:      

 

VRRP с применением BFD

Для формирования сеанса протокол BFD требует, чтобы оба партнера, участвующие в сеансе BFD, знали IPv4 или IPV6-адрес своего партнера. Это создает уникальную проблему с использованием протокола VRRP, что делает использование BFD для IPv4 или IPv6 совместно с VRRP  более сложным. В VRRP только главный маршрутизатор отправляет Advert пакеты. Это означает, что master-маршрутизатор не знает о каких-либо резервных маршрутизаторах, а резервные маршрутизаторы знают только о главном маршрутизаторе. Это также означает, что любой резервный маршрутизатор не знает о других резервных маршрутизаторах в сети.

Поскольку BFD для IPv4 или IPv6 требует, чтобы сеанс формировался обоими узлами, использующими адрес назначения и адрес источника, должны быть некоторые внешние средства для предоставления этой информации BFD от имени VRRP. Как только информация об узлах становится доступной, VRRP может объединять сеансы BFD со своим виртуальным маршрутизатором. Сеанс BFD для данного виртуального маршрутизатора определяется как сеанс BFD критического пути. Данный сеанс формируется между текущим главным маршрутизатором VRRP и маршрутизатором резервного копирования с наивысшим приоритетом. Когда сеанс BFD критического пути переходит из состояния  Up в Down,  на маршрутизаторе с самым высоким приоритетом это будет интерпретироваться VRRP  как событие Master Down. Событие Master Down означает, что первичный узел резервного копирования сразу станет новым мастером для виртуального маршрутизатора.

При использовании VRRP+BFD применяется механизм, используемый протоколом VRRP для построения таблицы  узлов, которая поможет в формировании сеанса BFD и определении критического пути для BFD. Если сеанс BFD критического пути по какой-либо причине перестанет работать, он будет сигнализировать о событии Master Down и сделает  резервный маршрутизатор в качестве основного маршрутизатора VRRP.

В режиме работы  VRRP+BFD узлы изучают соседние маршрутизаторы и формируют сеанс BFD между изученными маршрутизаторами. Чтобы создать таблицу узлов, все маршрутизаторы отправляют пакеты VRRP Advert в любом из рабочих состояний (Master или Backup). Обычно  VRRP узлы отправляют Advert пакеты  только в состоянии «Master», однако в этом режиме резервные узлы  VRRP также будут отправлять Advert пакеты типа Backup Advertisement. Маршрутизатор VRRP Master по-прежнему будет продолжать отправлять Advert пакеты с типом Advertisement, как определено в протоколе VRRP. Это должно поддерживать совместимость  с узлами, соответствующими протоколу VRRP.

Про коммутатор ISCOM3048G(PWR)

 

Устройство ISCOM3048G(PWR) является управляемым L3 гигабитным коммутатором нового поколения.  Коммутатор может обеспечить гибкое решение для построения сети любой сложности за счет большого набора интерфейсов. ISCOM3048G(PWR) обладает высокой надежностью, широким набором функций  уровня защиты, а также прост в администрировании и настройке. Стоит отметить, что коммутатор полностью адаптирован под технологию OAM и совместим со стандартом CE2.0.

Коммутатор ISCOM3048G(-PWR) поддерживает различные IPv4/IPv6 unicast/multicast протоколами маршрутизации,  а также имеет возможность  работы с ISF(Intelligent Stacking framework technology). Обладая такими широкими возможностями, коммутатор может приняться при самых разнообразных сценариях построения сетей.

Главной особенностью Коммутатора  ISCOM3048G(-PWR) является наличие Gigabit Ethernet портов с поддержкой POE согласно стандартам 802.3af и 802.3at. Устройства серии ISCOM3000G-PWR  полностью поддерживают работу с  IPv4/IPv6 протоколами маршрутизации  RIP, OSPF, BGP.
Операторы связи могут с легкостью использовать коммутаторы данной линейки для построения гибких сетей с максимальным уровнем надежности и защиты. 

Стоит отметить, что оборудование серии ISCOM3000G-PWR может быть использовано при подключении точек доступа, а также высокопроизводительных IP-камер. 
 

 

Пример настройки VRRP+BFD на коммутаторах модели ISCOM3048G.

Настройка VRRP на интерфейсе gigaethernet 1/1/2: 

Настройка BFD на этом же интерфейсе: 

Проверка настроек VRRP на коммутаторе:

 

Steinkäfer: BFD und BGP. Cisco

Bidirectional Forwarding Detection (BFD) — протокол, позволяющий быстро обнаруживать проблемы связности маршрутизаторов на IP уровне и тем самым обеспечивающий быструю сходимость протоколов маршрутизации.
BFD — двусторонний протокол, оба маршрутизатора генерируют BFD пакеты, а также отвечают на BFD пакеты посланные соседом. Протокол BFD практически не влияет на производительность CPU, поэтому интервал между BFD пакетами может быть сокращен до 50 мс, что обеспечивает быструю сходимость.

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 пакетов).
Пример:
Маршрутизаторы, соединенные непосредственно друг с другом, быстро обнаруживают проблему. Падение интерфейса на одном конце мгновенно будет обнаружено соседом на противоположном, что приведет к оперативному удалению недействительного маршрута из таблицы маршрутизации. Однако, ситуация меняется, если между маршрутизаторами появляется коммутатор. При падении интерфейса между одним маршрутизатором и коммутатором, второй маршрутизатор не видит падения интерфейа первого маршрутизатора. Удаление недействительного маршрута полностью зависит от таймеров используемого протокола маршрутизации (до 3 минут у BGP).
Настройка производится на обоих маршрутизаторах:
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
eighbor 3.3.3.2 fall-over bfd
Также возможна привязка статического маршрута к BFD сессии.
В результате при обнаружении падения BFD сессии (несколько сотен миллисекунд), маршрутизатор разрывает BGP сессию и оперативно удаляет недействительные маршруты из таблицы маршрутизации.
Troubleshooting
show bfd neighborsshow
bfd neighbors details

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

http://ciao-cacao.blogspot.ru/2011/12/bgp-bfd.html

Cisco Howto: 2011

Задача:

Имеются собственные 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   
  2   
  3   

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

Проверка:

С маршрутизатора 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   
  2   

Маршрут по умолчанию с хоста в локальной сети 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

Cisco Howto: декабря 2011

Задача:

Имеются собственные 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   
  2   
  3   

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

Проверка:

С маршрутизатора 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   
  2   

Маршрут по умолчанию с хоста в локальной сети 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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *