[Cisco, Сетевые технологии] VxLAN фабрика часть 4. Multipod
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр! Все еще заканчиваю цикл статей, посвященных запуску курса "Архитектор сетей" от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений машинных залов или ЦОД в одну VxLAN фабрику
Предыдущие части цикла можно найти по ссылкам:
- 1 часть цикла — L2 связанность между серверами
- 2 часть цикла — Маршрутизация между VNI
- 2.5 часть цикла — Теоретическое отступление
- 3 часть цикла — Подключение внешнего маршрутизатора/firewall
Для начала определимся какие варианты подключения существуют:
- Multipod
- Multisite
Да, вариантов не так много, однако их достаточно для решения поставленной задачи. Разберемся подробнее в каждом из способов. К уже знакомой ранее схеме, добавим второе подключение(второй ЦОД или второй машинный зал), в результате чего мы не можем подключить Leaf к уже существующему Spine. Возможно расстояние слишком большое или не хватка портов. Для простоты схемы я оставлю по одну Spine и одному Leaf коммутатору. В итоге добавляем еще один уровень в underlay сети — SuperSpine(SS):
Далее нам надо построить связанность между конечными узлами. И тут довольно много вариантов развития событий. Для начала предположим, что с одной стороны у нас есть VNI 10000 и IP адрес устройства находится в сети 10.0.0.0/24 и с другой стороны так же необходимо использовать сеть 10.0.0.0/24, предоставив один L2 домен между различными машинными залами или ЦОД.
В результате такой работы Leaf'ам необходимо поднять тоннель, по которому они будут обмениваться информацией о MAC и IP адресах:
Хорошо. С основной задачей определились. Остается понять как же построить тоннель между Leaf. А точнее как именно Leaf узнают друг о друге. Как мы помним из предыдущих частей Leaf регистрируются в сети с помощью EVPN route-type 3.
Появляется два способа передать информации EVPN о самих коммутаторах и MAC/IP адресах:
- Поднять BGP сессию между Spine:
- Поднять BGP сессию между Spine и SS
И снова есть два варианта настройки BGP сессии. C обеих сторон мы можем использовать одну и туже AS, тогда VNI будут иметь вид 65000:10000, где 65000 номер AS, 10000 — номер VNI (номера взяты из прошлых частей).
При одной AS проблем в целом не возникнет. Но, при увеличении сети, управлять одной AS может быть проблематично. Так как в iBGP требуется Full-Mesh, либо настройка Route-reflector.
Исходя из всего этого, мы будем настраивать каждую часть независимо друг от друга. То есть левый Spine находится в AS 65000. Правый Spine в AS 65010.
Остается вопрос, что делать с SS. Исходя из первого варианта SS можно использовать чисто как Underlay сеть. В целом вариант рабочий, но только до тех пор, пока в вашей сети не появится 3,4,5 и более подключенных к нему Spine. Так как между Spine придется поднимать Full-Mesh, для передачи маршрутной информации.
Второй вариант кажется более удобным — поднимать BGP сессию на SS с каждым Spine. Тогда не требуется Full-Mesh между отдельными Spine, что удобно в плане настройки и управления, но приводит к единой точке отказа (не забывайте, что каждое устройство должно дублироваться).
Так как мы ранее отнесли все Spine к разным AS, то к какой же отнести SS? Все просто — SS имеет свою AS:
Теперь у нас появился eBGP соседство и такое отношение приводит к следующей неприятной ситуации, но для начала вспомним как именно Leaf строят тоннели между собой. У Leaf есть информация о Next-hop(NH), за которым находится MAC/IP и тоннель строится до этого самого Next-Hop.
Например, есть следующая запись в таблице BGP о MAC адресе 00c1.6487.dbd1, который доступен через NH 10.255.0.3:
*> i[2]:[0]:[0]:[48]:[00c1.6487.dbd1]:[0]:[0.0.0.0]/216 *>i 10.255.0.3 100 0 64600 i
Значит и VxLAN тоннель будет строиться до этого же адреса. Но в сети появилась eBGP сессия, в которой адрес Next-Hop меняется при покидании update локальной AS. Поэтому нам потребуется дополнительная настройка на Spine и SS, которая будет запрещать смену NH адреса. Однако если мы говорим про Nexus, то данная настройка не так очевидна, как хотелось бы.
Для начала потребуется создать route-map, который запрещает смену Next_hop адреса:
route-map NH_UNCHANGED
set ip next-hop unchanged
Далее устанавливает route-map в сторону eBGP соседей:
router bgp 65000
template peer SuperSpine
remote-as 65005
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-map NH_UNCHANGED out
neighbor 10.255.1.101
inherit peer SPINE
Как вы могли заметить route-map устанавливается в адресном семействе l2vpn evpn и вы верно подумали — SS так же должен понимать evpn адресное семейство, чтобы передавать информацию различных типов EVPN. По сути включение SS мало чем отличается от подключения обычного Spine в плане настройки BGP сессии.
Хорошо, на этом можно считать, что задача выполнена, но как только мы начинаем проверять, что вся информация о MAC и IP адресах доходит до Leaf понимаем, что все не так хорошо и update так и не дошел до Leaf, а застрял на SS.
То есть вся информация дошла до SS, но он ее не отправляет дальше. Все дело в том, что тут работает обычная логика BGP и все эти маршруты не проходят проверку на Next-Hop, так как SS ничего не знает о том как добраться до Leaf (мы ведь запустили только BGP в адресном семействе l2vpn evpn). Чтобы поправить эту ситуации — запускаем OSPF между Spine и SS. То есть теперь вся сеть является единым IGP доменом. SS узнает обо всех NH и спокойно передает маршрутную информацию дальше.
Теперь радостно мы проверяем что все EVPN route-type 2 и 3 и 5 дошли до Leaf, но скорее всего нас снова постигнет разочарование. В таблице маршрутизации мы ничего не знаем об удаленных устройствах от удаленного Leaf.
Вспоминая первую часть, настройка VNI выглядела следующим образом:
evpn
vni 10000 l2
route-target import auto
route-target export auto
Route-target формируется автоматически на основе номер AS:VNI. В результате RT export для левой стороны — 65000:10000. Для правой — 65010:10000.
Так как правила import работают так же в автоматическом режиме — коммутатор не добавит маршрут с неизвестным RT в таблицу маршрутизации.
Тут можно поступить следующим образом. Вместо автоматического режима настроить RT вручную:
evpn
vni 10000 l2
route-target import 999:10000
route-target export 999:10000
То же самое касается и l3 VNI(если необходимо):
vrf context PROD
address-family ipv4 unicast
route-target both 999:99999
В результате на всех Leaf коммутаторах используется одинаковый RT, по которому маршрут будет добавлен в таблицу маршрутизации и появится связанность между конечными устройствами
оригинал
===========
Источник:
habr.com
===========
Похожие новости:
- [] Жуткие байки айтишников
- [Python, Программирование] Метаклассы в Python (перевод)
- [Информационная безопасность, Системное администрирование, Сетевые технологии] Белые начинают: так ли уж хороши “хорошие” боты?
- [IT-инфраструктура, Сетевые технологии, Сетевое оборудование] Пьеса об СКС в трех действиях, или Как мы создавали систему из 70 тысяч оптических волокон
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Сетевое оборудование] Fortinet Security Fabric на практике. Часть 1. Общий обзор
- [Сетевые технологии, Беспроводные технологии, Разработка систем связи, Научно-популярное, Космонавтика] Всё о проекте «Спутниковый интернет Starlink». Часть 9
- [Системное администрирование, Сетевые технологии, Сетевое оборудование] Linux Switchdev по-мелланоксовски
- [Системное администрирование, Сетевые технологии, Сетевое оборудование] Linux Switchdev the Mellanox way
- [Информационная безопасность, Сетевые технологии] Решения для защиты корпоративной и технологической сети: обзор продуктов Positive Technologies
- [Информационная безопасность, Системное администрирование, Сетевые технологии] Multifactor — российская система многофакторной аутентификации
Теги для поиска: #_cisco, #_setevye_tehnologii (Сетевые технологии), #_vxlan, #_evpn, #_cisco, #_nexus, #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_cisco, #_setevye_tehnologii (
Сетевые технологии
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:19
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, Хабр! Все еще заканчиваю цикл статей, посвященных запуску курса "Архитектор сетей" от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений машинных залов или ЦОД в одну VxLAN фабрику  Предыдущие части цикла можно найти по ссылкам:
Для начала определимся какие варианты подключения существуют:
Да, вариантов не так много, однако их достаточно для решения поставленной задачи. Разберемся подробнее в каждом из способов. К уже знакомой ранее схеме, добавим второе подключение(второй ЦОД или второй машинный зал), в результате чего мы не можем подключить Leaf к уже существующему Spine. Возможно расстояние слишком большое или не хватка портов. Для простоты схемы я оставлю по одну Spine и одному Leaf коммутатору. В итоге добавляем еще один уровень в underlay сети — SuperSpine(SS):  Далее нам надо построить связанность между конечными узлами. И тут довольно много вариантов развития событий. Для начала предположим, что с одной стороны у нас есть VNI 10000 и IP адрес устройства находится в сети 10.0.0.0/24 и с другой стороны так же необходимо использовать сеть 10.0.0.0/24, предоставив один L2 домен между различными машинными залами или ЦОД. В результате такой работы Leaf'ам необходимо поднять тоннель, по которому они будут обмениваться информацией о MAC и IP адресах:  Хорошо. С основной задачей определились. Остается понять как же построить тоннель между Leaf. А точнее как именно Leaf узнают друг о друге. Как мы помним из предыдущих частей Leaf регистрируются в сети с помощью EVPN route-type 3. Появляется два способа передать информации EVPN о самих коммутаторах и MAC/IP адресах:
И снова есть два варианта настройки BGP сессии. C обеих сторон мы можем использовать одну и туже AS, тогда VNI будут иметь вид 65000:10000, где 65000 номер AS, 10000 — номер VNI (номера взяты из прошлых частей). При одной AS проблем в целом не возникнет. Но, при увеличении сети, управлять одной AS может быть проблематично. Так как в iBGP требуется Full-Mesh, либо настройка Route-reflector. Исходя из всего этого, мы будем настраивать каждую часть независимо друг от друга. То есть левый Spine находится в AS 65000. Правый Spine в AS 65010. Остается вопрос, что делать с SS. Исходя из первого варианта SS можно использовать чисто как Underlay сеть. В целом вариант рабочий, но только до тех пор, пока в вашей сети не появится 3,4,5 и более подключенных к нему Spine. Так как между Spine придется поднимать Full-Mesh, для передачи маршрутной информации. Второй вариант кажется более удобным — поднимать BGP сессию на SS с каждым Spine. Тогда не требуется Full-Mesh между отдельными Spine, что удобно в плане настройки и управления, но приводит к единой точке отказа (не забывайте, что каждое устройство должно дублироваться). Так как мы ранее отнесли все Spine к разным AS, то к какой же отнести SS? Все просто — SS имеет свою AS:  Теперь у нас появился eBGP соседство и такое отношение приводит к следующей неприятной ситуации, но для начала вспомним как именно Leaf строят тоннели между собой. У Leaf есть информация о Next-hop(NH), за которым находится MAC/IP и тоннель строится до этого самого Next-Hop. Например, есть следующая запись в таблице BGP о MAC адресе 00c1.6487.dbd1, который доступен через NH 10.255.0.3: *> i[2]:[0]:[0]:[48]:[00c1.6487.dbd1]:[0]:[0.0.0.0]/216 *>i 10.255.0.3 100 0 64600 i
Значит и VxLAN тоннель будет строиться до этого же адреса. Но в сети появилась eBGP сессия, в которой адрес Next-Hop меняется при покидании update локальной AS. Поэтому нам потребуется дополнительная настройка на Spine и SS, которая будет запрещать смену NH адреса. Однако если мы говорим про Nexus, то данная настройка не так очевидна, как хотелось бы. Для начала потребуется создать route-map, который запрещает смену Next_hop адреса: route-map NH_UNCHANGED
set ip next-hop unchanged Далее устанавливает route-map в сторону eBGP соседей: router bgp 65000
template peer SuperSpine remote-as 65005 update-source loopback0 address-family l2vpn evpn send-community send-community extended route-map NH_UNCHANGED out neighbor 10.255.1.101 inherit peer SPINE Как вы могли заметить route-map устанавливается в адресном семействе l2vpn evpn и вы верно подумали — SS так же должен понимать evpn адресное семейство, чтобы передавать информацию различных типов EVPN. По сути включение SS мало чем отличается от подключения обычного Spine в плане настройки BGP сессии. Хорошо, на этом можно считать, что задача выполнена, но как только мы начинаем проверять, что вся информация о MAC и IP адресах доходит до Leaf понимаем, что все не так хорошо и update так и не дошел до Leaf, а застрял на SS.  То есть вся информация дошла до SS, но он ее не отправляет дальше. Все дело в том, что тут работает обычная логика BGP и все эти маршруты не проходят проверку на Next-Hop, так как SS ничего не знает о том как добраться до Leaf (мы ведь запустили только BGP в адресном семействе l2vpn evpn). Чтобы поправить эту ситуации — запускаем OSPF между Spine и SS. То есть теперь вся сеть является единым IGP доменом. SS узнает обо всех NH и спокойно передает маршрутную информацию дальше. Теперь радостно мы проверяем что все EVPN route-type 2 и 3 и 5 дошли до Leaf, но скорее всего нас снова постигнет разочарование. В таблице маршрутизации мы ничего не знаем об удаленных устройствах от удаленного Leaf. Вспоминая первую часть, настройка VNI выглядела следующим образом: evpn
vni 10000 l2 route-target import auto route-target export auto Route-target формируется автоматически на основе номер AS:VNI. В результате RT export для левой стороны — 65000:10000. Для правой — 65010:10000. Так как правила import работают так же в автоматическом режиме — коммутатор не добавит маршрут с неизвестным RT в таблицу маршрутизации. Тут можно поступить следующим образом. Вместо автоматического режима настроить RT вручную: evpn
vni 10000 l2 route-target import 999:10000 route-target export 999:10000 То же самое касается и l3 VNI(если необходимо): vrf context PROD
address-family ipv4 unicast route-target both 999:99999 В результате на всех Leaf коммутаторах используется одинаковый RT, по которому маршрут будет добавлен в таблицу маршрутизации и появится связанность между конечными устройствами  оригинал =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_cisco, #_setevye_tehnologii ( Сетевые технологии ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 20:19
Часовой пояс: UTC + 5