Маршрутизация

Для маршрутизации внутри ДЦ будем использовать BGP. На MPLS-магистрали OSPF+LDP. Для DCI, то есть организации связности в андерлее - BGP L3VPN over MPLS.

https://fs.linkmeup.ru/images/adsm/2/bird_view.png

Общая схема маршрутизации

На фабрике никаких OSPF и ISIS (запрещённый в Российской Федерации протокол маршрутизации). А это значит, что не будет Auto-discovery и вычисления кратчайших путей - только ручная (на самом деле автоматическая - мы же здесь про автоматизацию) настройка протокола, соседства и политик.

https://fs.linkmeup.ru/images/adsm/2/bgp_in_dc.png

Схема маршрутизации BGP внутри ДЦ

Почему BGP? На эту тему есть целый RFC имени Facebook’a и Arista, где рассказывается, как строить очень крупные сети датацентров, используя BGP. Читается почти как художественный, очень рекомендую для томного вечера.

А ещё целый раздел в моей статье посвящён этому. Куда я вас и отсылаю.

Но всё же если коротко, то никакие IGP не подходят для сетей крупных датацентров, где счёт сетевым устройствами идёт на тысячи. Кроме того использование BGP везде позволит не распыляться на поддержку нескольких разных протоколов и синхронизацию между ними.

Положа руку на сердце, на нашей фабрике, которая с большой долей вероятности не будет стремительно расти, за глаза хватило бы и OSPF. Это на самом деле проблемы мегаскейлеров и клауд-титанов. Но пофантазируем всего лишь на несколько выпусков, что нам это нужно, и будем использовать BGP, как завещал Пётр Лапухов.

Политики маршрутизации

На Leaf-коммутаторах мы импортируем в BGP префиксы с Underlay’ных интерфейсов с сетями. У нас будет BGP-сессия между каждой парой Leaf-Spine, в которой эти Underlay’ные префиксы будут анонсироваться по сети тудыть-сюдыть.

https://fs.linkmeup.ru//images/adsm/2/bgp_sessions.png

Внутри одного датацентра мы будем распространять специфики, которые импортировали на ТоРе. На Edge-Leaf’ах будем их агрегировать и анонсировать в удалённые ДЦ и спускать до ТоРов. То есть каждый ТоР будет знать точно, как добраться до другого ТоРа в этом же ДЦ и где точка входа, чтобы добраться до ТоРа в другом ДЦ. В DCI маршруты будут передаваться, как VPNv4. Для этого на Edge-Leaf интерфейс в сторону фабрики будет помещаться в VRF, назовём его UNDERLAY, и соседство со Spine на Edge-Leaf будет подниматься внутри VRF, а между Edge-Leaf’ами в VPNv4-family.

https://fs.linkmeup.ru/images/adsm/2/routing.png

А ещё мы запретим реанонсировать маршруты полученные от спайнов, обратно на них же.

https://fs.linkmeup.ru/images/adsm/2/no_reannounce.png

На Leaf и Spine мы не будем импортировать Loopback’и. Они нам понадобятся только для того, чтобы определить Router ID. А вот на Edge-Leaf’ах импортируем его в Global BGP. Между Loopback-адресами Edge-Leaf’ы будут устанавливать BGP-сессию в IPv4 VPN-family друг с другом.

Между EDGE-устройствами у нас будет растянута магистраль на OSPF+LDP. Всё в одной зоне. Предельно простая конфигурация.

Вот такая картина с маршрутизацией.

BGP ASN

Edge-Leaf ASN

На Edge-Leaf’ах будет один ASN во всех ДЦ. Это важно, чтобы между Edge-Leaf’ами был iBGP, и мы не накололись на нюансы eBGP. Пусть это будет 65535. В реальности это мог бы быть номер публичной AS.

Spine ASN

На Spine у нас будет один ASN на ДЦ. Начнём здесь с самого первого номера из диапазона приватных AS - 64512, 64513 итд. Почему ASN на ДЦ? Декомпозируем этот вопрос на два:

  • Почему одинаковые ASN на всех спайнах одного ДЦ?
  • Почему разные в разных ДЦ?

Почему одинаковые ASN на всех спайнах одного ДЦ Вот как будет выглядеть AS-Path Андерлейного маршрута на Edge-Leaf:

[leafX_ASN, spine_ASN, edge_ASN]

При попытке заанонсировать его обратно на Спайн, тот его отбросит потому что его AS (Spine_AS) уже есть в списке.

Однако в пределах ДЦ нас совершенно устраивает, что маршруты Underlay, поднявшиеся до Edge не смогут спуститься вниз. Вся коммуникация между хостами внутри ДЦ должна происходить в пределах уровня спайнов.

https://fs.linkmeup.ru/images/adsm/2/as_path_intra_dc.png

При этом агрегированные маршруты других ДЦ в любом случае беспрепятственно будут доходить до ТоРов - в их AS-Path будет только ASN 65535 - номер AS Edge-Leaf’ов, потому что именно на них они были созданы.

Почему разные в разных ДЦ Теоретически нам может потребоваться протащить Loopback’и каких-нибудь сервисных виртуальных машин между ДЦ. Например, на хосте у нас запустится Route Reflector или тот самый VNGW (Virtual Network Gateway), который по BGP запирится с ТоРом и проанонсирует свой лупбэк, который должен быть доступен из всех ДЦ. Так вот как будет выглядеть его AS-Path:

[VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

И здесь нигде не должно быть повторяющихся ASN.

https://fs.linkmeup.ru/images/adsm/2/as_path_inter_dc.png
То есть Spine_DC1 и Spine_DC2 должны быть разными, ровно как и leafX_DC1 и leafY_DC2, к чему мы как раз и подходим.
Как вы, наверно, знаете, существуют хаки, позволяющие принимать маршруты с повторяющимися ASN вопреки механизму предотвращения петель (allowas-in на Cisco). И у этого есть даже вполне законные применения. Но это потенциальная брешь в устойчивости сети. И я лично в неё пару раз проваливался. И если у нас есть возможность не использовать опасные вещи, мы ей воспользуемся.

Leaf ASN

У нас будет индивидуальный ASN на каждом Leaf-коммутаторе в пределах всей сети. Делаем мы так из соображений, приведённых выше: AS-Path без петель, конфигурация BGP без закладок. Чтобы маршруты между Leaf’ами беспрепятственно проходили, AS-Path должен выглядеть так:

 [leafX_ASN, spine_ASN, leafY_ASN]

где leafX_ASN и leafY_ASN хорошо бы, чтобы отличались. Требуется это и для ситуации с анонсом лупбэка VNF между ДЦ:

 [VNF_ASN, leafX_DC1_ASN, spine_DC1_ASN, edge_ASN, spine_DC2_ASN, leafY_DC2_ASN]

Будем использовать 4-байтовый ASN и генерировать его на основе ASN Spine’а и номера Leaf-коммутатора, а именно, вот так: Spine_ASN.0000X.

Вот такая картина с ASN.

https://fs.linkmeup.ru/images/adsm/2/asns.png