VxLAN фабрика. Часть 2.5

[Karroplan]

И в этом кроется весь секрет — VxLAN не имеет такой номер, а значит протокол IP не сможет о нем рассказать и уважающая себя сеть такой пакет не пропустит, поэтому инженеры обошли эту проблему с использованием протокола UDP

тут, пожалуй, уместнее вопрос — почему не выделили vxlan в отдельный ip-протокол, чтобы избежать лишней инкапсуляции?
но, я, наверное, знаю ответ: чтобы продолжать эффективно использовать механизм балансировки нагрузки между линками leaf-свитча, который опирается на хэш mac+ip+udp_port — в таком случае гораздо проще утилизировать все upstream-линки до spine, просто варьируя source udp port.

[alex_www]

Ну и что бы гонять vxlan через Интернет, скажем для DC-DC связи. UDP is the new IP

[Santchous]

Да, согласен. Почему-то сразу не пришел в голову такой вариант. Добавил в текст)

[admOS]

Нет, это неверное предположение.
Во-первых, зачем-то притянули за уши балансировку в LACP. Совершенно не связанные между собой вещи. Да и первое утверждение о том, что VxLAN не имеет своего номер выглядит не очень.
Во-вторых, ответ на вопрос «зачем используется UDP» три года назад дан в статье habr.com/ru/post/344326, а именно:

Возникает вопрос — почему UDP? Почему не TCP, он же надежнее, имеет адские таймауты для сессий и т д. Дело в том, что TCP проектировался под совсем другие нужны и его задача — гарантированная доставка данных приложений — отсюда и механизмы подтверждения получения пакета удаленной стороной и управление скоростью передачи. Проблема хорошо будет заметна, когда клиент тоже будет использовать TCP. В итоге мы получим TCP поверх TCP — уже звучит не очень. Теперь представьте, что пакеты теряются, и как вы понимаете, теряться они будут и в рамках underlay сессии VTEP-A<<>>VTEP-B и в рамках overlay сессии SERVER-A<<>>SERVER-B. А когда у нас теряются пакеты в TCP, то закономерно возникают ретрансмиты — так как нет подтверждения получения. В итоге возникнут ретрансмиты и в underlay сессии и в overlay сессии. То есть получается, что underlay TCP сессия начнет гонять помимо своих ретрансмит пакетов, еще и ретрансмиты overlay TCP сессии. В итоге в таком сценарии мы погрязнем в ретрансмитах, что неизбежно приведет к потере скорости и в итоге получим вместо плюсов — одни минусы. К тому же еще одним не менее важным фактором в пользу UDP является тот факт, что UDP не устанавливает сессию, когда TCP — это всегда p2p сессия и она не может быть p2mp — а вот зачем нам это, мы узнаем чуть позже.

[admOS]

Нет, ваше предположение неверно. Вы зачем-то притянули за уши балансировку на LACP ether-channel`ах, которая никак не связана с использованием UDP в качестве транспорта внутри VxLAN. Прочитайте habr.com/ru/post/344326 и вы найдёте ответ на вопрос.

[Karroplan]

вы не поняли. вопрос был не «почему udp, а не tcp», а «почему udp, а не просто ip». И в вашей статье этого ответа нет. Вернее, там сказано «ну, для vxlan не придумали номер протокола», что является глупостью — ибо законодатель в области сетей Cisco Inc легко могли выпросить у IETF номер протокола.
далее, да, я неправильно написал про хэш от mac+ip+udp_port, но тем не менее я прав в идее — балансировка при доступных нескольких next-hop осуществляется per-flow, как правило, и чтоб она работала нужен протокол уровня L4, читай udp.

[Santchous]

Соглашусь с Karroplan. В приведенной вами статье есть ответ почему не TCP. Однако, про UDP нет прямого ответа.

Спасибо про указание балансировки. MAC адрес действительно используется в LACP. ECMP — учитывает протокол + остальные поля. В тексте поправил этот момент. Но тут тоже можно поспорить, так как на некоторых линейках оборудования мы можем вручную указать поля, по которым будет считаться хеш для ECMP и у различных производителей это так же может отличаться. Я постарался указать значения по-умолчанию для оборудования Cisco.