VXLAN BGP EVPN — зачем нужна VLAN для L3 VNI?
-
Привет
[, @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»
(иллюстрации выше взяты из этой книги). Будьте здоровы, Серджиу
-
Хороший ответ, однако другие поставщики поддерживают как симметричный, так и асимметричный 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:]
-
Здравствуйте, Серджиу, Спасибо за ответ, он действительно полезен и проясняет ситуацию. Однако мой пост в первую очередь посвящен проблеме «растрачивания» VLAN (дефицитного ресурса) для функции, которая не использует VLAN и L2-коммутацию, и ее негативному влиянию в реальных случаях использования. Принимая во внимание все факты, касающиеся L3VNI и симметричного/асимметричного IRB, я по-прежнему считаю ненужным и в некотором роде «произвольным» «тратить» VLAN для каждого L3VNI/VRF/Tenant. Даже с учетом всех технических тонкостей, я все равно вижу возможность реализации с помощью какого-либо другого типа виртуального интерфейса вместо интерфейса VLAN. И это не просто теоретическая проблема, я считаю, что она имеет практическое негативное влияние в реальной жизни. Если вы хотите реализовать типичную многопользовательскую среду ЦОД, в которой каждый арендатор находится в VRF и каждый арендатор имеет одну или несколько подсетей, и вы хотите довести масштабируемость «до предела», вы никогда не сможете иметь <общее количество арендаторов> (1 VLAN на каждого) + <общее количество подсетей> (1 VLAN на каждую) более 4 тыс. в домене L2. Устранение этого требования по VLAN на L3VNI дает явное преимущество, которое в самом крайнем случае (1 подсеть на арендатора) может достигать 100%. Я прав или что-то упускаю?
-
Я думаю, вы упускаете из виду тот факт, что это «тратит» только 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. Теперь понятно?
-
В дополнение к ответу
@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 Также обратите внимание, что это зависит от программного обеспечения, поэтому в будущем этот показатель может увеличиться. Будьте в безопасности, Серджиу -
Привет, возвращаясь к этому вопросу, что если бы другие устройства не были частью vxlan, а были только обычными vlan, то маршрутизация происходила бы только с помощью подстилающего уровня? Почему нам нужно туннелировать маршрутизируемый трафик, я не совсем понимаю?
-
Необходимость туннелирования маршрутизируемого трафика заключается в том, чтобы другие узлы знали, в какой VRF его поместить на другой стороне. Если бы был только один VRF, то в туннелировании не было бы необходимости, хотя некоторые все равно это делают, чтобы не перегружать таблицы маршрутизации на устройствах, которые в этом не нуждаются. Если устройство находится в сети и не участвует в vxlan, то «подложка» похожа на любую другую сеть l3, но тогда это устройство не может общаться с чем-либо внутри сети «надстройки». VTEP — это то, что преобразует инкапсулированный трафик из overlay в «нормальную» таблицу маршрутизации vrf/vlan на локальном устройстве. Устройство имеет VTEP, что позволяет ему помещать данные в сеть overlay, и оно должно пометить их чем-то (как тег vlan в обычной сети), чтобы другая сторона, получающая их, знала, что с ними делать. часть layer3 нуждается в VNI, чтобы определить, в какой VRF он попадает на устройствах, и поскольку vxlan является только layer2, он должен иметь отдельный, а затем еще один отдельный VNI, чтобы сообщить ему, какой MAC-VRF (т. е. таблицу vlan) использовать, когда другой конец (vtep) получает его.
-
Привет
[, @Sergiu.Daniluk]
и
@f00z,
спасибо за ваш дополнительный вклад — действительно в точку. Еще раз подтверждаю, что полностью понимаю и принимаю ваши аргументы по следующим вопросам: - VLAN имеют значение только на местном уровне (именно это я имел в виду, говоря
о домене L2
)
; - Другие узкие места в масштабируемости платформы, менее значимые, чем это. Они, очевидно, зависят от программного и аппаратного обеспечения и, надеюсь, поддаются улучшению. На самом деле я считаю, что все это довольно ясно и хорошо задокументировано, поэтому любой заинтересованный человек сможет это понять. Цель этой ветки — проверить мою интуицию относительно того, что связь между VLAN и L3VNI полностью оторвана от базовой технологии и принципов EVPN. До сих пор в этой ветке это не обсуждалось явно, но, похоже, это так, верно? -
Привет,
@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 в традиционной сети. Это просто вывод, основанный на моем опыте, это предположение, я не являюсь разработчиком коммутатора, поэтому не могу знать истинную причину такого дизайна, но, честно говоря, я считаю, что это простой дизайн. -
Спасибо всем за подробный ДЛИННЫЙ ответ!!
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти