return

Автоматизация Для Самых Маленьких. Часть Вторая. Дизайн сети

20 июля 2019, 21:50

В первых двух статьях я поднял вопрос автоматизации и набросал её фреймворк, во второй сделал отступление в виртуализацию сети, как первый подход к автоматизации настройки сервисов.
А теперь пришло время нарисовать схему физической сети.
Описанные в этой серии практики должны быть применимы к сети любого типа, любого масштаба с любым многообразием вендоров (нет).
Однако нельзя описать универсальный пример применения этих подходов. Поэтому я остановлюсь на современной архитектуре сети ДЦ: Фабрике Клоза. DCI сделаем на MPLS L3VPN.
В этом случае получится сравнительно простой сценарий для автоматизации, потому что имеем много оборудования, настраивающегося одинаковым образом.
Мы выберем сферический ДЦ в вакууме:
— Одна версия дизайна везде.
— Два вендора, образующих две плоскости сети.
— Один ДЦ похож на другой как две капли воды.
Содержание:

Пусть наш Сервис-Провайдер будет, например, хостить обучающие видео о выживании в застрявших лифтах.
В мегаполисах это пользуется бешенной популярностью, поэтому физических машин надо много.
Сначала я опишу сеть приблизительно такой, какой бы её хотелось видеть. А потом упрощу для лабы.


Физическая топология

Локации
У LAN_DC будет 6 ДЦ:

  • Россия (RU):
    • Москва (msk)
    • Казань (kzn)
  • Испания (SP):
    • Барселона (bcn)
    • Малага (mlg)
  • Китай (CN):
    • Шанхай (sha)
    • Сиань (sia)

В каждом ДЦ по 10 стоек с машинами, они будут нумероваться как A, B, C итд.
В каждой стойке по 30 машин. Они нас интересовать не будут.
Также в каждой стойке стоит коммутатор, к которому подключены все машины — это Top of the Rack switch — ToR или иначе в терминах фабрики Клоза будем называть его Leaf.
Именовать их будем XXX-leafY, где XXX — трёхбуквенное сокращение ДЦ, а Y — порядковый номер. Например, kzn-leaf11.

Я в статьях позволю себе достаточно фривольно обращаться терминами Leaf и ToR, как синонимами. Однако нужно помнить, что это не так.
ToR — это конкретная роль устройства в физической топологии.
Leaf — это конечное устройство в терминах Фабрики Клоза.
Так Leaf’ом может быть EndofRaw-коммутатор, например.

Каждый ToR-коммутатор в свою очередь соединён с четырьмя вышестоящими агрегирующими коммутаторами — Spine. Под Spine’ы выделено по одной стойке в ДЦ. Именовать будем аналогично: XXX-spineY.
В этой же стойке будет стоять сетевое оборудование для связности между ДЦ — 2 маршрутизатора с MPLS на борту. Но по большому счёту — это те же самые ToR’ы. То есть с точки зрения Spine-коммутаторов не имеет никакого значения обычный там ToR с подключенными машинами или маршрутизатор для DCI — один чёрт форвардить.
Такие специальные ToR’ы называются Edge-leaf. Мы их будем именовать XXX-edgeY.
Для простоты предположим, что ДЦ связаны между собой прямыми линками.
Исключим из рассмотрения внешнюю связность.

Я отдаю себе отчёт в том, что каждый раз, как я убираю какой-либо компонент, я значительно упрощаю сеть. И при автоматизации нашей абстрактной сети всё будет хорошо, а на реальной возникнут костыли.
Это так. И всё же задача этой серии — подумать и порабоnать над подходами, а не героически решать выдуманные проблемы.

На Edge-Leaf’ах underlay помещается в VPN и передаётся через MPLS-магистраль (тот самый прямой линк).
Вот такая верхнеуровневая схема получается. Задача сетевой фабрики, как мы уже определились, очень и очень простая — обеспечить IP-связность между машинами как в пределах одного ДЦ, так и между.
Оттого-то сеть и называется фабрикой, так же, например, как фабрика коммутации внутри модульных сетевых коробок, о чём подробнее можно почитать в СДСМ14.
Фабрика полностью L3. Никаких VLAN, никаких Broadcast — вот такие у нас в LAN_DC замечательные программисты, умеют писать приложения, живущие в парадигме L3, а виртуальные машины не требует Live Migration c сохранением IP-адреса.
Почему фабрика?!!!


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

Для маршрутизации внутри ДЦ будем использовать BGP.
На MPLS-магистрали OSPF+LDP.
Для DCI, то есть организации связности в андерлее — BGP L3VPN over MPLS.
На фабрике никаких OSPF и ISIS (запрещённый в Российской Федерации протокол маршрутизации).
А это значит, что не будет Auto-discovery и вычисления кратчайших путей.
Ручная (нет — автоматическая) настройка протокола, соседства и политик.
Почему BGP?
На эту тему есть целый RFC имени Facebook’a и Arista, где рассказывается, как строить очень крупные сети датацентров, используя BGP. Читается почти как художественный, очень рекомендую для томного вечера.
В нём и про Clos-топологии, и про L3-дизайны, и про BGP в качестве единственного протокола маршрутизации, и даже OPEX с CAPEX’ом. В общем мне Лапухов (он один из авторов) идею продал.
Что такое крупный — это тысячи стоек в одном датацентре, то есть это тысячи сетевых устройств. Даже при разбиении на OSPF-зоны или ISIS (запрещённый в Российской Федерации протокол маршрутизации)-level’ы проблема работы Link-State протоколов вопросы остаются: политики маршрутизации, агрегация маршрутов, а если у нас VRF, а если хочется распространять не только unicast маршруты?
При этом от BGP как протокола сигнализации между датацентрами, скорее всего, никуда не денешься.
А BGP супер-масштабируемый, расширяемый протокол, который уже показал свою эффективность на самой крупной сети нашей Солнечной системы.
Десятки и сотни тысяч (даже миллионы) маршрутов он ест на завтрак.
Как раз то, что нужно.
Тем более мы сокращаем стек используемых технологий — везде BGP.
С точки зрения маршрутизации один датацентр можно считать единым доменом маршрутизации.
Стоит вспомнить, как в середине СДСМ мы наивно смеялись над идеей BGP в качестве IGP, а теперь пришлось к ней обратиться.

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

Сессии и политики

На Leaf-коммутаторах мы импортируем в BGP префиксы с Underlay’ных интерфейсов с сетями. Допустим это будет Vlan127.
У нас будет BGP-сессия между каждой парой Leaf-Spine, в которой эти Underlay’ные префиксы будут анонсироваться по сети тудыть-сюдыть.
Внутри одного датацентра мы будем распространять специфики, которые импортировали на ТоРе. На Edge-Leaf’ах будем их агрегировать и анонсировать в удалённые ДЦ и спускать до ТоРов. То есть каждый ТоР будет знать точно, как добраться до другого ТоРа в этом же ДЦ и где точка выхода, чтобы добраться до ТоРа в другом ДЦ.
В DCI маршруты будут передаваться, как VPNv4. Для этого на Edge-Leaf интерфейс в сторону фабрики будет помещаться в VRF, назовём его UNDERLAY, и соседство с Edge-Leaf на Spine будет подниматься внутри VRF, а между Edge-Leaf’ами в VPNv4-family.
А ещё мы запретим реанонсировать маршруты полученные от вышестоящего уровня, обратно на него.
На Leaf и Spine мы не будем импортировать Loopback’и. Они нам понадобятся только для того, чтобы определить Router ID.
А вот на Edge-Leaf’ах импортируем его в Global BGP. Между Loopback-адресами Edge-Leaf’ы будут устанавливать BGP-сессию в IPv4 VPN-family друг с другом.
Между EDGE-устройствами у нас будет растянута магистраль на OSPF+LDP. Всё в одной зоне. Предельно простая конфигурация.
Вот такая картина с маршрутизацией.

BGP ASN

Edge-Leaf

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

Spine

На Spine у нас будет один ASN на ДЦ. Начнём здесь с самого первого номера из диапазона приватных AS — 64512, 64513 итд.
Почему ASN на ДЦ?
Декомпозируем этот вопрос на два:
Почему одинаковые ASN на всех Спайнах одного ДЦ,
Почему разные в разных ДЦ
Почему одинаковые ASN на всех Спайнах одного ДЦ
Вот как будет выглядеть AS-Path Андерлейного маршрута на Edge-Leaf:
[leaf1_ASN, spine_ASN, edge-leaf_ASN]
При попытке заанонсировать его обратно на Спайн, тот его отбросит потому что его AS (Spine_AS) уже есть в списке.
Однако в пределах ДЦ нас совершенно устраивает, что маршруты Underlay, поднявшиеся до Edge не смогут спуститься вниз. Вся коммуникация между хостами внутри ДЦ должна происходить в пределах Спайнов. При этом агрегированные маршруты других ДЦ в любом случае беспрепятственно будут доходить до ТоРов — в их AS-Path будет только ASN 65535 — номер AS Edge-Leaf’ов, потому что именно на них они были созданы.
Почему разные в разных ДЦ
Теоретически нам может потребоваться протащить Loopback’и каких-нибудь сервисных виртуальных машин между ДЦ.
Например, на хосте у нас запустится Route Reflector или тот самый VNGW (Virtual Network Gateway), который по BGP запирится с ТоРом и проанонсирует свой Лупбэк, который должен быть доступен из всех ДЦ.
Так вот как будет выглядеть его AS-Path:
[VNF_ASN, leaf_DC1_ASN, spine_DC1_ASN, edge-leaf_ASN, spine_DC2_ASN, leaf_DC2_ASN].
И здесь нигде не должно быть повторяющихся ASN.
То есть Spine_DC1 и Spine_DC2 должны быть разными, ровно как и ToR_DC1 и ToR_DC2, к чему мы как раз и подходим.

Как вы, наверно, знаете, существуют хаки, позволяющие принимать маршруты с повторяющимися ASN вопреки механизму предотвращения петель (allowas-in на Cisco). И у этого есть даже вполне законные применения. Но это потенциальная брешь в устойчивости сети.
И если у нас есть возможность не использовать опасные вещи, мы ей воспользуемся.

Leaf

У нас будет индивидуальный ASN на каждый Leaf-коммутаторах в пределах всей сети.
Делаем мы так из соображений, приведённых выше: AS-Path без петель, конфигурация BGP без закладок.
Чтобы маршруты между Leaf’ами беспрепятственно проходили, AS-Path должен выглядеть так:
[leaf1_ASN, spine_ASN, leaf2_ASN]
где leaf1_ASN и leaf2_ASN хорошо бы, чтобы отличались.
Требуется это и для ситуации с анонсом Лупбэка VNF между ДЦ:
[VNF_ASN, leaf_DC1_ASN, spine_DC1_ASN, edge-leaf_ASN, spine_DC2_ASN, leaf_DC2_ASN]
Будем использовать 4-байтовую ASN и генерировать его на основе ASN Spine’а и номера Leaf-коммутатора, а именно, вот так: Spine_ASN.0000X.
Вот такая картина с ASN.


IP-план

Принципиально, нам нужно выделить адреса для следующих подключений:

  1. Адреса сети Underlay между ToR и машиной. Они должны быть уникальны в пределах всей сети, чтобы любая машина могла связаться с любой другой. Отлично подходит 10/8. На каждую стойку по /26 с запасом.
  2. Линковые адреса между Leaf/Tor и Spine. Пусть это будет… 169.254.0.0/16. А именно 169.254.00X.Y/31, где X — номер Spine, Y — P2P-сеть /31. Это позволит запускать до 128 стоек, и до 10 Spine в ДЦ. Линковые адреса могут (и будут) повторять из ДЦ в ДЦ.
  3. Cтык Spine — Edge-Leaf организуем на подсетях 169.254.10X.Z/31, где точно так же X — номер Spine, Y — P2P-сеть /31.
  4. Линковые адреса из Edge-Leaf в MPLS-магистраль. Здесь ситуация несколько иная — место соединения всех кусков в один пирог, поэтому переиспользовать адресное пространство те же самые не получится — нужно выбирать следующую свободную подсеть. Поэтому за основу возьмём 192.168.0.0/16 и будем из неё выгребать свободные.
    • Адреса Loopback. Отдадим под них весь диапазон 172.16.0.0/12.
    • Leaf — по /25 на ДЦ — те же 128 стоек. Выделим по /23 на регион.
    • Spine — по /28 на ДЦ — до 16 Spine. Выделим по /26 на регион.
    • Edge-Leaf- по /29 на ДЦ — до 8 коробок. Выделим по /27 на регион.

Вот такая картина с IP-адресацией.

Префикс Роль устройства Регион ДЦ
172.16.0.0/23 edge    
172.16.0.0/27 ru  
172.16.0.0/29 msk
172.16.0.8/29 kzn
172.16.0.32/27 sp  
172.16.0.32/29 bcn
172.16.0.40/29 mlg
172.16.0.64/27 cn  
172.16.0.64/29 sha
172.16.0.72/29 sia
172.16.2.0/23 spine    
172.16.2.0/26 ru  
172.16.2.0/28 msk
172.16.2.16/28 kzn
172.16.2.64/26 sp  
172.16.2.64/28 bcn
172.16.2.80/28 mlg
172.16.2.128/26 cn  
172.16.2.128/28 sha
172.16.2.144/28 sia
172.16.8.0/21 leaf    
172.16.8.0/23 ru  
172.16.8.0/25 msk
172.16.8.128/25 kzn
172.16.10.0/23 sp  
172.16.10.0/25 bcn
172.16.10.128/25 mlg
172.16.12.0/23 cn  
172.16.12.0/25 sha
172.16.12.128/25 sia

Лаба

Два вендора. Одна сеть. АДСМ.
Juniper + Arista. Ubuntu. Старая добрая Ева.
Количество ресурсов на нашей виртуалочке в Миране всё же ограничено, поэтому для практики мы будем использовать вот такую упрощённую до предела сеть. Два датацентра: Казань и Барселона.

  • По два спайна в каждом: Juniper и Arista.
  • По одному ТоРу (Leaf’у) в каждом, с одним подключенным хостом (возьмём легковесный Cisco IOL для этого).
  • По одной ноде Edge-Leaf (пока только Juniper).
  • One Cisco switch to rile them all.
  • Помимо сетевых коробок запущена виртуальная машина-управляка. Она имеет доступ ко всем устройствам, на ней будут крутиться IPAM/DCIM-системы, букет питоновских скриптов, анзибль и что угодно ещё, что нам может понадобиться.

Полная конфигурация всех сетевых устройств, которую мы будем пробовать воспроизвести с помощью автоматики.




Полезные ссылки.
Подход к маршрутизации в L3 ДЦ описан в следующих документах:
Лапухов

Меланокс.!!!

like 460 views 1125 message 0

0 коментариев

Ещё статьи

Вебинар и лабинар по EIGRP
В четверг 18 августа в 19:30 МСК состоится очередной вебинар на тему «EIGRP», который проведёт Дмитрий Фиголь. В нём мы рассмотрим как и основы протокола EIGRP, так и продвинутые фичи. ...
like 0 4496 0
17 августа 2016
Сети для Самых Маленьких. Микровыпуск №4. Погружение в IOU
Автор статьи — Александр Sinister. Специально для проекта linkmeup. =================== Продолжая, а точнее завершая, обзор разнообразных эмуляторов оборудования Сisco Systems, я подробно остановлюсь на Cisco IOU (Cisco IOS on UNIX). ...
like 112 41971 49
28 октября 2013
Как запустить форум за один вечер
Наш проект CCIE за год семимильными шагами приближается к своему старту. Летят эссе в преддедлайновой агонии. Меж тем надо запускать форум. Тут следует сделать анонс — у нас будет два ...
like 0 4115 4
12 марта 2016