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

Habrahabr
Важно ли знать форматы заголовков передаваемых данных? Во многих учебных курсах по сетям разбору заголовков протоколов уделяется больше или меньше времени, но обычно без этого не обходится. Нося по своей природе описательный характер часто их изучение вызывает скуку, а наличие средств автоматического разбора не улучшает картину. Иногда заголовок действительно содержит интересный подход, но в большинстве случаев всё это вписывается в какой-то один принцип и следующий новый формат обычно уже не вызывает удивления. Самое интересное это, конечно, всевозможные сочетания тех опций, которые влияют на функционал, но стоит ли помнить какие опции в каком порядке вписываются в заголовке?
Не могу сказать, что я это помню, ещё не могу сказать что это мне мешает в работе. Я даже не могу сказать, что мне приходится часто видеть заголовки в каком-то необработанном виде, потому что, как правило, сообщения в 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
Попробуем разобрать это руками как написано в RFC4721. Не будем искать причину — просто разбор заголовков. Будет много цитат и, скорее всего, ничего нового для тех кто уже это умеет делать. Для остальных читаем дальше. Читать дальше →