Тема BUM трафика имеет огромное значение в современном мире сетевых технологий. И не важно L3-only у вас, или единый L2 на всю корпорацию. BUM - используется в любом случае. Тем более, это имеет огромное и внутри сетей центров обработки данных. Вот хочу поговорить про это чуть побольше и подетальней, и естественно в разрезе EVPN-VXLAN.
Добро пожаловать, надеюсь будет интересно.
BUM - общая инфа
BUM — это аббревиатура, сочетающая в себе 3 типа трафика, а именно B - broadcast, U - unknown unicast и M - multicast. В ходе статьи мы будем говорить о каждом отдельно и посмотрим на их особенности, а пока давайте посмотрим на них целиком.
Обратите внимание, это не одинаковые типы трафика, но они все по какой-то причине объединены в одну группу. Они все используют многоадресную рассылку, или point-to-multipoint. Если бы мы говорили про классическую сеть, то ни для кого не секрет, как рассылается Broadcast внутри VLAN. Коммутатор берёт и кидает кадр во все интерфейсы принадлежащие этому VLANу, кроме того, с которого получил.
Что же касается EVPN-VXLAN, то тут с BUM не всё так просто. То есть, конечно мы ровно так и попытаемся сделать, чтобы наш кадр получили все нуждающиеся, кроме того, кто нам его отправил, однако это будет чуть-чуть интересней.
Как многие из вас знают, у нас внутри EVPN домена, существует несколько типов маршрутов, каждый из которых имеет своё предназначение. Мы тут не будем обсуждать все, остановимся только на том, который отвечает на многоадресную рассылку внутри EVPN. Это Route Type 3 (он же RT-3), или inclusive multicast. Не хочу расписывать всё про данный тип маршрута, коснусь только той информации, которая для нас будет иметь значение, но для любопытствующих ниже будут ссылки:
Вот тут например, в целом хорошо расписан сам маршрут. Не обращайте внимание на то, что в статье указан Juniper и речь идёт про EVPN-MPLS, история с RT-3 будет ровно точно такой же и для EVPN-VXLAN.
Кому надо больше, то рекомендую не жалеть себя и идти сразу читатьRFC6514оно интересное, по крайней мере мне было любопытно.
Помимо стандартных атрибутов, типа NEXT_HOP или AS_PATH, он включает в себя специфичный. Причем слово "атрибут", тут не ошибка, он описан в RFC6514 section 5.0 и называется PMSI Tunnel Attribute.
Так вот внутри него содержится 2 основных для нас параметра:
Tunnel Type (1 octets)
Тут указан тот тип инкапсуляции, который нужно использовать для связи. То есть пир вам отдаёт этот маршрут и он же говорит, как вам нужно до него добираться, через какой туннель. Например через RSVP, или через PIM-SM, ну или какой-то другой способ. Всё это определяется кодом, который описан в RFC по ссылке выше.
MPLS Label (3 octets)
Тут собственно тоже всё понятно - указан номер метки, в которую стоит всё это дело завернуть перед отправкой. Если у вас VXLAN, то соответственно, для вас это поле остаётся таким же, но значение меняется с MPLS метки, на VNI. И он как раз сюда ровно помещается, со своими 24 битами, или 3 байтами, или 8 октетами.
Возьмём следующий пример, мы получаем RT-3, со следующим наполнением:
...
[PMSI Tunnel Attribute]
Tunnel Type = 6
MPLS Label = 100100
...
Указано в Tunnel Type значение "6", cмотрим RFC, там 6 = Ingress Replication. Ок, значит делаем Ingress Replication. Что такое Ingress Replication и как работает, посмотрим чуть позже. Внутри MPLS Label выставлено значение "100100", то в эту метку и заворачиваем, ну или указываем её в качестве поля VNI, внутри VXLAN заголовка.
Собственно, используя вот эту связку, мы и будем понимать как нам рассылать тот самый BUM трафик.
Возникает абсолютно закономерный вопрос, что такое этот ваш Ingress Replication и как пир перед отправкой, решает какой всё-таки тип туннелирования ему требовать от получателя маршрута, да и какую метку выставить тоже непонятно...
Давайте начнём с того, какое значение нужно отправить в поле MPLS Label.
Отправляем то, которое указали для нашего L2 сегмента, или L2VNI. То есть мы указывали в конфигурации, для L2VNI значение VNI равное 100100, вот его и установим в это поле, перед отправкой пакета.
Что насчет метода туннелирования? Тут немного остановимся, дабы определится с терминологией. Чуть раньше я уже сказал, что существует несколько вариантов, и так как rfc писался в первую очередь для сетей построенных на MPLS, то и варианты были соответствующие. Вот все:
0 - No tunnel information present
1 - RSVP-TE P2MP LSP
2 - mLDP P2MP LSP
3 - PIM-SSM Tree
4 - PIM-SM Tree
5 - BIDIR-PIM Tree
6 - Ingress Replication
7 - mLDP MP2MP LSP
Но т.к. у нас нет ни одного LSP, поэтому все варианты, опирающиеся на MPLS для нас неактуальны. Ок, убираем 1, 2 и 7.
0 для нас тоже неинтересен, т.к. предназначен для того случая, когда нам всё равно, какой механизм использовать и мы отдаём право выбора на сторону получателя данного маршрута.
Остаётся 3, 4, 5 и 6. При этом, три опираются на один и тот же протокол - PIM, а вот шестой, отличается.
Таким образом, внутри EVPN-VXLAN, мы имеем следующие варианты туннелирования BUM трафика:
PIM, или Protocol Independent Multicast. Собственно протокол, который позволяет нам маршрутизировать multicast внутри сети. Писать про него в деталях не буду, т.к. это тема для совсем отдельной статьи, а точнее нескольких, всё-таки multicast это одна из тех тем, о которых стараются умолчать и не трогать лишний раз..., но дальше ещё мы в обсуждении именно передачи мультикастового трафика внутри EVPN-VXLAN, вернёмся к нему. Конкретно нашла применение вариация PIM-SM, поддерживающая RP или Rendezvous Point. Вот тут можно почитать об этом - https://linkmeup.gitbook.io/sdsm/9.-multicast/2.-pim/1.-pim-sparse-mode
Ingress Replication (или Head-end replication). Это механизм, не протокол. Суть в том, что в отличии от PIM, выполняется репликация, или рассылка трафика всей группе, непосредственно с узла, который инициирует тот самый трафик. Вот что пишут внутри RFC "When the Tunnel Type is set to Ingress Replication, the Tunnel dentifier carries the unicast tunnel endpoint IP address of the local PE that is to be this PE's receiving endpoint address for the tunnel."К примеру, у нас есть 10 лифов, которые делят один и тот же L2VNI сегмент. Каждый из этих лифов сгенерит RT-3 и внутрь него подставит вышеописанные параметр. Дальше эти 10 сообщений распределятся между всеми и с точки зрения каждого лифа, у него будет 9 уникальных маршрутов RT-3, внутри одного и того же L2VNI. Когда этот коммутатор решит отправлять BUM трафик, то он его отправит всем девяти лифам, от которых ранее получил сообщение.
Ок, вот гифка.
Оба эти варианта возможны и лично я, встречал и тот и другой, но, подавляющее количество вендоров производящих коммутаторы с поддержкой EVPN-VXLAN, не поддерживают ничего, кроме Ingress Replication. И чуть позже мы попытаемся найти ответ почему.
Мне кажется тут вышло более чем достаточно различной справки, пора переходить дальше.
B - Broadcast
Наш первый тип, и наверное самый популярный. Причины очевидны - огромное количество проблем возникающих внутри сетей, происходит по причине широковещательного шторма. Если вы думаете, что это наследие и его больше не существует, то могу вас уверить, что внутри EVPN-VXLAN фабрики, шторм наводит такой шорох, что мало не покажется никому.
Я тут не буду повторять и расписывать подробности возникновения петель, а также механизмы защиты. Вот тут писал более чем подробно про петли внутри EVPN-VXLAN:
Что же всё-таки за трафик у нас бывает внутри EVPN-VXLAN, который должен распространяться по принципу широковещательного, и что нам с этим всем делать.
ARP
О да, ARP. Этот парень знает толк в петлях. Но пока что, без него существование IP сетей вообще нереально. Считаю, что всякие разные технологии, которые вы знаете, очень важны, но ARP важнее. Наверное, если говорить про сети ЦОДов, это будет протокол входящий в топ #2, первое место отдадим всё-таки BGP. В общем без него никуда.
На самом деле он не является каким-то сложным, просто таков мир TCP/IP, что без ARP мы не можем обеспечивать связь на уровне MAC - IP.
Как многие из вас прекрасно знают, ARP имеет 2 типа сообщения, request и reply. Так вот первый, он же request, наш любимый broadcast.
А второй, это тот который никогда не возвращается...
Многие вендоры, да почти все, реализовали на уровне лифов технологии сокращения количества ARP-Request. Однако, тут есть варианты:
arp-suppression. Классический вариант, впервые я его встретил на Cisco N9K, но в последующем на многих коробках, начиная с Arista, заканчивая B4COM. Собственно лиф, получив arp-request от хоста, просто смотрит в свою ARP таблицу, и если у него есть ответ, то отправляет его в качестве arp-reply обратно на хост. Флуда при этом внутри всего домена не происходит.
arp-broadcast-suppression. Вариант, который Huawei, по крайней мере я его встретил впервые именно там. К слову, этот же вариант использует Aquarius в своих коробках. Идея другая, тут коммутатор, получив arp-request, не отвечает на него сам, хоть даже и знает всю информацию, а всё-таки отправляет этот кадр дальше, но уже не как broadcast, а как unicast. Это интересный вариант, кажется что вот он то и будет победой, но увы, некоторые ребята, получив такой интересный request, считают, что он "паленый" и веры ему нет, дропнем лучше пока ничего не случилось.
Оба варианта, настраиваются проще простого, это чаще всего одна команда. Примерно вот, что-то такое:
Cisco N9K:
interface nve1
member vni 100100
suppress-arp
Huawei CE 6-8K:
#
bridge-domain 100
vxlan vni 100100
arp broadcast-suppress enable
#
Но есть варианты, где arp-suppression включен по умолчанию, например Arista, и его выключить можно только вот так:
router l2-vpn
arp proxy prefix-list DISABLE_SUPPRESSION
!
ip prefix-list DISABLE_SUPPRESSION
seq 10 deny 1.2.3.4/32
#
Если сравнивать варианты с включенным и с выключенным подавлением ARPа, то если у вас нет объективных причин, то я вам рекомендую его НЕ включать.
Почему? Всё просто, очень много раз встречал, когда эта технология работает не так как должна, а точнее не работает вовсе. Просто коммутатор получает request, и не отвечает ничего, хотя вся информация у него есть. И работали в рамках кейсов, и исследовали сами, где-то помогал переход на более свежую версию софта, а где-то вообще ничего и приходилось именно выключать. Причем это касается не только каких-то "специфичных" кейсов или малоизвестных вендоров, а вполне себе Cisco N9K имеет проблемы с этим. Многие из тех, кто эксплуатировали у себя в сети эти коробки, не дадут соврать.
DHCP
Брат нашего предыдущего протокола. Не такой важный, но такой же broadcast. А точнее его первый пакет - DHCP Discovery. С ним всё иначе, его немного и он летит не часто. При этом, тут возникает другая проблема, заключается она в том, что DHCP-сервер живёт у нас обычно где-то далеко, и нужно трафик до него проксировать (использовать dhcp-relay).
Казалось бы, ну и что тут такого? В целом ничего, только вот как вернуть трафик в нужное место?
То есть вы отправили с leaf-1, discovery улетел куда-то, а дальше вам нужно со стороны сервера вернуть ответ не просто внутрь этой сети, а именно на leaf-1, т.к. в противном случае host отправивший данный кадр, не получит ответ и останется без адреса.
Ок, вот ещё гифка.
Решается с помощью поля gateway address (или giaddr) внутри пакета DHCP. В данное поле, мы помещаем адрес нашего Leaf-1, т.е. он должен быть уникальным и указан в настройках. После получения такого пакета, DHCP сервер уже не просто куда-то отвечает, а отвечает на вполне себе конкретный IP адрес и пакет возвращается ровно на тот лиф, который и инициировал взаимодействие.
Ниже приложу пример конфигурации, для Huawei и Arista. Выбрал этих, просто потому что конфиги под рукой. В целом идея на других будет ровно такая же.
Давайте опишу коротко шаги:
Создаём интерфейс SVI или IRB.
Указываем какой-то VRF.
Указываем на нём IP, который будет anycast.
Добавляем уникальный IP, который попадёт в поле giaddr.
Указываем адрес DHCP сервера.
Готово.
Ну и собственно вот сами конфигурации:
Huawei СE:
Interface Vbdif100
ip binding vpn-instance TEST
ip address 10.1.1.1 255.255.255.192
dhcp select relay
dhcp relay information enable
dhcp relay server-ip 10.99.99.99 vpn-instance TEST
dhcp source-ip-address 10.1.1.2
m-lag ip address 10.1.1.2 255.255.255.192
И аналогичный конфиг для Arista:
ip dhcp relay information option
interface Vlan100
description TEST_100
vrf TEST
ip address 10.1.1.2/27
ip helper-address 10.99.99.99
ip virtual-router address 10.1.1.1/24
Вот таким образом, вы получаете ровно то, что описано выше. Полученные в этом vlan DHCP пакеты, будут лететь уже на DHCP сервер, который расположен по адресу 10.99.99.99, внутри которых будет поле giaddr с параметром "10.1.1.2". Сервер получит, выдаст IP из этой подсетки, и отправит пакет, где будет в качестве dst указан 10.1.1.2.
Всякое разное широковещательное
ARP и DHCP - это два основных протокола, которые используют broadcast в рамках инфры ЦОДа, но в теории, вы можете встретить и другие. Например, есть WoL, или Wake-on-LAN. Он тоже опирается на broadcast, но с другой стороны кому он нужен внутри ЦОДа, да и вообще? Лично я не встречал.
В целом, логика реализации любого broadcast трафика будет похожая, однако не будет подобных оптимизаций, какие мы имеем для ARP и DHCP.
U (или UU) - Unknown unicast
Следующий тип трафика - это UU, или Unknown unicast. Наверное, это не столько тип трафика, сколько явление, которое можно наблюдать внутри сетей. Причем оно одинаково будет как для провайдерского сегмента, так и для сетей ЦОДа, да и для любой вообще.
Что это и как возникает?
Механизм возникновения известен многим, но я на всякий повторю. Представим ситуацию, что мы получаем какой-то unicast кадр. Что будет делать коммутатор? Правильно, проверять свою FDB и искать там соответствие "destination MAC - интерфейс", чтобы туда отправить наш кадр.
Но что будет, если у него нет записи по тому MAC адресу, который используется как destination? Он его разошлёт всем, внутри данного широковещательного домена, кроме того порта с которого получил.
Ничего не напоминает?
Всё верно. Это будет точно такая же логика, которая присуща и broadcast. Только произойдёт оно с unicast кадром.
Ну ок, произошло и произошло, передаваться дальше же ничего не будет. Шторма не произойдёт. Не произойдёт же, да?...
Расскажу вам одну байку. Недавно тестировали одну коробку, и коллега собрала фабрику, где к одному из лифов подключила простой кампусный коммутатор транковым портом. После этого взяла и запустила трафик с TRex в одну сторону, так, что он заходил на тестируемый лиф со стороны спайнов, т.е. со стороны NVE интерфейса. Т.к. трафик был однонаправленный, то обратного потока не было и лиф понятия не имел о том, где находится MAC получателя, поэтому слал трафик во все порты, включая TRex и наш маленький кампусный коммутатор, который внезапно оказался под ударом и чуть не сдох при каждом запуске трафика уходил в себя, начинал нещадно тупить при открытии SSH сессии и наверное очень сильно переживал...
А теперь представьте, если такое произойдёт не на одном лифе, а в сети провайдера, ну или вот, в вашем ЦОДе...
К примеру лиф не 1, а 10. Потоков трафика будет не 1, а тоже 10... Да и пусть портов получателя тоже будет не 1, а 10... Ну как бы этого уже будет более, чем достаточно, чтобы от такого разово всплекса могло что-то продуктивное подустать и прилечь отдохнуть.
Почему же FDB могла обнулиться? Да очень просто. MAC learning имеет таймер. Вот если по какой-то причине, у вас нет трафика на протяжении этого времени, то вы гарантированно получаете unknown unicast в рамках поиска того самого MAC адреса. Ну и в целом, если у вас хосты молчуны, а потом внезапно говоруны, то таймер может истечь, MAC удалится из FDB, и тут же резко всем очень понадобится...
Так, выходит что и из-за этого может произойти достаточно серьёзный сбой. Ну ок, получается тоже надо учитывать.
Вариант защиты
Самый простой и наверное единственный вариант, это ЗАПРЕТИТЬ L2 ВООБЩЕ корректировать таймеры.
Как вы понимаете, никакого MAC взаимодействия, не может произойти, пока мы не узнали тот самый MAC. Да, да, опять ARP.
Логично сделать так, чтобы таймеры ARP, были меньше, чем таймеры внутри FDB. Таким образом, выученный MAC вследствие работы ARP, будет храниться гарантированно дольше, чем храниться ARP и если кто-то и перестанет общаться, то он и обновится опять с рассылкой нашего ARPа.
У каждого вендора данные таймеры свои, но везде редактируются. Например, для Cisco N9K дефолт хранения MAC - 1800 секунд и ARP - 1500 секунд. Для Huawei FDB 300 секунд, и ARP кеш 1200 секунд. Ну и на Arista решила повторить дефолт, который годами стоял на Cisco IOS - MAC - 300 секунд и ARP - 4 часа, или 14400 секунд.
Всё это правится вот так:
Cisco N9K:
mac address-table aging-time 1200
ip arp timeout 600
Huawei CE:
mac-address aging-time 1200
arp timeout 600
Arista:
mac address-table aging-time 1200
interface vlan 100
arp aging timeout 600
С такими таймаутами, уже не произойдёт история, что ARP сохранится дольше, чем MAC, т.к. имеет таймер в 2 раза меньше. Но вы для себя конечно должны самостоятельно определить те таймеры, которые стоит использовать.
Стоит учитывать, что данная оптимизация не убирает возникновение unknown unicast, т.к. это более чем легитимный трафик на котором строится впринципе сетевое взаимодействие, но она гарантированно его снижает и убирает возможность непрерывного цикличного появления всплесков.
M - Multicast
Ну и на последок, оставил вот это.
Что уж говорить, мультикаст - это нечто. Он особенный. При этом его почти никто никогда не использует. Вот такой достаточно закономерный результат "избыточно" сложной технологии.
В целом, мы уже чуть выше говорили про мультикаст в разрезе underlay и выделили два основных варианта передачи:
Ingress Replication
PIM-SM
Интересно то, что для остальных протоколов это по сути не имеет такого значения, т.к. всплески broadcast или unknown unicast обычно означают какую-то аварию, либо носят кратковременный эффект. Зато для multicast трафика ещё как имеет.
Смысл в том, кто будет реплицировать трафик, тот и будет нагружаться. И естественно это в разы выгоднее и логичнее делать на тех узлах, которые предназначены для обработки большого количества трафика - это наши спайны, ну или супер спайны.
Если мы используем IR, то каждый leaf, получивших поток трафика в сторону multicast, будет выдавать его делая копию локально и отправляя её по своему VTEP flood-list.
Вначале была гифка про это, вот на всякий ещё и схемка:
Очевидно, что чем больше такого трафика и VTEPов, тем сложнее ему это дастся.
И конечно же не идёт ни в какое сравнение с тем, как будет работать в данной ситуации в разы более эффективный PIM-SM и pine, на котором настроен RP (Rendezvous Point). Leaf тут просто отдаст 1 пакет, а вот spine уже его будет реплицировать.
Казалось бы, так давайте всегда делать PIM-SM, зачем нам этот IR? Слава богу, оказалось всё чуть проще.
Первоначально, Cisco на своих N9K активно продвигала идею использования PIM-SM внутри фабрики, в качестве underlay. Аргументы в принципе вы уже поняли, я их выше привёл. Но достаточно быстро стало понятно, что внутри EVPN-VXLAN, практически не бывает multicast трафика внутри сервисов. То есть задача в теории решена, да, только на практике не встречается. Но зато сколько минусов от внедрения PIM-SM... Отдельная боль - это troubleshoot, он переходит на новую фазу. Второй момент, это банальное использование дополнительного протокола, что в принципе не может упростить схему, а лишь только будет усложнять. Всё это, в итоге выливается в то, что и инженер становится дороже, и оборудование, т.к. они оба должны это уметь и понимать и поддерживать. Ну и зачем спрашивается это делать, если можно не делать вообще?
Вот и многие вендоры решили точно также. И поддерживают только IR внутри EVPN-VXLAN, про PIM-SM даже не вспоминают.
В целом, на этом можно было бы завершать рассказ про multicast, но есть ещё несколько ребят, которые его используют.
LLDP
Да, LLDP использует в качестве destination MAC - multicast. Собственно поэтому, leaf получив такой кадр, в некоторых случаях будет его рассылать внутри фабрики на всех в своём VTEP flood-list. Так что не пугайтесь, когда вы при выводе "show lldp neighbours" увидите хост, который находится в другом конце машзала...
LACP
Тут тоже самое что и LLDP, LACP использует multicast destination MAC при отправке своих BPDU. Поэтому иногда, кадр может улететь внутрь фабрики и LAG не соберётся.
STP
Надеюсь, вам не придёт в голову идея пробросить spanning-tree через фабрику, но если вдруг, то вот по этой причине оно может не сработать. Но я в вас очень верю и надеюсь, что всё-таки вы этого не сделаете.
Что-то ещё?
Да, есть ещё VRRP, HSRP, OSPF и наверняка что-то ещё. Что делать во всех этих вариантах?
Если серьёзно, то сделать так, чтобы их не возникло. Я однажды видел OSFP через фабрику для передачи анонсов внутри сервиса между хостами. Мне не понравилось. Там траблшут становится отдельным испытанием.
Чаще всего оно по дефолту выключено и само по себе не возникнет, но сетью то могут управлять несколько человек, ну или вы придёте, а там уже. Короче, легаси никто не отменял и лучше хотя бы иметь ввиду, что вот такое возможно.
Для разнообразия, вот вам ссылка на документацию Juniper - https://www.juniper.net/documentation/us/en/software/junos/evpn/topics/topic-map/l2pt-evpn-vxlan-bridged-overlay.html.
Собственно там и конфигурации и описание.
Заключение
В итоге, постарался вам показать на примерах и реальных кейсах то, что такое BUM внутри фабрики, как он работает, какие проблемы и особенности возникают.
Все приведенные мной случаи, конфигурации и примеры - всё это в какие-то моменты работы, встречалось на практике. Собственно мне всегда казалось очень важным не только понимать теорию, но и иметь практическое представление.
Не забывайте поделиться с коллегами, друзьями и тем, кто по вашему мнению будет заинтересован. Таким образом вы окажете поддержку мне и выразите свою благодарность.
Спасибо за внимание!
