У перших двох статтях я порушив питання автоматизації та накидав її фреймворк, у другій зробив відступ у віртуалізацію мережі, як перший підхід до автоматизації налаштування сервісів.
А тепер настав час намалювати схему фізичної мережі.

Якщо ви не на короткій нозі з пристроєм мереж датацентрів, то я рекомендую почати з статті про них.

Усі випуски:

• 0. АДСМ. Частина Нульова. Планування
• 1. АДСМ. Частина перша (яка після нульової). Віртуалізація мережі
• 2. АДСМ. Частина друга. Дизайн мережі

Описані в цій серії практики повинні бути застосовні до мережі будь-якого типу, будь-якого масштабу з будь-яким різноманіттям вендорів (ні). Проте не можна описати універсальний приклад застосування цих підходів. Тому я зупинюся на сучасній архітектурі мережі ДЦ: Фабриці Клоза.
DCI зробимо на MPLS L3VPN.

Поверх фізичної мережі працює Overlay-мережа з хоста (це може бути VXLAN OpenStack'а або Tungsten Fabric або будь-що інше, що вимагає від мережі тільки базової IP-зв'язку).

У цьому випадку вийде порівняно простий сценарій для автоматизації, тому що маємо багато обладнання, яке налаштовується однаковим чином.

Ми виберемо сферичний ДЦ у вакуумі:

• Одна версія дизайну скрізь.
• Два вендори, що утворюють дві площини мережі.
• Один ДЦ схожий на інший, як дві краплі води.

Зміст

• Фізична топологія
• маршрутизація
• IP-план
• Лаба
• Висновок
• Корисні посилання

Нехай наш Сервіс-Провайдер LAN_DC буде, наприклад, хостити навчальні відео про виживання в ліфтах, що застрягли.

У мегаполісах це має шалену популярність, тому фізичних машин треба багато.

Спочатку я опишу мережу приблизно такою, якою її хотілося б бачити. А потім спрощу для лаби.

Фізична топологія

Локації

У LAN_DC буде 6 ДЦ:

• Росія (RU):
  • Москва (московське)
  • Казань (кзн)

• Іспанія (SP):
  • Барселона (bcn)
  • Малага (млг)

• Китай (CN):
  • Шанхай (ша)
  • Сіань (обидва)

Усередині ДЦ (Intra-DC)

У всіх ДЦ ідентичні мережі внутрішньої зв'язності, що базуються на топології Клоза.
Що за мережі Клоза і чому саме вони – в окремій статті.

У кожному ДЦ по 10 стійок з машинами, вони нумеруватимуться як A, B, C І так далі.

У кожній стійці по 30 машин. Вони нас не цікавитимуть.

Також у кожній стійці стоїть комутатор, до якого підключені всі машини – це Top of the Rack switch - ToR чи інакше в термінах фабрики Клоза називатимемо його Лист.

Загальна схема заводу.

Іменувати їх будемо XXX- листY, Де XXX - Трилітерне скорочення ДЦ, а Y - порядковий номер. Наприклад, kzn-leaf11.

Я в статтях дозволю собі досить фривольно звертатися до термінів Leaf і ToR, як синонімів. Однак слід пам'ятати, що це не так.
ToR це комутатор, встановлений у стійці, до якого підключаються машини.
Leaf - це роль пристрою у фізичній мережі або свитч першого рівня у термінах топології Клоза.
Тобто Leaf! = ToR.
Так Leaf'ом може бути EndofRaw-комутатор, наприклад.
Однак у рамках цієї статті будемо все ж таки звертатися ними як синонімами.

Кожен ToR-комутатор у свою чергу з'єднаний з чотирма вищими комутаторами, що агрегують. Хребет. Під Spine'и виділено по одній стійці у ДЦ. Назвати будемо аналогічно: XXX-spineY.

У цій же стійці стоятиме мережне обладнання для зв'язків між ДЦ — 2 маршрутизатори з MPLS на борту. Але за великим рахунком - це ті ж ToR'и. Тобто з погляду Spine-комутаторів не має жодного значення звичайний там ToR із підключеними машинами або маршрутизатор для DCI – один чорт форвардити.

Такі спеціальні ToR'и називаються Edge-leaf. Ми їх називатимемо XXX-обростатиY.

Виглядатиме це так.

На схемі вище edge та leaf я дійсно розмістив на одному рівні. Класичні трирівневі мережі привчили нас розглядати, аплінк (власне звідси й термін), як лінки вгору. А тут виходить «аплінк» DCI йде назад, що деяким трохи ламає звичну логіку. У разі великих мереж, коли датацентри поділяються ще на дрібніші одиниці — POD'и (Point Of Delivery), виділяють окремі Edge-PODти для DCI і виходу в зовнішні мережі.

Для зручності сприйняття надалі я все ж малюватиму Edge над Spine, при цьому ми будемо тримати в умі, що ніякого інтелекту на Spine і відмінностей при роботі зі звичайними Leaf і з Edge-leaf немає (хоча тут можуть бути нюанси, але в цілому це так).

Схема заводу з Edge-leaf'ами.

Трійця Leaf, Spine та Edge утворюють Underlay-мережу або фабрику.

Завдання мережевої фабрики (читай Underlay), як ми вже визначилися у минулому випуску, дуже і дуже проста - забезпечити IP-зв'язок між машинами як в межах одного ДЦ, так і між.
Тому мережа і називається фабрикою, так само, наприклад, як фабрика комутації всередині модульних мережевих коробок, про що докладніше можна почитати в СДСМ14.

А взагалі така топологія називається фабрикою, бо fabric у перекладі – це тканина. І важко не погодитись:

Фабрика повністю L3. Жодних VLAN, ніяких Broadcast — ось такі у нас в LAN_DC чудові програмісти, вміють писати програми, що живуть у парадигмі L3, а віртуальні машини не вимагають Live Migration із збереженням IP-адреси.

І ще раз: відповідь на запитання, чому фабрика і чому L3 — в окремій статті.

DCI - Data Center Interconnect (Inter-DC)

DCI буде організовано за допомогою Edge-Leaf, тобто вони є нашою точкою виходу в магістраль.
Для простоти припустимо, що ДЦ пов'язані між собою прямими лінками.
Виключимо із розгляду зовнішню зв'язність.

Я усвідомлюю, що кожного разу, як я прибираю якийсь компонент, я значно спрощую мережу. І при автоматизації нашої абстрактної мережі все буде добре, а на реальній виникнуть милиці.
Це так. І все ж таки завдання цієї серії — подумати і попрацювати над підходами, а не героїчно вирішувати вигадані проблеми.

На Edge-Leaf'ах underlay розміщується у VPN і передається через MPLS-магістраль (той самий прямий лінк).

Ось така верхньорівнева схема виходить.

маршрутизація

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

Загальна схема маршрутизації

На фабриці жодних OSPF та ISIS (заборонений у Російській Федерації протокол маршрутизації).

А це означає, що не буде Auto-discovery та обчислення найкоротших шляхів — лише ручне (насправді автоматичне — ми ж тут про автоматизацію) налаштування протоколу, сусідства та політик.

Схема маршрутизації BGP усередині ДЦ

Чому BGP?

На цю тему є цілий RFC імені Facebook'a та Arista, де розповідається, як будувати дуже великі мережі датацентрів за допомогою BGP. Читається майже як художній, дуже рекомендую для важкого вечора.

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

Але все ж таки якщо коротко, то ніякі IGP не підходять для мереж великих датацентрів, де рахунок мережевим пристроями йде на тисячі.

Крім того, використання BGP скрізь дозволить не розпорошуватися на підтримку декількох різних протоколів і синхронізацію між ними.

Поклавши руку на серце, на нашій фабриці, яка з великою ймовірністю не стрімко зростатиме, за очі вистачило б і OSPF. Це насправді проблеми мегаскейлерів та клауд-титанів. Але пофантазуємо лише на кілька випусків, що нам це потрібно, і будемо використовувати BGP, як заповів Петро Лапухов.

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

На Leaf-комутаторах ми імпортуємо до BGP префікси з Underlay'них інтерфейсів із мережами.
У нас буде BGP-сесія між кожній парою Leaf-Spine, в якій ці Underlay'ні префікси анонсуватимуться по мережі туди-сюди.

Усередині одного датацентру ми поширюватимемо специфіки, які імпортували на Торі. На Edge-Leaf'ах будемо їх агрегувати та анонсувати у віддалені ДЦ і спускати до Торів. Тобто кожен Тор буде знати точно, як дістатися до іншого Тор в цьому ж ДЦ і де точка входу, щоб дістатися до Тор в іншому ДЦ.

DCI маршрути будуть передаватися, як VPNv4. Для цього на Edge-Leaf інтерфейс у бік фабрики поміщатиметься у VRF, назвемо його UNDERLAY, і сусідство зі Spine на Edge-Leaf підніматиметься всередині 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 ASN

На Edge-Leaf'ах буде один ASN у всіх ДЦ. Це важливо, щоб між Edge-Leaf'ами був iBGP, і ми не накололися на нюанси eBGP. Нехай це буде 65535 XNUMX. Насправді це міг би бути номер публічної 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, не зможуть спуститися вниз. Вся комунікація між хостами всередині ДЦ має відбуватися в межах спайнів.

При цьому агреговані маршрути інших ДЦ у будь-якому випадку безперешкодно сягатимуть Торів — у їх 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.

Тобто 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.

IP-план

Принципово нам потрібно виділити адреси для наступних підключень:

1. Адреси мережі Underlay між ToR та машиною. Вони повинні бути унікальними в межах усієї мережі, щоб будь-яка машина могла зв'язатися з будь-якою іншою. Відмінно підходить 10/8. На кожну стійку /26 із запасом. Виділятимемо по /19 на ДЦ та /17 на регіон.
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.Y/31, де так само X - Номер Spine, Y - P2P-мережа /31.
4. Лінкові адреси з Edge-Leaf до MPLS-магістраль. Тут ситуація дещо інша — місце з'єднання всіх шматків в один пиріг, тому перевикористовувати ті ж адреси не вийде — потрібно вибирати наступну вільну підсіть. Тому за основу візьмемо 192.168.0.0/16 і будемо з неї вигрібати вільні.
5. Адреси Loopback. Віддамо під них весь діапазон 172.16.0.0/12.
   • Leaf - по 25 на ДЦ - ті ж 128 стійок. Виділимо по /23 на регіон.
   • Spine - по 28 на ДЦ - до 16 Spine. Виділимо по /26 на регіон.
   • Edge-Leaf - по 29 на ДЦ - до 8 коробок. Виділимо по /27 на регіон.

Якщо в ДЦ нам не вистачатиме виділених діапазонів (а їх не будуть — ми ж претендуємо на гіперскейлероство), просто виділяємо наступний блок.

Ось така картина з ІР-адресацією.

Loopback'и:

префікс
Роль пристрою
регіон
ДЦ

172.16.0.0/23
край
 
 

172.16.0.0/27
ru
 

172.16.0.0/29
московське

172.16.0.8/29
кзн

172.16.0.32/27
sp
 

172.16.0.32/29
bcn

172.16.0.40/29
млг

172.16.0.64/27
cn
 

172.16.0.64/29
ша

172.16.0.72/29
обидва

172.16.2.0/23
хребет
 
 

172.16.2.0/26
ru
 

172.16.2.0/28
московське

172.16.2.16/28
кзн

172.16.2.64/26
sp
 

172.16.2.64/28
bcn

172.16.2.80/28
млг

172.16.2.128/26
cn
 

172.16.2.128/28
ша

172.16.2.144/28
обидва

172.16.8.0/21
лист
 
 

172.16.8.0/23
ru
 

172.16.8.0/25
московське

172.16.8.128/25
кзн

172.16.10.0/23
sp
 

172.16.10.0/25
bcn

172.16.10.128/25
млг

172.16.12.0/23
cn
 

172.16.12.0/25
ша

172.16.12.128/25
обидва

Підкладка:

префікс
регіон
ДЦ

10.0.0.0/17
ru
 

10.0.0.0/19
московське

10.0.32.0/19
кзн

10.0.128.0/17
sp
 

10.0.128.0/19
bcn

10.0.160.0/19
млг

10.1.0.0/17
cn
 

10.1.0.0/19
ша

10.1.32.0/19
обидва

Лаба

Два вендори. Одна мережа. АДСМ.

Juniper + Arista. Ubuntu. Стара добра Єва.

Кількість ресурсів на нашій віртуалочці в Мірані все ж таки обмежена, тому для практики ми будемо використовувати ось таку спрощену до межі мережу.

Два датацентри: Казань та Барселона.

• По два спайни в кожному: Juniper та Arista.
• По одному тору (Leaf'у) у кожному - Juniper і Arista, з одним підключеним хостом (візьмемо легковажний Cisco IOL для цього).
• По одній ноді Edge-Leaf (поки що тільки Juniper).
• Один Cisco перемикається до всіх них.
• Окрім мережевих коробок запущено віртуальну машину-управителя. Під керуванням Ubuntu.
  Вона має доступ до всіх пристроїв, на ній будуть крутитися IPAM/DCIM-системи, букет пітонівських скриптів, анзибль і будь-що, що нам може знадобитися.

Повна конфігурація всіх мережевих пристроїв, яку ми намагатимемося відтворити за допомогою автоматики.

Висновок

Так само заведено? Під кожною статтею робити короткий висновок?

Отже, ми вибрали трирівневу мережа Клоза всередині ДЦ, оскільки очікуємо багато East-West трафіку та хочемо ECMP.

Розділили мережу на фізичну (андерлей) та віртуальну (оверлей). При цьому оверлей починається з хоста, тим самим спростивши вимоги до андерлею.

Вибрали BGP як протокол маршрутизації анедрелейних мереж за його масштабованість та гнучкість політик.

У нас будуть окремі вузли для організації DCI – Edge-leaf.
На магістралі буде OSPF+LDP.
DCI буде реалізовано на основі MPLS L3VPN.
Для P2P-лінків IP-адреси ми обчислюватимемо алгоритмічно на основі імен пристроїв.
Лупбеки будемо призначати за роллю пристроїв та їх розташуванням послідовно.
Андерлейні префікси – тільки на Leaf-комутатори послідовно на основі їхнього розташування.

Припустимо, що зараз у нас ще не встановлено обладнання.
Тому наші наступні кроки будуть завести їх у системах (IPAM, інвентарна), організувати доступ, згенерувати конфігурацію та задеплоїти її.

У наступній статті розберемося з Netbox – системою інвентаризації та управління IP-простором у ДЦ.

Дякую

• Андрію Глазкову aka @glazgoo за вичитку та правки
• Олександру Клименку aka @v00lk за вичитку та правки
• Артему Чорнобаю за КДПВ

Джерело: habr.com