Какое сообщение в состоянии openconfirm ожидает bgp система для перехода в состояние established

Обновлено: 05.07.2024

5. Определение состояния соседских отношений в BGP

После установления TCP сессии приложение BGP пытается установить сессию с соседом. Должно пройти несколько шагов перед установлением этой сессии.

Состояния, через которые два маршрутизатора проходят при установлении BGP сессии, можно с помощью команд debug. В версии Cisco IOS 12.4 и выше используется команда debug ip bgp ipv4 unicast, а в более ранних версиях – debug ip bgp events. Команды debug используют много ресурсов маршрутизатора, поэтому их надо включать только по необходимости.

- он ожидает, что внутренний протокол маршрутизации узнает об этой сети с помощью анонса от другого маршрутизатора

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

Одной из команд проверки соседских отношений является команда show ip bgp summary. На рисунке показана информация, выводимая этой командой.

Main routing table version – последняя версия таблицы BGP, которая была внедрена в таблицу маршрутизации

Neighbor – IP адреса, которые используются в команде neighbor, с которыми маршрутизатор имеет соседские отношения

Up/Down – промежуток времени, в течение которого сосед находится в текущем BGP состоянии (established, active или idle).

State (established, active, idle, open sent, open confirm, idle [admin]) – состояние BGP. Сосед может быть административно выключен командой neighbor shutdown.

6. Аутентификация в BGP

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

Для включения MD5 аутентификации на TCP соединении между двумя BGP соседями используется команда меню настройки маршрутизации neighbor password string.

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

Если ключ аутентификации будет установлен неправильно, BGP сессия не будет установлена. Поэтому рекомендуется внимательно вводить пароль, а также проверять установление сессии после настройки аутентификации.

Если группа BGP соседей определена использованием аргумента peer-group-name, все члены группы будут наследовать характеристики, настроенные этой командой.

Если пароль или ключ MD5 аутентификации между двумя соседями с настроенной аутентификацией изменить, локальный маршрутизатор не будет завершать существующую сессию сразу после смены пароля. Он попробует поддержать сессию с новым паролем пока не истечет BGP hold-down таймер. По умолчанию этот период составляет 180 секунд. Если пароль на удаленном маршрутизаторе не будет изменен до истечения hold-down nfqvthf, сессия будет завершена.

Настройка нового значения hold-down таймера будет иметь эффект только после сброса текущей сессии. Нет возможности поменять это значение без сброса сессии.

На рисунке показан пример настройки MD5 аутентификации для BGP сессии между маршрутизаторами R1 и R2. Одинаковые пароли должны быть настроены на маршрутизаторах до окончания Hold-таймера.

7. Пример активации базовой конфигурации BGP

На рисунке показан еще один пример BGP, который включает все базовые настройки BGP. Маршрутизатор R1 имеет одного внешнего EBGP соседа, R2 имеет одного внешнего EBGP и одного внутреннего IBGP соседа, а R3 – одного внутреннего IBGP соседа. На рисунке показана конфигурация R1 и R2, вместе с которой будут даны пояснения необходимых базовых настроек для создания внешних и внутренних BGP отношений.

Команда router bgp 65010 указывает, что локальный номер автономной системы 65010. Первая подкоманда описывает соседей, с которыми устанавливаются соседские отношения, указывается их IP адреса и номера автономной системы. У R2 есть два соседа. С точки зрения R2 маршрутизатор R1 – EBGP сосед, а R3 – IBGP сосед. Подкоманда neighbor на маршрутизаторе R2 для R1 указывает на адрес прямого соединения R1. Кроме того, подкоманда neighbor на маршрутизаторе R2 для R3 указывает на адрес Loopback интерфейса R3, т.к. R2 имеет несколько путей для достижения R3. И если на маршрутизаторе R2 указать адрес R3 192.168.3.2, то при падении интерфейса маршрутизатор R2 не сможет переустановить сессию до момента подъема интерфейса. При указании Loopback интерфейса сессия BGP будет оставаться работоспособной до тех пор, пока будет доступен хотя бы один путь от R2 к R3.На маршрутизаторе R3 также надо указывать адрес Loopback интерфейса маршрутизатора R2. Также на R2 включена аутентификация для связи с R1 и указан пароль, такой же, как и в конфигурации на R1.

Команда neighbor 192.168.2.2 update-source Loopback 0 указывает маршрутизатору R2 всегда использовать адрес интерфейса Loopback 0 как адрес источника при отправке обновлений маршрутизатору R3. Маршрутизатор R2 также меняет адрес следующего шага для сетей, доступных через него. По умолчанию, адрес следующего шага для сетей из автономной системы 65020 – 10.1.1.2. С помощью команды next-hop-self маршрутизатор R2 устанавливает адрес следующего шага адрес своего Loopback 0 интерфейса.

Три команды network указывают на сети, которые надо распространять через BGP. Первая – подсеть класса В с маской подсети. А вторая и третья – две сети класса С, подключенные к R2 и R3. По умолчанию у этих сетей маска 255.255.255.0, поэтому нет необходимости включать маску в команду.

На рисунке показан частичный вывод этой команды. Коды статуса показуются в начале каждой строки, а коды происхождения – в конце строки. В большинстве строк в первой колонке стоит звездочка (*). Это означает, что адрес следующего шага (в пятой колонке) правильный. Адрес следующего шага это не всегда маршрутизатор, имеющий прямое соединение с текущим. Другие варианты значений статуса, которые могут быть в первой колонке, следующие:

- S – suppressed, показывает, что какой-то маршрут подавлен (обычно, когда используется суммирование маршрутов, отправляется только суммарный маршрут).

- D – dampening, показывает, что на маршрут был наложен штраф из-за частого падения и появления. Хоть маршрут может быть правильным в данный момент, он не будет распространяться, пока не истечет время штрафа.

- Н – history, показывает, что маршрут недоступен, историческая информация о маршруте имеется, но лучший путь не существует.

- R – сбой базы с информацией о маршрутах (RIB), показывает, что маршрут не был помещен в RIB. Причину, по которой это произошло, можно узнать с помощью команды show ip bgp rib-failure, которая показана на следующем рисунке.

Колонка Next Hop содержит все адреса следующего шага для каждого маршрута. Эта колонка может содержать запись 0.0.0.0, что означает, данный маршрутизатор является источником маршрута.

Три колонки левее колонки Path показывают три атрибута BGP пути: метрика (Multi-exit discriminator – MED), локальные предпочтения (local preference) и вес.

Колонка с заголовком Path может содержать последовательность автономных систем в пути. Первый слева номер указывает на автономную систему, от которой эта сеть была изучена. Крайний правый номер – автономная система – источник или хозяин этой сети. Номера автономных систем между этими двумя номерами представляют точный путь из автономных систем, через которые необходимо будет пройти пакету, чтобы достигнуть начальную автономную систему. Если колонка Path пуста, значит сеть принадлежит текущей автономной системе.

Команда show ip bgp rib-failure используется для отображения BGP маршрутов, которые не были добавлены в базу данных RIB, а также причины, по которой это не произошло.

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

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

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

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

Сброс сессии – это метод информирования соседа или соседей об изменении политики. Если BGP сессии сбрасывается, вся информация, полученная в этой сессии, считается недействительной и удаляется из таблицы BGP. Также, удаленный сосед, который обнаружит сессию в выключенном состоянии, удалит всю информацию, полученную в этой сессии. Через 30-60 секунд BGP сессия переустановится автоматически, и BGP таблицы будут обменяны между соседями, но уже через новые фильтры. Кроме того, сброс BGP сессии нарушает пересылку пакетов.

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

Команда clear ip bgp * приведет к тому, что вся информация из таблицы BGP будет удалена, и маршрутизаторы необходимо будет заново изучать информацию от всех соседей. Если маршрутизатор имеет много соседей, это действие может привести к очень сложной ситуации.Эта команда заставит всех соседей отправлять свою информацию одновременно.

Напрмер, в ситуации, когда маршрутизатор R1 имеет восемь соседей и каждый сосед имеет полную базу данных интернета размером 32 Мб. Если на маршрутизаторе R1 применить команду clear ip bgp , все восемь соседей будут отправлять 32 Мб информации одновременно. Для хранения всех этих обновлений, маршрутизатор R1 должен иметь 256 Мб оперативной памяти. Также он должен суметь обработать всю эту информацию. Обработка этой информации может забрать большое количество ресурсов процессора, что приведет к задержке машрутизации пользовательских данных.

Вторая команда, которую можно применить вместо первой, это clear ip bgp 10.1.1.2. Она позволяет сбрасывать сессию только с одним выбранным соседом. Влияние от применения этой команды на трафик и ресурсы маршрутизатора будет меньше, но изменение политики для всех маршрутизаторов будет идти дольше, так как необходимо сбрасывать BGP сессии для каждого соседа в отдельности.

Опция soft out команды clear ip bgp заставляет BGP делать программный сброс исходящих обновлений. Маршрутизатор, на котором введена команда clear ip bgp soft out не сбрасывает BGP сессию, вместо этого он создает новое обновление и отправляет всю таблицу определенному соседу.

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

Слово soft в этой команде является опциональным и его можно не указывать, команда clear ip bgp out сделает программный сброс для исходящих обновлений.

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

С помощью команды neighbor 10.1.1.2 soft-reconfiguration inbound происходит требуется от BGP сохранить все обновления, изученные от определенного соседа. BGP маршрутизатор сохраняет нефильтрованную таблицу обновлений, посланных соседом.

При изменении входящей политики используется команда clear ip bgp in. Сохраненная нефильтрованная таблица используется для генерации новых входящих обновлений, новые результаты заносятся в базу данных BGP. Таким образом, при изменении входящей политики нет необходимости требовать от соседа отправки всей своей таблицы BGP.

В версии Cisco IOS 12.0 представлено улучшение функции программного сброса BGP, также известного как обновление маршрутов, которое предоставляет автоматическую поддержку динамического программного сброса таблицы входящих BGP обновлений и не зависит от сохраненной таблицы обновлений. Команда clear ip bgp soft in реализует эту функцию. Этот метод не требует предварительной настройки и требует значительно меньше памяти, чем предыдущий метод программного сброса для входящих таблиц обновлений.

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

Если все маршрутизаторы поддерживают обновление маршрутов, используется команда clear ip bgp in. Нет необходимости использовать слово soft, так как программный сброс автоматически будет запущен, когда маршрутизатор поддерживает функцию обновления маршрутов.

Когда происходит сброс BGP сессии и используется программная реконфигурация, есть несколько команд, позволяющих мониторить, как маршруты получаются, отправляются или фильтруются.
Можно использовать следующие команды:
- show ip bgp naighbor address recieved
- show ip bgp neighbor address routes
- show ip bgp
- show ip bgp neighbor address advertised

На рисунке выше представлен частичный вывод информации после ввода команды debug ip bgp updates на маршрутизаторе R1 после выполнения команды clear ip bgp, в результате которой произошел сброс BGP сессии с соседом 10.1.0.2.

Позже маршрутизатор R1 получает обновление от 10.1.0.2. Обновление содержит путь к двум сетям, 10.1.2.0/24 и 10.1.0.0/24. Атрибуты, показанные в этом обновлении будут рассмотрены в следующей главе.

BGP не обнаруживает соседей автоматически – каждый сосед настраивается вручную. Процесс установления отношений соседства происходит следующим образом:

II) Для обеспечения надёжности BGP использует TCP. Это означает, что теоретически BGP-пиры могут быть подключены не напрямую, а, например, так .

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

BGP-маршрутизатор (их также называют BGP-спикерами/speaker или BGP-ораторами) слушает и посылает пакеты на 179-й TCP порт. Когда слушает – это состояние CONNECT . В таком состоянии BGP находится очень недолго.

Вот пример неуспешного установления TCP-сессии. BGP будет в состоянии ACTIVE, иногда переключаясь на IDLE и снова обратно. TCP SYN отправлен с R1 на R2.

На R2 не запущен BGP, и R2 возвращает ACK, что получен SYN от R1 и RST, означающий, что нужно сбросить подключение.

Состояние BGP пиринга:

IDLE

Маршрутизатор запустил процесс BGP пиринга

CONNECT

Маршрутизатор пытается установить TCP сессию с пиром.

Инымы словами: ожидание ответ от пира.

BGP использует TCP 179 для установления BGP пиринга

NOTE

Тот пир локальный порт которого отличный от TCP 179 является инициализатором TCP сессии

ACTIVE

Состояние в котором маршрутизатор отправит SYN и ожидает ACK

Т.е. сам является инициализатором сессии.

OPEN SEND

После успешного установленияTCP сессии:

Jul 18 2019 19:25:01.99.3-08:00 R1 RM/6/RMDEBUG:

BGP.Public: Send OPEN MSG to peer 10.0.0.2, Version: 4

Local AS: 1 , HoldTime: 180 , Router ID: 10.0.0.1

OPEN CONFIRME

Jul 18 2019 19:25:06.399.6-08:00 R1 RM/6/RMDEBUG:

BGP.Public: 10.0.0.2 State is changed from ACTIVE to OPENSENT.

Jul 18 2019 19:25:06.419.2-08:00 R1 RM/6/RMDEBUG:

BGP: Received from 10.0.0.2 (AS Number: 1)

Jul 18 2019 19:25:06.419.3-08:00 R1 RM/6/RMDEBUG:

BGP.Public: Recv OPEN MSG from peer 10.0.0.2 Length: 45

Version: 4, Remote AS: 1, HoldTime : 180,

Router ID: 10.0.0.2, TotOptLen: 16

Jul 18 2019 19:25:06.419.7-08:00 R1 RM/6/RMDEBUG:

BGP.Public: 10.0.0.2 State is changed from OPENSENT to OPENCONFIRM.

Jul 18 2019 19:25:06.459.5-08:00 R1 RM/6/RMDEBUG:

BGP.Public: 10.0.0.2 State is changed from OPENCONFIRM to ESTABLISHED.

ESTABLISHED

Окончательный статус в процессе установления пиринга BGP.

KEEPALIVE служит для обозначения что сессия активна.

Посылаются по-умолчанию каждые 60 секунд.

Состояние BGP пиринга:
IDLE
Изначальное состояние
Маршрутизатор запустил процесс BGP пиринга
--------------
Открываем RFC 4721 A Border Gateway Protocol 4 (BGP-4)
8.2. Description of FSM
8.2.2. Finite State Machine
Idle state:
Initially, the BGP peer FSM is in the Idle state. Hereafter, the
BGP peer FSM will be shortened to BGP FSM.
In this state, BGP FSM refuses all incoming BGP connections for
this peer. No resources are allocated to the peer.
Внимательно читаем.
Никакого пиринга в этом состоянии быть не может.
----------------------------------------------
CONNECT
Маршрутизатор пытается установить TCP сессию с пиром.
ACTIVE
Состояние в котором маршрутизатор отправит SYN и ожидает ACK
Т.е. сам является инициализатором сессии.
--------------------------------------------------
Открываем, например, документацию Huawei на CE6800 Configuration Guide - IP Unicast Routing
Understanding BGP ->BGP Fundamentals->BGP State Machine. Картинка 9-2.
2.In Connect state, the BGP device starts the Connect Retry timer and waits to establish a TCP connection.
If the TCP connection is established, the BGP device sends an Open message to the peer and changes to the OpenSent state.
If the TCP connection fails to be established, the BGP device moves to the Active state.
If the BGP device does not receive a response from the peer before the Connect Retry timer expires, the BGP device attempts to establish a TCP connection with another peer and stays in Connect state.

In Active state, the BGP device keeps trying to establish a TCP connection with the peer.

Причины перехода из состояния в состояние и что происходит в том или ином состоянии конечного автомата BGP изложено неверно.

KPI по публикациям не отменяет знания предмета и умения КОРРЕКТНО излагать состояния конечного автомата, изложенные в RFC.

После создания однорангового узла bgp, если он активен, он запустит таймер запуска bgp, а затем начнет согласование конечного автомата BGP, иначе будет неловко создавать его, ничего не делая.

Введение в конечные автоматы

Ниже приводится определение BGP, управляемое состоянием и событиями:

bgp Он основан на протоколе tcp, который включает в себя преимущества протокола tcp, поэтому конечный автомат, указанный выше, имеет определенную связь с tcp-соединением:

tcp Состояние фазы установления соединения: Idle, Connect, Active
tcp После установления соединения: OpenSent, OpenConfirm, Established

Idle
BGP Первоначально соглашение находится в состоянии ожидания. В этом состоянии система не выделяет никаких ресурсов и отклоняет все входящие соединения BGP. Только после получения Start Event ресурсы BGP выделяются, таймер ConnectRetry запускается, соединение транспортного уровня с другими одноранговыми узлами BGP запускается, а также отслеживается запрос соединения от других узлов.

Таким образом, мы можем нарисовать конечный автомат BGP:

BGP Код конечного автомата написан очень красиво, с использованием текущего состояния + СОБЫТИЕ в качестве индекса конечного автомата, чтобы найти соответствующую функцию выполнения и следующее состояние:

Через массив FSM bgp_event_update заставляет код преобразования конечного автомата играть волшебный эффект упрощения комплекса:

start По истечении таймера EVNET - это BGP_Start, который получается через массив FSM в функции bgp_event_update

bgp_start После выполнения некоторых проверок вызовите bgp_connect, чтобы запустить TCP-соединение. Bgp использует tcp для подключения. Каждый экземпляр bgp сам по себе является tcp-сервером однорангового узла, а также tcp-клиентом однорангового узла. Сервер устанавливает свою собственную службу сокетов после bgp_create. Конец начинает отслеживать порт 179.

peer->fd = vrf_sockunion_socket Создайте TCP fd терминала обслуживания клиентов, подключенного к одноранговому узлу, и установите для FD неблокирующий режим. Поскольку FRR управляется событиями, поток не может быть приостановлен из-за блокировки fd.
Если пароль настроен, будет добавлена опция проверки подписи TCP MD5.

Приведенный выше код дополняет опцию MD5SIG.

В функции int tcp_v4_rcv (struct sk_buff * skb):

Следовательно, на стороне сервера проверка подписи завершается непосредственно ядром, когда tcp получен и обработан.

Наконец, bind вызывается для привязки настроенного исходного IP-адреса.

Наконец, вызовите sockunion_connect для обработки соединения с сервером.

Поскольку fd не является блоком, вызывая connect для запуска трехстороннего рукопожатия TCP, существует высокая вероятность того, что это не удастся немедленно (если он заблокирован, поток будет зависать), тогда есть небольшая вероятность того, что успех будет возвращен. ?

Согласно справке man по connect, возвращаемое значение выглядит следующим образом, проверьте объяснение, вы можете понять обработку возвращаемого значения кода:

If the connection or binding succeeds, zero is returned. On error, -1 is returned, and errno is set appropriately.

The socket is nonblocking and the connection cannot be completed immediately. It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select(2) indicates writability, use getsock‐opt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure).

Поэтому, когда bgp_connect возвращается, другая обработка будет выполняться в соответствии с возвращаемым значением:

connect_success: инициировать событие TCP_connection_open BGP_EVENT_ADD (peer, TCP_connection_open);
connect_in_progress: указывает на то, что соединение не было успешным, оно запускает доступные для чтения и записи события fd (согласно описанию предыдущего человека это может понять), функция обратного вызова bgp_connect_check основана на getsockopt (peer-> fd, SOL_SOCKET, SO_ERROR, (void *) & status, & slen);, чтобы определить, в порядке ли ссылка для подключения.

Затем функция возвращается напрямую и, наконец, достигает bgp_event_update, который изменяет состояние однорангового узла на Connect (соединение запускает TCP-соединение, которое не сразу становится успешным)

При вызове connect для запуска трехстороннего подтверждения TCP, connect возвращается напрямую без блокировки, а затем добавляет события FD, доступные для чтения и записи, функция обратного вызова - это функция bgp_connect_check, а затем вызывает getsockopt для получения статуса TCP-соединения, если статус возвращается Если установлено значение 0, то TCP-соединение устанавливается, а затем запускается событие TCP_connection_open:

В это время одноранговый узел находится в состоянии подключения. Согласно глобальному FSM, вы можете знать:

Следующее состояние: OpenSent

Функция обратного вызова: bgp_connect_success

bgp_connect_success в основном завершает:

Когда функция вернется к bgp_event_update, статус пира будет изменен на OpenSend

Читайте также: