Bgp notification error codes

Важно ли знать форматы заголовков передаваемых данных? Во многих учебных курсах по сетям разбору заголовков протоколов уделяется больше или меньше времени, но обычно без этого не обходится. Нося по своей природе описательный характер часто их изучение вызывает скуку, а наличие средств автоматического разбора не улучшает картину. Иногда заголовок действительно содержит интересный подход, но в большинстве случаев всё это вписывается в какой-то один принцип и следующий новый формат обычно уже не вызывает удивления. Самое интересное это, конечно, всевозможные сочетания тех опций, которые влияют на функционал, но стоит ли помнить какие опции в каком порядке вписываются в заголовке?

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

Ericsson SmartEdge

notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, repeated 89 times, code 3/4 (update: attribute flags error) - 
0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Cisco, то же с другой стороны

NOTIFICATION received from 192.0.2.2 (External AS 64496):
code 3 (Update Message Error) subcode 4 (attribute flags error),
Data: e0 07 08 00 03 02 ed 5b dc 3f 01

Попробуем разобрать это руками как написано в RFC4271. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше.

Чтобы внести разнообразие не ограничимся одним сообщением и разберём ещё вот это issue с GitHub FRRouting:

%NOTIFICATION: received from neighbor 192.168.0.1
3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes
50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Что мы можем прочитать? Видим тип сообщения, его значение и подзначение, IP адрес соседства (который нам и так известен) и шестнадцатеричная строка, которую мы не понимаем.

Начнём с главного с сайта IANA где есть все нужные коды с отсылкой к RFC4271. Если набраться сил и прочитать RFC от корки до корки, то всё должно стать понятно, но мы попытаемся разобраться только в формате наших двух сообщений не затрагивая поведенческие аспекты.

Разбираем NOTIFICATION

Из содержания, по названию, нам подходит пункт 4.5 NOTIFICATION Message Format. Открыв который действительно находим формат нужного нам заголовка и список всех кодов с ссылкой на соответствующие разделы (дальше всё цитирование спрячем под спойлеры):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Error code    | Error subcode |   Data (variable)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Error Code:

         This 1-octet unsigned integer indicates the type of
         NOTIFICATION.  The following Error Codes have been defined:

            Error Code       Symbolic Name               Reference
              1         Message Header Error             Section 6.1
              2         OPEN Message Error               Section 6.2
              3         UPDATE Message Error             Section 6.3
              4         Hold Timer Expired               Section 6.5
              5         Finite State Machine Error       Section 6.6
              6         Cease                            Section 6.7

Наш раздел 6.3 UPDATE Message Error с кодом ошибки 3. Видим его во всех сообщениях, вместе с уточняющим кодом:

code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01

3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

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

В нашем случае — используемые флаги не могут быть использованы c данным атрибутом:

If any recognized attribute has Attribute Flags that conflict with
the Attribute Type Code, then the Error Subcode MUST be set to
Attribute Flags Error.  The Data field MUST contain the erroneous
attribute (type, length, and value).

и — фактическая длина атрибута не совпадает с ожидаемой:

If any recognized attribute has an Attribute Length that conflicts
with the expected length (based on the attribute type code), then the
Error Subcode MUST be set to Attribute Length Error.  The Data field
MUST contain the erroneous attribute (type, length, and value).

Самое важное, что тут написано и что нам поможет в дальнейшем это то, что помимо кодов ошибок в сообщении ДОЛЖЕН присутствовать ошибочный атрибут из UPDATE сообщения в поле data в формате TLV (тип, длина, значение). Та самая шестнадцатеричная строка которую мы пока не можем интерпретировать. Однако, у нас по прежнему есть проблема в идентификации этого поля, связанная теперь с различными соглашениями принятыми производителями устройств для отображения журнала логов.

В примере с Cisco, явно указывается начало словом «Data»:
code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01

В остальных случаях, такой привязки нет. При этом строка с Ericsson, содержит гораздо больше данных чем у Cisco, хотя мы знаем что эти сообщения идентичны. Поэтому возвращаемся на шаг назад к описанию NOTIFICATION и видим что мы разобрали его полностью, поле data переменной длины является последним в сообщении.

Поднимемся выше по иерархии и начнём читать с начала раздела 4.1:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                                                               +
      |                           Marker                              |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Length               |      Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Каждое сообщение начинается с поля:

This 16-octet field is included for compatibility; it MUST be
set to all ones.

длиной в 16 байт и состоящее из всех единиц ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff. Такой же паттерн мы видим в логе Ericsson:
code 3/4 (update: attribute flags error) - 0000 0000 (ffff ffff ffff ffff ffff ffff ffff ffff) 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Далее поле длины в два байта:
code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff (0020) 0303 04e0 0708 0003 02ed 5bdc 3f01, со значением 32 десятичные, что совпадает с расшифровкой из журнала notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes, а ещё дальше :

This 1-octet unsigned integer indicates the type code of the
message.  This document defines the following type codes:

                     1 - OPEN
                     2 - UPDATE
                     3 - NOTIFICATION
                     4 - KEEPALIVE

и мы знаем что оно номер 3 — NOTIFICATION: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 (03)03 04e0 0708 0003 02ed 5bdc 3f01

А следом уже само сообщение и то что мы распознали (раздел 4.5) 03 04 — тип и подтип ошибки: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 03(03 04)e0 0708 0003 02ed 5bdc 3f01

Ericsson повторил нам не только поле data которое начинается с e0, а всё сформированное сообщение. В логе Cisco именно с него начинается байтовая последовательность. Лог FRRouting, также содержит полностью расшифрованный заголовок BGP сообщения NOTIFICATION за которым следует уже поле data, к декодированию которого мы возвращаемся.

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

A variable-length sequence of path attributes is present in
every UPDATE message, except for an UPDATE message that carries
only the withdrawn routes.  Each path attribute is a triple
<attribute type, attribute length, attribute value> of variable
length.

Начнём со значения поля Тип, которое состоит из двух однобайтных частей:

         Attribute Type is a two-octet field that consists of the
         Attribute Flags octet, followed by the Attribute Type Code
         octet.

               0                   1
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |  Attr. Flags  |Attr. Type Code|
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Здесь опять надо читать всё подряд, так как всё оформлено сплошным текстом. Из него следует, что поле флагов использует 4 первых бита с 0 по 3, а второй байт определяет сам атрибут. Сведём всё это в таблицу:

Биты 4-7 должны быть 0 при передаче и игнорироваться при приёме, на них внимание не обращаем. Бит 3 определяет размер поля length в TLV:

The fourth high-order bit (bit 3) of the Attribute Flags octet
is the Extended Length bit.  It defines whether the Attribute
Length is one octet (if set to 0) or two octets (if set to 1).

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

1. В случае, если атрибут не распознаётся этот флаг устанавливается, а сам атрибут передаётся дальше — 9 раздел:

   Update Message handling

   If an optional transitive attribute is unrecognized, the Partial 
   bit (the third high-order bit) in the attribute flags octet is 
   set to 1, and the attribute is retained for propagation to other 
   BGP speakers.

2. Если атрибут распознаётся следующим спикером, то флаг всё равно не сбрасывается — 5 раздел:

   Path Attributes

   Paths with unrecognized transitive optional attributes SHOULD be 
   accepted.  If a path with an unrecognized transitive optional 
   attribute is accepted and passed to other BGP peers, then the 
   unrecognized transitive optional attribute of that path MUST be 
   passed, along with the path, to other BGP peers with the Partial bit 
   in the Attribute Flags octet set to 1.  If a path with a recognized,
   transitive optional attribute is accepted and passed along to other 
   BGP peers and the Partial bit in the Attribute Flags octet is set 
   to 1 by some previous AS, it MUST NOT be set back to 0 by the 
   current AS.

3. И если не исходный спикер хочет добавить транзитивный атрибут, то флаг так же устанавливается:

   (там же)

   New, transitive optional attributes MAY be attached to the path by
   the originator or by any other BGP speaker in the path.  If they are
   not attached by the originator, the Partial bit in the Attribute
   Flags octet is set to 1.

Приступим к разбору UPDATE

Поле флагов в первом случае e0: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04(e0) 0708 0003 02ed 5bdc 3f01 — в двоичном 1110 0000 — опциональный, транзитивный с установленным флагом partial, поле длины задаётся одним байтом.

code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 (07)08 0003 02ed 5bdc 3f01 — код атрибута 7 — AGGREGATOR

Размер данных 8 байт: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 07(08) 0003 02ed 5bdc 3f01

Во втором случае — общеизвестный атрибут (50 — 0101 0000), размер поля длины в два байта, AS_PATH (02), длина 3294 байта (0c de): 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes (50 02 0c de) 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Оставшаяся часть строки это поле данных самого атрибута. Для этого продвигаемся дальше по разделу 4.3:

AGGREGATOR is an optional transitive attribute of length 6.
The attribute contains the last AS number that formed the
aggregate route (encoded as 2 octets), followed by the IP
address of the BGP speaker that formed the aggregate route
(encoded as 4 octets).  This SHOULD be the same address as
the one used for the BGP Identifier of the speaker.

Следует учесть работу с 32-битными ASn RFC6793, чтобы получить следующий результат:

4 байта это AS197357: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 (0003 02ed) 5bdc 3f01,

и 4 байта IP адрес 91.220.63.1: code 3/4 (update: attribute flags error) - 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed (5bdc 3f01) — в сумме 8 байт, как и указано в поле длины.

Во втором случае AS_PATH, сам по себе TLV:

The path segment type is a 1-octet length field with the
following values defined:

   Value      Segment Type

    1         AS_SET: unordered set of ASes a route in the
                 UPDATE message has traversed

    2         AS_SEQUENCE: ordered set of ASes a route in
                 the UPDATE message has traversed

The path segment length is a 1-octet length field,
containing the number of ASes (not the number of octets) in
the path segment value field.

Поля типа и длины размером по 1 байту.

Тип 2, размер данных (ff — 255 ASn): 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de (02 ff) 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 ... очень много раз 00 04 00 35

Сами данные — номера AS по 4 байта каждая: 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff (00 00 0c b9) (00 00 00 ae ) (00 04 00 3e ) (00 04 00 3e ) (00 04 00 35 ) (00 04 00 35 )... очень много раз 00 04 00 35 — AS3257, AS174, AS262206 AS262206, AS262197, AS262197, AS262197, AS262197 …

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

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

P.S. В случае FRRouting есть патч, намекающий, что проблема не в формате.

В первом случае, видимо, тоже нужен патч, так как формально я не увидел какой либо проблемы в совместном использовании флагов для атрибута AGGREGATOR, может кто увидел.

Bgp notification error code

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don’t want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. 🙂

If you like The TCP/IP Guide, please consider the download version. It’s priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I’d be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select «Disable on tcpipguide.com». Or go to the Tools menu and select «Adblock Plus Preferences. «. Then click «Add Filter. » at the bottom, and add this string: «@@||tcpipguide.com^$document». Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide

The TCP/IP Guide 9 TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4) 9 TCP/IP Internet Layer (OSI Network Layer) Protocols 9 TCP/IP Routing Protocols (Gateway Protocols) 9 TCP/IP Exterior Gateway/Routing Protocols (BGP and EGP) 9 TCP/IP Border Gateway Protocol (BGP/BGP-4) 9 BGP Detailed Messaging, Operation and Message Formats

BGP Error Reporting: Notification Messages
(Page 3 of 3)

BGP Notification Message Error Codes and Error Subcodes

Table 142 and Table 143 show the values permitted for the Error Code and Error Subcode fields, respectively, and thus provide a good summary of the types of errors that Notification messages can report (as well as demonstrating the other non-error uses of the message type).

Table 142: BGP Notification Message Error Codes

Message Header Error

A problem was detected either with the contents or length of the BGP header. The Error Subcode provides more details on the nature of the problem.

Open Message Error

A problem was found in the body of an Open message. The Error Subtype field describes the problem in more detail. Note that authentication failures or inability to agree on a parameter such as hold time are included here.

Update Message Error

A problem was found in the body of an Update message. Again, the Error Subtype provides more information. Many of the problems that fall under this code are related to issues detected in the routing data or path attributes sent in the Update message, so these messages provide feedback about such problems to the device sending the erroneous data.

Hold Timer Expired

Finite State Machine Error

The BGP finite state machine refers to the mechanism by which the BGP software on a peer moves from one operating state to another based on events ( see the TCP finite state machine description for some background on this concept ). If an event occurs that is unexpected for the state the peer is currently in, it will generate this error.

Used when a BGP device wants to break the connection to a peer for a reason not related to any of the error conditions described by the other codes.

Table 143: BGP Notification Message Error Subcodes

Error Subcode Value

Message Header Error (Error Code 1)

Connection Not Synchronized

The expected value in the Marker field was not found, indicating that the connection has become unsynchronized. See the description of the Marker field .

Bad Message Length

The message was less than 19 bytes, greater than 4096 bytes, or not consistent with what was expected for the message type.

Bad Message Type

The Type field of the message contains an invalid value.

Open Message Error (Error Code 2)

Unsupported Version Number

The device does not “speak” the version number its peer is trying to use.

The router doesn’t recognize the peer’s autonomous system number or is not willing to communicate with it.

Bad BGP Identifier

The BGP Identifier field is invalid.

Unsupported Optional Parameter

The Open message contains an optional parameter that the recipient of the message doesn’t understand.

The data in the Authentication Information optional parameter could not be authenticated.

Unacceptable Hold Time

The router refuses to open a session because the proposed hold time its peer specified in its Open message is unacceptable.

Update Message Error (Error Code 3)

Malformed Attribute List

The overall structure of the message’s path attributes is incorrect, or an attribute has appeared twice.

Unrecognized Well-Known Attribute

One of the mandatory well-known attributes was not recognized.

Missing Well-Known Attribute

One of the mandatory well-known attributes was not specified.

Attribute Flags Error

An attribute has a flag set to a value that conflicts with the attribute’s type code.

Attribute Length Error

The length of an attribute is incorrect.

Invalid Origin Attribute

The Origin attribute has an undefined value.

AS Routing Loop

A routing loop was detected.

Invalid Next_Hop Attribute

The Next_Hop attribute is invalid.

Optional Attribute Error

An error was detected in an optional attribute.

Invalid Network Field

The Network Layer Reachability Information field is incorrect.

The AS_Path attribute is incorrect.

Note that, perhaps ironically, no mechanism exists to report an error in a Notification message itself. This is likely because the connection is normally terminated after such a message is sent.

Key Concept: BGP Notification messages are used for error reporting between BGP peers. Each message contains an Error Code field that indicates what type of problem occurred. For certain Error Codes, an Error Subcode field provides additional details about the specific nature of the problem. Despite these field names, Notification messages are also used for other types of special non-error communication, such as terminating a BGP connection.

Источник

Разбираем BGP NOTIFICATION по RFC

Важно ли знать форматы заголовков передаваемых данных? Во многих учебных курсах по сетям разбору заголовков протоколов уделяется больше или меньше времени, но обычно без этого не обходится. Нося по своей природе описательный характер часто их изучение вызывает скуку, а наличие средств автоматического разбора не улучшает картину. Иногда заголовок действительно содержит интересный подход, но в большинстве случаев всё это вписывается в какой-то один принцип и следующий новый формат обычно уже не вызывает удивления. Самое интересное это, конечно, всевозможные сочетания тех опций, которые влияют на функционал, но стоит ли помнить какие опции в каком порядке вписываются в заголовке?

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

Cisco, то же с другой стороны

Попробуем разобрать это руками как написано в RFC4271. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше.

Чтобы внести разнообразие не ограничимся одним сообщением и разберём ещё вот это issue с GitHub FRRouting:

Что мы можем прочитать? Видим тип сообщения, его значение и подзначение, IP адрес соседства (который нам и так известен) и шестнадцатеричная строка, которую мы не понимаем.

Начнём с главного с сайта IANA где есть все нужные коды с отсылкой к RFC4271. Если набраться сил и прочитать RFC от корки до корки, то всё должно стать понятно, но мы попытаемся разобраться только в формате наших двух сообщений не затрагивая поведенческие аспекты.

Разбираем NOTIFICATION

Из содержания, по названию, нам подходит пункт 4.5 NOTIFICATION Message Format. Открыв который действительно находим формат нужного нам заголовка и список всех кодов с ссылкой на соответствующие разделы (дальше всё цитирование спрячем под спойлеры):

Наш раздел 6.3 UPDATE Message Error с кодом ошибки 3. Видим его во всех сообщениях, вместе с уточняющим кодом:

code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

code 3 (Update Message Error) subcode 4 (attribute flags error), Data: e0 07 08 00 03 02 ed 5b dc 3f 01

3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 . очень много раз 00 04 00 35

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

В нашем случае — используемые флаги не могут быть использованы c данным атрибутом:

и — фактическая длина атрибута не совпадает с ожидаемой:

Самое важное, что тут написано и что нам поможет в дальнейшем это то, что помимо кодов ошибок в сообщении ДОЛЖЕН присутствовать ошибочный атрибут из UPDATE сообщения в поле data в формате TLV (тип, длина, значение). Та самая шестнадцатеричная строка которую мы пока не можем интерпретировать. Однако, у нас по прежнему есть проблема в идентификации этого поля, связанная теперь с различными соглашениями принятыми производителями устройств для отображения журнала логов.

В примере с Cisco, явно указывается начало словом «Data»:
code 3 (Update Message Error) subcode 4 (attribute flags error), Data : e0 07 08 00 03 02 ed 5b dc 3f 01

В остальных случаях, такой привязки нет. При этом строка с Ericsson, содержит гораздо больше данных чем у Cisco, хотя мы знаем что эти сообщения идентичны. Поэтому возвращаемся на шаг назад к описанию NOTIFICATION и видим что мы разобрали его полностью, поле data переменной длины является последним в сообщении.

Поднимемся выше по иерархии и начнём читать с начала раздела 4.1:

Каждое сообщение начинается с поля:

длиной в 16 байт и состоящее из всех единиц ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff . Такой же паттерн мы видим в логе Ericsson:
code 3/4 (update: attribute flags error) — 0000 0000 ( ffff ffff ffff ffff ffff ffff ffff ffff ) 0020 0303 04e0 0708 0003 02ed 5bdc 3f01

Далее поле длины в два байта:
code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff ( 0020 ) 0303 04e0 0708 0003 02ed 5bdc 3f01 , со значением 32 десятичные, что совпадает с расшифровкой из журнала notification msg sent (nbr 192.0.2.1, context 0x40030044 32 bytes , а ещё дальше :

и мы знаем что оно номер 3 — NOTIFICATION: code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 ( 03 ) 03 04e0 0708 0003 02ed 5bdc 3f01

А следом уже само сообщение и то что мы распознали (раздел 4.5) 03 04 — тип и подтип ошибки: code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 03 ( 03 04 ) e0 0708 0003 02ed 5bdc 3f01

Ericsson повторил нам не только поле data которое начинается с e0, а всё сформированное сообщение. В логе Cisco именно с него начинается байтовая последовательность. Лог FRRouting, также содержит полностью расшифрованный заголовок BGP сообщения NOTIFICATION за которым следует уже поле data, к декодированию которого мы возвращаемся.

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

Начнём со значения поля Тип, которое состоит из двух однобайтных частей:

Здесь опять надо читать всё подряд, так как всё оформлено сплошным текстом. Из него следует, что поле флагов использует 4 первых бита с 0 по 3, а второй байт определяет сам атрибут. Сведём всё это в таблицу:

Биты 4-7 должны быть 0 при передаче и игнорироваться при приёме, на них внимание не обращаем. Бит 3 определяет размер поля length в TLV:

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

В случае, если атрибут не распознаётся этот флаг устанавливается, а сам атрибут передаётся дальше — 9 раздел:

Приступим к разбору UPDATE

Поле флагов в первом случае e0: code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04 ( e0 ) 0708 0003 02ed 5bdc 3f01 — в двоичном 1110 0000 — опциональный, транзитивный с установленным флагом partial, поле длины задаётся одним байтом.

code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 ( 07 ) 08 0003 02ed 5bdc 3f01 — код атрибута 7 — AGGREGATOR

Размер данных 8 байт: code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 07 ( 08 ) 0003 02ed 5bdc 3f01

Во втором случае — общеизвестный атрибут (50 — 0101 0000), размер поля длины в два байта, AS_PATH (02), длина 3294 байта (0c de): 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes ( 50 02 0c de ) 02 ff 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 . очень много раз 00 04 00 35

Оставшаяся часть строки это поле данных самого атрибута. Для этого продвигаемся дальше по разделу 4.3:

Следует учесть работу с 32-битными ASn RFC6793, чтобы получить следующий результат:

4 байта это AS197357: code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 ( 0003 02ed ) 5bdc 3f01 ,

и 4 байта IP адрес 91.220.63.1: code 3/4 (update: attribute flags error) — 0000 0000 ffff ffff ffff ffff ffff ffff ffff ffff 0020 0303 04e0 0708 0003 02ed ( 5bdc 3f01 ) — в сумме 8 байт, как и указано в поле длины.

Во втором случае AS_PATH, сам по себе TLV:

Поля типа и длины размером по 1 байту.

Тип 2, размер данных (ff — 255 ASn): 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de ( 02 ff ) 00 00 0c b9 00 00 00 ae 00 04 00 3e 00 04 00 3e 00 04 00 35 00 04 00 35 . очень много раз 00 04 00 35

Сами данные — номера AS по 4 байта каждая: 3/5 (UPDATE Message Error/Attribute Length Error) 3298 bytes 50 02 0c de 02 ff ( 00 00 0c b9 ) ( 00 00 00 ae ) ( 00 04 00 3e ) ( 00 04 00 3e ) ( 00 04 00 35 ) ( 00 04 00 35 ) . очень много раз 00 04 00 35 — AS3257, AS174, AS262206 AS262206, AS262197, AS262197, AS262197, AS262197 .

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

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

P.S. В случае FRRouting есть патч, намекающий, что проблема не в формате.

В первом случае, видимо, тоже нужен патч, так как формально я не увидел какой либо проблемы в совместном использовании флагов для атрибута AGGREGATOR, может кто увидел.

Источник

A BGP notification message is sent when an error condition is detected by the BGP process. The TCP connection with that BGP peer is closed after sending the notification message. Usually, the BGP process will log this notification in syslog, which would help us to identify the reason why the BGP session was brought down.

In this post, BGP notification message format along with error codes and subcodes are discussed.

Notification Message format:

BGP header(fixed 19 bytes which has marker, length and type fields) + Notification message [that has Error + Error subcode + Data field (variable length)]. Data field depends on Error and Error subcode.

when a notification is received/sent, BGP syslog message is displayed on console/vty line as below: (from a Dell switch)

STKUNIT0-M:CP %BGP-5-ADJCHANGE: VRF default Connection with neighbor 3.3.3.1 closed. Bad Peer AS received

In addition to syslog, Dell switches running FTOS would log the notification history in raw hex format in the output of “show ip bgp neighbor x.x.x.x” command. Due to limited logging buffer space, BGP notification logs might have been overwritten by other syslog messages. In those cases, to troubleshoot and identify the root cause of any outage caused by BGP flap, this raw hex output in the show command would be helpful.

Dell#Show ip bgp neighbor
<snip>
 Last reset 00:01:47, due to Maximum prefix limit reached
 Notification History
 'Connection Reset' Sent : 34 Recv : 0
 Last notification (len 21) sent 00:01:47 ago
 ffffffff ffffffff ffffffff ffffffff 00150306 01000000

Decoding Hex dump: BGP Header + Notification message:

BGP Header:  Marker (ffffffff ffffffff ffffffff fffffff)
Length: 0x0015 = 21
Message Type:0x03 = Notification
Error: 0x06 = Cease
Error Subcode: 0x01 = There is no subcode for cease error
Data: set to zeros.

Last notification (len 23) received 00:00:10 ago
 ffffffff ffffffff ffffffff ffffffff 00170302 02fe1400

BGP Header: Marker (ffffffff ffffffff ffffffff fffffff)
Length: 0x0017 = 23
Message Type:0x03 = Notification
Error: 0x02 = OPEN message error
Error Subcode: 0x02 = Bad Peer AS
Data: 0xfe14 = Inform peer that they use 65044 as their AS, which is wrong.

Following table has the list of BGP notification error/subcodes.

This entry was posted in bgp, Force10, Routing and tagged BGP, notification. Bookmark the permalink.

Notification messages, whose format is shown in Figure 2-47, are sent when an error condition is detected. The BGP connection is closed immediately after the message is sent.

i Figure ^ ^^ Notification Message Format

The BGP Notification message contains the following fields:

• Error Code—A 1-octet field indicating the type of error.

• Error Subcode—A 1 -octet field providing more-specific information about the error. Table 2-8 shows the possible error codes and associated error subcodes.

• Data—A variable-length field used to diagnose the reason for the error. The contents of the Data field depend on the error code and subcode.

Table BGP Notification Message Error Codes and Error Subcodes

continues continues

Continue reading here: Review Questions

Was this article helpful?

Материал из Xgu.ru

Перейти к: навигация, поиск

< BGP

[править] Формат заголовка

У всех сообщений BGP такой формат заголовка:

|<-------------------------- 32 бита --------------------------->|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                           Marker                              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Length               |      Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля заголовка BGP-сообщений:

• Marker — поле, которое включено в заголовок для совместимости. Размер поля — 16 байт, все байты должны быть 1.
• Length — длина всего сообщения в октетах, включая заголовок. Поле может принимать значения от 19 до 4096.
• Type — тип передаваемого сообщения:
  • 1 — OPEN
  • 2 — UPDATE
  • 3 — NOTIFICATION
  • 4 — KEEPALIVE

[править] Open

Open — используется для установки отношений соседства и обмена базовыми параметрами. Отправляется сразу после установки TCP-соединения.

Формат сообщения Open:

|<-------------------------- 32 бита --------------------------->|

+-+-+-+-+-+-+-+-+
|    Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     My Autonomous System      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         BGP Identifier                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Optional Parameters                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Кроме стандартного заголовка пакета BGP, в сообщении Open такие поля:

• Version — версия протокола BGP
• My Autonomous System — номер автономной системы отправителя
• Hold Time — максимальное время в секундах, которое может пройти между получением Keepalive и сообщением Update. Время выбирается минимальным
• BGP Identifier — играет роль в выборе пути пересылки BGP-сообщений при наличии более одного канала связи между BGP-соседями
• Optional Parameters Length — если =0, то в маркер записываются 1-цы, а Optional Parameters имеет нулевую длину; если не =0, то в Optional Parameters записываются данные для определения кода, который указывается в маркере.
• Optional Parameters — играет роль в формировании и последующем определении кода в поле маркер.

[править] Update

Update — используется для обмена информацией маршрутизации.

Формат сообщения Update:

+-----------------------------------------------------+
|   Unfeasible Routes Length (2 octets)               |
+-----------------------------------------------------+
|  Withdrawn Routes (variable)                        |
+-----------------------------------------------------+
|   Total Path Attribute Length (2 octets)            |
+-----------------------------------------------------+
|    Path Attributes (variable)                       |
+-----------------------------------------------------+
|   Network Layer Reachability Information (variable) |
+-----------------------------------------------------+

[править] Notification

Notification — используется когда возникают ошибки BGP. После отправки сообщения сессия с соседом разрывается.

Формат сообщения Notification:

|<-------------------------- 32 бита --------------------------->|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code    | Error subcode |           Data                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Кроме стандартного заголовка пакета BGP, в сообщении Notification такие поля:

• Error Code — тип оповещения:
  • 1 — Message Header Error
  • 2 — OPEN Message Error
  • 3 — UPDATE Message Error
  • 4 — Hold Timer Expired
  • 5 — Finite State Machine Error
  • 6 — Cease

[править] Дополнительная информация

[править] Примечания

BGP — Border Gateway Protocol
Основы	BGP  • Типы сообщений BGP  • BGP full view  • BGP RFC  • Bogon  • RIPE NCC  • RIS
Атрибуты BGP	BGP AS path  • BGP next-hop  • BGP origin  • BGP MED  • BGP weight  • BGP local preference  • BGP community
IBGP	BGP confederation  • BGP route reflector
Cisco	Cisco BGP filter order  • Cisco distribute-list  • Cisco prefix-list  • BGP AS path filter  • Cisco route-map  • Изменение значения AD для BGP в Cisco  • Команды отладки BGP  • Применение изменений в настройках политик BGP  • BGP synchronization  • BGP timers  • BGP ORF  • Процессы BGP в Cisco  • Просмотр информации BGP в Cisco
Маршрутизация	Выбор лучшего маршрута в BGP  • Маршрут по умолчанию в BGP  • Перераспределение маршрутов в BGP  • Суммирование маршрутов BGP
MP-BGP	BGP address-family
Безопасность	BGP Security  • Аутентификация BGP
Управление трафиком	Управление входящим трафиком BGP  • Управление исходящим трафиком BGP  • Балансировка трафика в BGP  • Использование BGP для резервирования Интернет-каналов  • BGP AS path prepend  • BGP conditional route injection  • BGP backdoor
Реализации	BGP в Cisco  • BGP в Quagga  • Zebra BGP
Утилиты BGP	BGP tools  • BGP Looking Glass  • BGPlay
Разное	BGP/config

BGP