All MTUs matter

История релевантна для протокола BGP в целом, но у меня всплывала в EVPN-овском кейсе, посему пример будет про EVPN.

В общем, жила-была одна фабрика... Вернее две, а точнее несколько подов - ну multipod тобишь в терминологии Cisco. В общем, единый control plane и вот это вот всё. Ну жила себе и жила. Бордер лифы связывались посредством какой-то там матери, то есть какого-то IP транспорта.

Ну допустим так:

Вся эта конструкция работала без проблем - маршруты передовались, туннельчики строились, L2-трафик мой любимый гонялся. Фабрика росла - количество хостов увеличивалось, лифы добавлялись.

Однако в какой-то момент что-то там наебнулось внутри транспортной сети и BGP сессия порвалась.

Ну как сломалось, так и починилось. Транспорт восстановился и стал работать стабильно. Даже BGP сессия подняласась. Однако ничего чёто по ней в одну сторону не передовалось - апдейты не доходили куда-надо, да ещё и падала сессия периодически, и период этот был равен ВНЕЗАПНО длине hold timer-а.

Чё происходит - не понятно :(

Пришлось в общем немного потраблшутить ) А для красочной картинки пришлось даже в проде повторить ситуацию.

В общем, если в тот короткий момент посмотреть на состояние bgp сессии можно увидеть растущий счётчик исходящей очереди:

То есть эта тварь реально не может отдать своему товарищу всё, что у него там накопилось.

Итого два факта - bgp сессия рвётся по hold-timer-у, растёт очередь исходящих сообщений.

Тут в общем немного пришлось теорию BGP вспоминать)

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

Во-вторых - BGP это про TCP. Как узнать что друг наш Keepalive-то получил? Правильно - ждём tcp ack с сооветствующим номером.

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

А если Update возомнит себя Айболитом? А если он не дойдёт? А если он в пути пропадёт? Что станется с ними - с больными, с нашими bgp соседями шальными?

Ведь получается ни мой апдейт ни дошёл, да и на keepalive я хуй забил. Что обо мне подумает мой сосед? Конечно же он подумает что я сдох через время равное Hold timer-у

Так и при чём тут MTU вообще? А вот при чём. Оказывается где-то на пути следования трафика из Пода 1 в Под 2 был занижен MTU на транспорте!

Ну и что? А то, что после переустановки сессии бордер лиф с Пода 1 захотел послать такоооооооой большой апдейт (ну накопилось у него MAC-ов там этих), что в 8050 байт он и не пролез. Он-то думал что MTU - 9000, глянул по своему интерфейсу исходящему и да и запихал всё, что только уместилось в пакетик - роутер же не знал, что мудаки-админы не позаботились про консистентность MTU на пути следования пакета или на крайняк не подумали про PMTUD. Пакет успешно наебнулся по пути следования, роутер не получив ack, увеличил исходящую очередь и отправил update ещё раз - и так ещё пару раз, пока не получил сообщение от соседа что это вообще всё бессмыслено и никому не нужно (TCP FIN).

В общем, не будьте как я, поцоны - соблюдайте гигиену MTU.

А если кто-то знает на своём опыте помог бы мне на Nexus-ах

ip tcp path-mtu-discovery

- напишите комментик )