VXLAN BGP EVPN — зачем нужна VLAN для L3 VNI?

[f00z]

Причина в том, что vxlan является только уровнем 2, а для использования уровня 3 маршрутизации требуется пункт назначения/следующий узел. Таким образом, следующий узел маршрутизации находится в vrf, которому требуется MAC-адрес в качестве следующего узла, поскольку vxlan является уровнем 2, и устройство предоставляет его с помощью интерфейса vlan и идентификатора vlan. Причина, по которой ему нужен vlan, заключается в том, что это коммутатор. Если это маршрутизатор, он может использовать другой целевой адрес (маршрутизаторы имеют гораздо более высокую способность целевых адресов интерфейса, т. е. группы мостов. Они не используют vlan так часто, как продвигают поп-теги, поэтому ограничение 4k vlan отсутствует). Коммутаторы имеют место только для 4k vlan в своей таблице, и интерфейс IRB (SVI) использует одну из этих целей. Кроме того, VTEP должен знать, нужно ли выполнять поиск l3 в полученном кадре, инкапсулированном vxlan. Так, например, если VTEP получает кадр, предназначенный для L2 VNI, который сопоставлен конечной точке vlan, он знает, что нужно выполнить поиск в таблице MAC для этого кадра и отправить его. Соответственно, если кадр предназначен для L3 VNI (конечно, сопоставленного другой конечной точке VLAN), а MAC-адрес назначения является адресом маршрутизатора (SVI/IRB int), то он должен выполнить поиск на уровне 3 для локальной маршрутизации. Представьте себе VLAN как группу мостов, конечную точку, где на маршрутизаторах может быть десятки или сотни тысяч, но коммутаторы ограничены. Он должен знать, следует ли пересылать кадр на уровне 2 или выполнить поиск маршрутизации. Каждое устройство выполняет независимый поиск маршрутизации. Поскольку vxlan является только уровнем 2, это говорит ему о необходимости выполнить поиск маршрутизации. Например, у вас есть сервер на leaf1, и он использует anycast gw для доступа к серверу на leaf2 (две разные подсети), MAC-адрес anycast gw будет тем, куда сервер отправляет трафик на default gw (MAC-адрес anycast gw), этот коммутатор выполнит поиск маршрутизации и увидит, что следующим прыжком является leaf2, этот следующий прыжок должен быть смежным, который формируется ассоциацией от другого vtep, который рекламирует информацию через EVPN, база данных выходной инкапсуляции заполняется информацией о туннеле и следующим прыжком другого устройства. Это односторонний туннель, как mpls. Можно представить это так, как если бы два коммутатора были напрямую подключены без использования evpn или vxlan. Допустим, они подключены с помощью магистрального порта и разрешены vlan 50-100. Это нормально работает на уровне 2, теперь у вас есть другой физический порт, соединяющий два коммутатора, но вместо этого это порт маршрутизатора с IP-адресом x.x.x.x с обеих сторон. В основном это то, что он делает, чтобы различать маршрутизируемые и немаршрутизируемые данные. Я подозреваю, что в будущем эта конструкция изменится, потому что ASIC коммутаторов больше не проектируются с ограниченными пределами и технически могут использовать домены мостов, но в настоящее время они заблокированы на использовании идентификаторов VLAN, вероятно, из-за BU или просто потому, что к этому все привыкли на данный момент. Ладно, я немного отклонился от темы и, возможно, высказался не совсем связно. Если эта информация имеет смысл, дайте мне знать, если нет, я постараюсь пояснить более подробно.

[Sergiu.Daniluk]

Привет
[, @blazarov86] Роль L3VNI обусловлена характером реализации IRB (Integrated Routing Bridging) на устройствах Cisco. Более конкретно —
симметричного IRB
. Как это работает? Очень просто! Когда две конечные точки, расположенные в разных L2VNI (разных подсетях), VTEP инкапсулируют и пересылают маршрутизируемый трафик через L3VNI, как показано ниже: ![symmetric.jpg] У других поставщиков (Juniper, Arista) реализация IRB является
асимметричной, что
означает
,
что концепция L3VNI не существует, и входящий VTEP выполняет маршрутизацию между L2VNI, как показано на следующем рисунке: ![asymmetric.jpg] Из-за этого различия в механизмах IRB невозможно соединить две фабрики VXLAN с разными типами IRB (например, Cisco и Juniper). Если вы хотите глубже изучить VXLAN, я рекомендую следующую книгу:
«Создание центров обработки данных с помощью VXLAN BGP EVPN: перспектива Cisco NX-OS»
(иллюстрации выше взяты из этой книги). Будьте здоровы, Серджиу

[f00z]

Хороший ответ, однако другие поставщики поддерживают как симметричный, так и асимметричный IRB, а также другие функции, такие как централизованный шлюз, тогда как Cisco поддерживает ТОЛЬКО симметричный и anycast-шлюз. Вполне возможно использовать Juniper Arista и Cisco EVPN/vxlan вместе, у меня это работает в лаборатории; но поскольку Cisco заставляет вас использовать симметричный и anycast, это единственный поддерживаемый метод, который работает. VNI для L3 используется, потому что vxlan/EVPN технически является только уровнем 2, поэтому он должен создавать VNI для каждого VRF (считайте это как метку MPLS), и есть MAC VRF для уровня 2 и L3 VRF для маршрутизации, каждый с (уровнем 2) VNI. EVPN vxlan во многих случаях похож на VPLS. В определенных сценариях можно использовать комбинацию симметричного и асимметричного подхода, чтобы он работал больше как традиционная настройка типа l3vpn/l2vpn (mpls/vpls или что-то в этом роде). Cisco назвала эту «функцию» downstream VNI, но это не столько функция, сколько возможность Cisco работать, а не блокировать. Просто хотел добавить это для пояснения.
![:grinning_face_with_smiling_eyes:]

[blazarov86]

Здравствуйте, Серджиу, Спасибо за ответ, он действительно полезен и проясняет ситуацию. Однако мой пост в первую очередь посвящен проблеме «растрачивания» VLAN (дефицитного ресурса) для функции, которая не использует VLAN и L2-коммутацию, и ее негативному влиянию в реальных случаях использования. Принимая во внимание все факты, касающиеся L3VNI и симметричного/асимметричного IRB, я по-прежнему считаю ненужным и в некотором роде «произвольным» «тратить» VLAN для каждого L3VNI/VRF/Tenant. Даже с учетом всех технических тонкостей, я все равно вижу возможность реализации с помощью какого-либо другого типа виртуального интерфейса вместо интерфейса VLAN. И это не просто теоретическая проблема, я считаю, что она имеет практическое негативное влияние в реальной жизни. Если вы хотите реализовать типичную многопользовательскую среду ЦОД, в которой каждый арендатор находится в VRF и каждый арендатор имеет одну или несколько подсетей, и вы хотите довести масштабируемость «до предела», вы никогда не сможете иметь <общее количество арендаторов> (1 VLAN на каждого) + <общее количество подсетей> (1 VLAN на каждую) более 4 тыс. в домене L2. Устранение этого требования по VLAN на L3VNI дает явное преимущество, которое в самом крайнем случае (1 подсеть на арендатора) может достигать 100%. Я прав или что-то упускаю?

[f00z]

Я думаю, вы упускаете из виду тот факт, что это «тратит» только VLAN на этом конкретном листе. VLAN — это локальная сущность НА КАЖДОМ листе с EVPN. Поэтому, если у вас есть клиент на каждом порту 48-портового листа, он будет использовать 48 VLAN на этом листе, но эти VLAN используются только на этом устройстве, а не в других местах сети. Если клиенту на этом листе на порту 1 был назначен VLAN 1234, а затем клиент добавил еще один порт на другом листе, этому порту может быть назначен VLAN 333, поскольку само назначение VLAN является локальным для каждого устройства и не распространяется по сети. VNI теперь является реальным глобальным идентификатором внутри самой EVPN. Если вы думаете, что у вас будет 1000 VLAN на каждый лист, возможно, ваш проект неверный. Обычно лист — это верхнее устройство стойки, обслуживающее определенное количество серверов или клиентов, если это установка типа colo или DCI. Хотя каждый leaf может использовать только около 1000 VLAN, EVPN может иметь 16 миллионов VNI, так работает масштабирование. В большинстве документации не указано, что номера VLAN могут быть разными в разных местах, и для удобства понимания в документации используется один и тот же номер VLAN на каждом листе, чтобы показать его сопоставление с VNI. Если один клиент находится на 10 разных листьях, это может быть 10 разных VLAN (разные номера на каждом листе), но для клиента это все равно будет один и тот же VLAN. Теперь понятно?

[Sergiu.Daniluk]

В дополнение к ответу
@f00z
о масштабируемости: на одном листе в настоящее время можно настроить максимум: VLAN на узле VTEP
Коммутаторы Nexus 9200, 9300, 9300-EX, 9300-FX, 9364C и 9500, а также линейные карты X9700-EX/FX
1700 (общее количество VLAN)
1500 (VXLAN VLAN)
200 (VLAN, отличные от VXLAN) и по всей фабрике: VXLAN Layer 2 VNIs
Коммутаторы Nexus 9200, 9300, 9300-EX, 9300-FX, 9364C и 9500, а также линейные карты X9700-EX/FX
2000
VXLAN Layer 3 VNIs/VRFs
Коммутаторы Nexus 9200, 9300, 9300-EX, 9300-FX, 9364C и 9500, а также линейные карты X9700-EX/FX.
500 Ссылка:
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/92x/scalability/guide_923/b_Cisco_Nexus_9000_Series_NX-OS_Verified_Scalability_Guide_923.html#id_91722 Также обратите внимание, что это зависит от программного обеспечения, поэтому в будущем этот показатель может увеличиться. Будьте в безопасности, Серджиу

[carl.townshend]

Привет, возвращаясь к этому вопросу, что если бы другие устройства не были частью vxlan, а были только обычными vlan, то маршрутизация происходила бы только с помощью подстилающего уровня? Почему нам нужно туннелировать маршрутизируемый трафик, я не совсем понимаю?

[f00z]

Необходимость туннелирования маршрутизируемого трафика заключается в том, чтобы другие узлы знали, в какой VRF его поместить на другой стороне. Если бы был только один VRF, то в туннелировании не было бы необходимости, хотя некоторые все равно это делают, чтобы не перегружать таблицы маршрутизации на устройствах, которые в этом не нуждаются. Если устройство находится в сети и не участвует в vxlan, то «подложка» похожа на любую другую сеть l3, но тогда это устройство не может общаться с чем-либо внутри сети «надстройки». VTEP — это то, что преобразует инкапсулированный трафик из overlay в «нормальную» таблицу маршрутизации vrf/vlan на локальном устройстве. Устройство имеет VTEP, что позволяет ему помещать данные в сеть overlay, и оно должно пометить их чем-то (как тег vlan в обычной сети), чтобы другая сторона, получающая их, знала, что с ними делать. часть layer3 нуждается в VNI, чтобы определить, в какой VRF он попадает на устройствах, и поскольку vxlan является только layer2, он должен иметь отдельный, а затем еще один отдельный VNI, чтобы сообщить ему, какой MAC-VRF (т. е. таблицу vlan) использовать, когда другой конец (vtep) получает его.

[blazarov86]

Привет
[, @Sergiu.Daniluk]
и
@f00z,
спасибо за ваш дополнительный вклад — действительно в точку. Еще раз подтверждаю, что полностью понимаю и принимаю ваши аргументы по следующим вопросам: - VLAN имеют значение только на местном уровне (именно это я имел в виду, говоря
о домене L2
)
; - Другие узкие места в масштабируемости платформы, менее значимые, чем это. Они, очевидно, зависят от программного и аппаратного обеспечения и, надеюсь, поддаются улучшению. На самом деле я считаю, что все это довольно ясно и хорошо задокументировано, поэтому любой заинтересованный человек сможет это понять. Цель этой ветки — проверить мою интуицию относительно того, что связь между VLAN и L3VNI полностью оторвана от базовой технологии и принципов EVPN. До сих пор в этой ветке это не обсуждалось явно, но, похоже, это так, верно?

[xiaosyu]

Привет,
@blazarov86 Прежде всего, это связано с тем, что в вашей конфигурации EVPN используется
симметричный IRB. Вы можете представить это следующим образом: когда мы реализуем маршрутизацию между VLAN, нам необходимо создать интерфейс SVI для каждой VLAN. Коммутатор скрывает детали маршрутизации между VLAN, поэтому вам не нужно заботиться о деталях. Когда трафик идет из VLAN A в VLAN B, входным интерфейсом является SVI A, а выходным интерфейсом — SVI B. Это единственное, что мы можем узнать из конфигурации. Но в среде VXLAN EVPN, когда ваш пакет нуждается в маршрутизации между двумя VLAN, и вы также используете функцию шлюза anycast, это означает, что мы не можем предсказать, где находятся источник и назначение; пакеты могут потребовать пересечения фабрики до своего назначения, как вы знаете, вам необходимо инкапсулировать ваши пакеты с помощью заголовка VXLAN и через туннель между двумя листьевыми коммутаторами. (Конечно, когда источник и пункт назначения находятся на одном устройстве, возможно, не потребуется пересекать L3VNI? Это похоже на обычную маршрутизацию между VLAN? Я не уверен в этом.) L2VNI (подсеть A) — L3VNI — L2VNI (подсеть B) Теперь попробуйте заменить L2VNI на маршрутизатор, а L3VNI — на обычное соединение, как показано ниже: Маршрутизатор A (подсеть A) — Ethernet-соединение — Маршрутизатор B (подсеть B) Я думаю, что
симметричная
конструкция
IRB
похожа на общую топологию L3. Мы создаем промежуточную сеть между маршрутизаторами, чтобы обеспечить маршрутизацию между ними. Таким образом, можно представить, что L3VNI используется для соединения разных подсетей (например, разных маршрутизаторов), и вам просто не нужно настраивать для него IP-адрес, потому что EVPN будет использовать интерфейс loopback в качестве интерфейса источника туннеля, как вы настроили, а SVI L3VNI — это просто логический узел в сети. Но мы также можем использовать
асимметричный IRB
, в этом случае сеть EVPN похожа на большой коммутатор, а маршрутизация между L2VNI похожа на маршрутизацию между VLAN в традиционной сети. Это просто вывод, основанный на моем опыте, это предположение, я не являюсь разработчиком коммутатора, поэтому не могу знать истинную причину такого дизайна, но, честно говоря, я считаю, что это простой дизайн.

[jamesbond]

Спасибо всем за подробный ДЛИННЫЙ ответ!!