О протоколах OSPF,BGP, VxLan

Введение. Зачем нужны эти три протокола?

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

OSPF (Open Shortest Path First)

Это IGP — Interior Gateway Protocol, протокол внутренней маршрутизации. Его задача — обеспечить полную связность IP-маршрутов внутри одной административной зоны (одного предприятия, одного датацентра, одной автономной системы). OSPF быстро сходится после изменений топологии, поддерживает иерархию через концепцию областей (areas) и считает кратчайшие пути на основе метрики стоимости (cost), вычисляемой по алгоритму Дейкстры. OSPF — это «нервная система» внутренней сети.

BGP (Border Gateway Protocol)

Это EGP — Exterior Gateway Protocol, протокол маршрутизации между автономными системами. BGP — это протокол всего интернета: именно он соединяет провайдеров, операторов связи и крупные корпоративные сети друг с другом. В отличие от OSPF, BGP не считает «кратчайший путь» в технологическом смысле — он реализует политику маршрутизации, позволяя владельцу сети управлять тем, через какие соседние AS пускать трафик, какие маршруты анонсировать наружу и какие принимать. В современных датацентрах BGP всё чаще используется и как IGP — это архитектура BGP-only fabric (например, в Clos/Spine-Leaf топологиях).

VXLAN (Virtual eXtensible LAN)

Это технология сетевой инкапсуляции — оверлей (overlay), позволяющий передавать L2-кадры Ethernet поверх IP-сети (underlay). VXLAN решает фундаментальную проблему классического VLAN: ограничение в 4096 сегментов, а также невозможность растягивать L2-домен через L3-маршрутизацию. С VXLAN можно построить логические L2-сегменты (24-битный VNI даёт более 16 миллионов идентификаторов) поверх любой IP-инфраструктуры — между разными датацентрами, между стойками внутри ДЦ, между регионами облака.

Как они работают вместе

В современном датацентре типичная архитектура выглядит так: underlay-сеть между Spine- и Leaf-коммутаторами строится на BGP (часто eBGP с разными номерами AS на каждом коммутаторе) или на OSPF. Поверх этого underlay строится VXLAN-оверлей, плоскость управления которого реализована через MP-BGP EVPN (это семейство адресов BGP для распространения MAC- и IP-маршрутов). Таким образом, все три протокола работают одновременно: OSPF/BGP обеспечивают IP-связность, VXLAN инкапсулирует пользовательский трафик, а EVPN распространяет информацию о MAC-адресах и хостах между VTEP-устройствами.

ПРИМЕЧАНИЕ. Эта лекция построена так, чтобы каждый раздел можно было читать независимо, но рекомендуется изучать в указанном порядке: OSPF даёт фундамент понимания link-state протоколов, BGP — это путь от IGP к политике, а VXLAN/EVPN объединяет всё в современную фабрику.

Модуль 1. OSPF — протокол link-state маршрутизации

1.1. Принципы работы и место в иерархии

OSPF (Open Shortest Path First) — это link-state протокол маршрутизации, разработанный IETF и описанный в RFC 2328 (OSPFv2 для IPv4) и RFC 5340 (OSPFv3 для IPv6). Под «link-state» понимается принцип, при котором каждый маршрутизатор не получает готовые маршруты от соседей (как в distance-vector протоколах вроде RIP), а получает информацию о состоянии всех связей в сети и самостоятельно строит граф топологии, после чего применяет к нему алгоритм Дейкстры для вычисления кратчайших путей.

Принципиальное отличие link-state от distance-vector состоит в том, что каждый маршрутизатор имеет полную картину топологии своей области (area). Это даёт три ключевых преимущества: быструю сходимость (convergence) при изменениях, отсутствие маршрутных петель в пределах area, и возможность принимать решения на основе всего графа, а не только мнения соседа.

Базовый цикл работы OSPF

Маршрутизатор обнаруживает соседей через Hello-пакеты, рассылаемые на multicast-адреса 224.0.0.5 (все OSPF-маршрутизаторы) и 224.0.0.6 (только DR/BDR на multi-access сегментах).

Между соседями устанавливается отношение adjacency, в ходе которого они обмениваются базами данных состояния каналов (LSDB — Link-State Database).

Каждое изменение топологии — например, упавший интерфейс — порождает LSA (Link-State Advertisement), который flood-ится по всей area.

Получив новый LSA, маршрутизатор обновляет LSDB и запускает алгоритм SPF (Дейкстры) для перерасчёта дерева кратчайших путей.

Результат SPF-расчёта помещается в RIB (Routing Information Base), а оттуда лучшие маршруты попадают в FIB (Forwarding Information Base).

1.2. Hello-протокол и установление соседства

Hello-пакет — это сердце OSPF. Он рассылается каждые HelloInterval секунд (по умолчанию 10 на point-to-point и broadcast-сегментах, 30 — на NBMA). Если маршрутизатор не слышит Hello от соседа в течение DeadInterval (по умолчанию 4 × HelloInterval), соседство считается потерянным, и LSA об этом флудятся по сети.

Параметры, которые ДОЛЖНЫ совпадать для установления соседства

Area ID — оба маршрутизатора должны быть в одной OSPF-области на этом интерфейсе.

Subnet и netmask — соседи должны быть в одной IP-подсети (исключение: интерфейсы типа point-to-point).

HelloInterval и DeadInterval — таймеры должны быть идентичны.

Authentication — если включена, тип и ключ должны совпадать.

Stub area flag — если area объявлена как stub на одном маршрутизаторе, она должна быть stub на всех.

MTU — совпадение MTU проверяется при обмене DBD-пакетами; несовпадение приведёт к застреванию на состоянии EXSTART/EXCHANGE.

Состояния соседства

Процесс установления adjacency проходит через несколько состояний, и при диагностике важно понимать, на каком этапе застряла сессия:

Состояние

Что происходит

Down

Hello не получены в течение DeadInterval

Attempt

NBMA-сегмент: маршрутизатор пытается явно слать unicast Hello

Init

Получен Hello от соседа, но в нём не было нашего RID

2-Way

Получен Hello, в котором сосед перечисляет нас. На broadcast-сегментах далее выбирается DR/BDR; non-DR-роутеры могут остаться в 2-Way с другими non-DR

ExStart

Master/Slave определены, генерируется первый DBD

Exchange

Обмен DBD-пакетами — описанием LSDB

Loading

Запросы LSR/ответы LSU для недостающих LSA

Full

База синхронизирована, соседство полностью установлено

ПРИМЕЧАНИЕ. Если соседство застряло в состоянии EXSTART/EXCHANGE — это почти всегда несовпадение MTU между интерфейсами. Команды диагностики: «show ip ospf neighbor» (Cisco) или «get router info ospf neighbor» (FortiGate).

1.3. Типы сетей в OSPF

OSPF различает несколько типов сетей, и от типа зависит то, как формируются adjacency, нужны ли DR/BDR и как анонсируются маршруты.

Тип сети

DR/BDR

Hello timer

Применение

Point-to-Point

Нет

10 сек

Прямая линия между двумя роутерами

Broadcast (Ethernet)

Да

10 сек

LAN-сегмент с несколькими роутерами

Non-Broadcast (NBMA)

Да

30 сек

Frame Relay full-mesh

Point-to-Multipoint

Нет

30 сек

Hub-and-spoke без полной mesh

Loopback

Не применимо

—

Анонсируется как /32 host-маршрут

DR и BDR — зачем нужны

На multi-access сегменте (Ethernet с тремя и более маршрутизаторами) flooding LSA становится проблемой: если каждый маршрутизатор будет устанавливать full adjacency с каждым, количество adjacencies растёт квадратично (n × (n-1) / 2). Для решения этой проблемы выбираются Designated Router (DR) и Backup Designated Router (BDR). Все остальные маршрутизаторы (DROther) устанавливают full adjacency только с DR и BDR, а с другими DROther остаются в состоянии 2-Way.

Когда DROther хочет анонсировать LSA, он отправляет его на 224.0.0.6 (только DR/BDR), DR ретранслирует его всем через 224.0.0.5. Это сводит трафик flooding-а к линейному.

Выбор DR/BDR происходит по двум критериям: сначала по OSPF priority интерфейса (по умолчанию 1, 0 означает «никогда не быть DR»), затем по Router-ID. Процесс non-preemptive: если в сегмент позже придёт маршрутизатор с более высоким priority/RID, он не вытеснит уже выбранного DR.

1.4. Router-ID и его значение

Router-ID — это уникальный 32-битный идентификатор OSPF-процесса, имеющий формат IPv4-адреса (но это именно идентификатор, а не маршрутизируемый адрес). Алгоритм выбора RID при отсутствии явной конфигурации:

Если задан явный «router-id X.X.X.X» — используется он.

Иначе — самый высокий IP-адрес среди up-loopback интерфейсов.

Иначе — самый высокий IP-адрес среди up-физических интерфейсов.

Лучшая практика — всегда явно задавать RID, привязывая его к адресу loopback-интерфейса. Loopback не падает при отказе физического интерфейса, и адрес остаётся стабильным. Изменение RID требует перезапуска OSPF-процесса (clear ip ospf process), что вызовет переустановление всех соседств.

1.5. Areas и иерархия OSPF

OSPF масштабируется через концепцию areas (областей). В пределах одной area все маршрутизаторы имеют идентичную LSDB. Между areas обмен происходит через ABR (Area Border Router) — маршрутизатор, имеющий интерфейсы в нескольких areas. Backbone area (Area 0) — обязательная центральная область; все остальные areas должны подключаться к ней либо напрямую, либо через виртуальные линки (virtual links).

Типы areas

Тип area

LSA Type 5 (External)

LSA Type 3 (Inter-Area)

LSA Type 7 (NSSA)

Standard (нормальная)

Разрешены

Разрешены

Не применяется

Stub

Запрещены, заменяются default

Разрешены

Не применяется

Totally Stubby

Запрещены, заменяются default

Запрещены, заменяются default

Не применяется

NSSA

Запрещены

Разрешены

Разрешены, конвертируются в Type 5 на ABR

Totally NSSA

Запрещены

Запрещены, заменяются default

Разрешены

Зачем нужны разные типы area

Stub и Totally Stubby используются для уменьшения размера LSDB на устройствах в удалённых филиалах или на маршрутизаторах с ограниченной памятью. Если филиал имеет только один путь наружу через ABR, нет смысла знать о всех external маршрутах — достаточно default-маршрута. NSSA (Not-So-Stubby Area) — гибрид: позволяет редистрибьюцию из других протоколов внутри area (через LSA Type 7), но блокирует внешние LSA из других area-ов. Применяется, когда в stub-area нужно подключить, например, BGP-сессию или статический маршрут наружу.

1.6. Типы LSA — фундамент LSDB

LSA — это блок информации, описывающий часть топологии. Их существует 11 типов, но на практике в IPv4 OSPFv2 используются 1, 2, 3, 4, 5 и 7. Знание типов LSA необходимо для глубокой диагностики, потому что команда «show ip ospf database» выводит именно по типам.

Тип

Название

Что описывает

Где flood-ится

1

Router LSA

Все интерфейсы и стоимости одного маршрутизатора

Внутри area

2

Network LSA

Multi-access сегмент с DR; список присоединённых роутеров

Внутри area, генерирует только DR

3

Summary LSA (Inter-Area)

Маршрут из другой area, генерируемый ABR

В соседнюю area

4

Summary ASBR LSA

Положение ASBR относительно ABR

В соседнюю area

5

External LSA

Внешний маршрут, редистрибутированный ASBR

По всем areas, кроме stub/NSSA

7

NSSA External LSA

Аналог Type 5 внутри NSSA

Внутри NSSA, конвертируется в Type 5 на ABR

Метрики external маршрутов: E1 vs E2

При редистрибьюции внешних маршрутов в OSPF можно выбрать тип метрики:

E2 (по умолчанию) — метрика остаётся той, что задана при редистрибьюции, и не увеличивается при прохождении через сеть. Используется, когда внутренняя стоимость пути не важна по сравнению с внешней.

E1 — к метрике external добавляется внутренняя стоимость пути от вычислителя до ASBR. Применяется, когда хочется выбирать external маршрут с учётом «своей» стоимости.

При наличии нескольких маршрутов: E1 предпочтительнее E2, при равенстве типа — меньшая метрика, при равенстве метрик — ближайший ASBR.

1.7. Алгоритм SPF и метрика стоимости

Алгоритм Дейкстры (SPF) строит дерево кратчайших путей от вычисляющего маршрутизатора (root) до всех остальных узлов LSDB. Стоимость пути — сумма стоимостей интерфейсов выхода вдоль маршрута. Стоимость одного интерфейса по умолчанию вычисляется как:

cost = reference-bandwidth / interface-bandwidth

Reference-bandwidth по умолчанию равна 100 Мбит/с, что было разумно в 90-х, но в современных сетях с 10G/40G/100G интерфейсами это создаёт проблему: все эти линки получают cost=1 (округление к минимуму), и OSPF не может различить более быстрые от менее быстрых. Поэтому при наличии 10G+ интерфейсов обязательно нужно увеличить reference-bandwidth до 100000 (100 Гбит/с) или 1000000 командой «auto-cost reference-bandwidth». Очень важно сделать это согласованно на всех маршрутизаторах area, иначе пути будут считаться по-разному.

iSPF и partial SPF

Полный пересчёт SPF для большой LSDB может занимать сотни миллисекунд CPU и потенциально приводить к временным петлям в момент сходимости. Современные реализации используют incremental SPF (iSPF) — пересчитывают только изменённую часть дерева. Кроме того, partial SPF применяется при изменении только Summary LSA (Type 3), когда внутренняя топология area не изменилась.

1.8. OSPF на FortiGate — практические нюансы

В контексте FortiGate OSPF имеет несколько практических особенностей, которые регулярно встречаются при эксплуатации:

Конфигурация через CLI

config router ospf set router-id 10.0.0.1 set default-information-originate enable config area edit 0.0.0.0 next end config network edit 1 set prefix 10.0.0.0 255.255.255.0 set area 0.0.0.0 next end config ospf-interface edit "wan1_ospf" set interface "wan1" set hello-interval 10 set dead-interval 40 set network-type point-to-point next endend

OSPF поверх IPSec VPN

Один из частых сценариев — запуск OSPF поверх IPSec-туннелей для динамического выбора резервного пути. Здесь критически важно: IPSec-интерфейс должен быть с режимом «net-device disable» в interface-mode (route-based VPN), интерфейс должен иметь IP-адрес, и тип сети рекомендуется ставить point-to-point (не broadcast — это породит ненужные DR-выборы и multicast-проблемы внутри туннеля).

Аутентификация

OSPFv2 поддерживает три типа аутентификации: Null (без аутентификации), Simple Password (передаётся открытым текстом, годится только для защиты от случайных ошибок) и MD5/HMAC-SHA (криптографическая, рекомендуется для продакшен-сетей). Аутентификация настраивается per-interface и должна совпадать у обеих сторон.

1.9. Диагностика и устранение проблем OSPF

Сосед застрял в Init или 2-Way

Проверьте multicast: на L2-сегменте может быть включён IGMP snooping без OSPF-исключения, который блокирует 224.0.0.5/6.

Проверьте ACL на интерфейсах — мог быть случайно заблокирован OSPF (IP protocol 89).

При 2-Way между двумя non-DR в broadcast-сегменте — это нормально, full adjacency в multi-access сегменте устанавливается только с DR/BDR.

Сосед застрял в EXSTART/EXCHANGE

Несовпадение MTU — самая частая причина. Команда «mtu-ignore» на интерфейсе позволяет обойти проверку, но это маскирует проблему.

Дубль Router-ID — два маршрутизатора с одинаковым RID не могут установить полное соседство.

Маршруты не появляются в RIB

Проверьте «show ip ospf database» — есть ли соответствующий LSA в LSDB.

Если LSA есть, но маршрута нет — возможно, проблема с next-hop reachability (RFC 2328 требует, чтобы next-hop был в той же area или был достижим через intra-area путь).

Проверьте Administrative Distance: если есть тот же префикс через статический маршрут или другой протокол с меньшим AD, OSPF-маршрут будет в RIB, но не в FIB.

Постоянные пересчёты SPF

Flapping интерфейс генерирует серии LSA. Современные реализации используют SPF throttling — нарастающие задержки между расчётами. Включите OSPF flooding throttling и LSA pacing.

Проверьте логи на «SPF run» — частые запуски указывают на нестабильность underlay.

Модуль 2. BGP — протокол маршрутизации интернета и фабрики ДЦ

2.1. BGP в контексте: AS, eBGP, iBGP

BGP — Border Gateway Protocol, версия 4 (BGPv4) описана в RFC 4271. Это path-vector протокол: вместо распространения состояния каналов, как OSPF, или вектора расстояния, как RIP, BGP передаёт в каждом анонсе полный список автономных систем (AS_PATH), через которые префикс был получен. Это даёт два важных свойства: естественную защиту от петель (получив анонс с собственным AS в пути, маршрутизатор отбрасывает его) и базу для применения политики маршрутизации.

Автономная система (AS)

AS — это совокупность IP-сетей и маршрутизаторов под единым административным управлением, имеющая единую политику маршрутизации по отношению к внешнему миру. Номера AS бывают:

Публичные 16-битные: 1–64495, выдаются IANA через RIR-ы (RIPE, ARIN, APNIC и т.д.).

Приватные 16-битные: 64512–65534, для использования внутри организации.

Публичные 32-битные: 131072–4199999999, появились в 2007 году (RFC 6793) из-за исчерпания 16-битного пространства.

Приватные 32-битные: 4200000000–4294967294.

eBGP против iBGP

BGP-сессии бывают двух типов в зависимости от того, между какими AS они установлены:

Параметр

eBGP (External)

iBGP (Internal)

Между чем устанавливается

Между разными AS

Внутри одной AS

TTL по умолчанию

1 (нужен ebgp-multihop, если не сосед)

255

Изменение AS_PATH

Свой AS добавляется при анонсе

AS_PATH не изменяется

Изменение NEXT_HOP

Меняется на исходящий интерфейс

Не меняется (нужен next-hop-self)

Анонс маршрутов

Маршруты анонсируются всем

Полученное по iBGP не анонсируется другим iBGP-соседям (split horizon)

Administrative Distance (Cisco)

20

200

Правило split horizon в iBGP и его следствия

Маршрут, полученный по iBGP-сессии, не может быть переанонсирован другому iBGP-соседу. Это правило защищает от петель внутри AS, но порождает требование: все iBGP-маршрутизаторы должны иметь сессии «каждый-с-каждым» (full mesh). При наличии N маршрутизаторов это N×(N-1)/2 сессий — для 100 устройств это уже 4950 сессий. Решений два:

Route Reflector (RR) — выделенный маршрутизатор-рефлектор, которому разрешено переанонсировать iBGP-маршруты другим клиентам. Описан в RFC 4456.

Confederation — разделение AS на под-AS, между которыми работает квази-eBGP. Менее распространён.

2.2. Установление BGP-сессии

BGP работает поверх TCP на порту 179. Это принципиальное отличие от OSPF (raw IP protocol 89) и обеспечивает надёжную доставку — но и вносит зависимость от IP-связности между BGP-соседями. Сессия проходит через несколько состояний:

Состояние

Что происходит

Idle

Начальное состояние; ожидание команды или таймера

Connect

Попытка установить TCP-соединение; ждём успеха TCP handshake

Active

TCP-соединение не установилось, повторяем попытки. ВНИМАНИЕ: «Active» НЕ означает работающую сессию!

OpenSent

TCP установлен, отправлено OPEN-сообщение, ждём OPEN от соседа

OpenConfirm

OPEN получены и приняты с обеих сторон, ждём KEEPALIVE

Established

Сессия активна, маршруты обмениваются через UPDATE

ПРИМЕЧАНИЕ. Состояние «Active» — частый источник недоразумений. Если сессия зависла в Active, это значит, что TCP не устанавливается. Проверьте: ACL на пути, listening на порту 179, корректность IP-адреса соседа, маршрутизацию до соседа, eBGP-multihop при необходимости.

Параметры в OPEN-сообщении

При установлении сессии стороны обмениваются следующим:

Версия BGP (всегда 4).

Свой AS-номер.

Hold Time — таймер удержания. Если за это время не пришёл KEEPALIVE или UPDATE, сессия сбрасывается. Принимается минимум из двух предложенных. По умолчанию 180 секунд, KEEPALIVE отсылается каждые Hold/3 = 60 секунд.

BGP Identifier (RID) — уникальный 32-битный идентификатор.

Optional Parameters — capabilities (multi-protocol extensions, route refresh, 4-byte AS, graceful restart и т.д.).

2.3. Атрибуты пути (Path Attributes)

BGP — это путь принятия решений на основе атрибутов. Каждый префикс приходит в BGP с набором атрибутов, и алгоритм выбора лучшего пути рассматривает их в строго определённом порядке. Знание атрибутов и их влияния — основа работы с BGP.

Категории атрибутов

Категория

Свойство

Примеры

Well-known mandatory

Должны присутствовать в каждом UPDATE

ORIGIN, AS_PATH, NEXT_HOP

Well-known discretionary

Могут присутствовать, все BGP их понимают

LOCAL_PREF, ATOMIC_AGGREGATE

Optional transitive

Опциональны, передаются дальше даже если не поняты

COMMUNITY, AGGREGATOR

Optional non-transitive

Опциональны, не передаются за пределы AS если не поняты

MED, CLUSTER_LIST, ORIGINATOR_ID

Ключевые атрибуты подробно

ORIGIN — указывает источник анонса. Принимает три значения: IGP (i, маршрут анонсирован командой network внутри AS), EGP (e, устаревший), Incomplete (?, маршрут получен через redistribution). При прочих равных IGP предпочтительнее EGP, EGP — Incomplete.

AS_PATH — список AS, через которые префикс был получен. Используется для предотвращения петель и как один из критериев выбора лучшего пути (короче — лучше). Существует несколько подтипов: AS_SEQUENCE (упорядоченный список), AS_SET (неупорядоченное множество, образуется при агрегации). При выборе пути учитывается длина AS_SEQUENCE; AS_SET считается за единицу.

NEXT_HOP — IP-адрес следующего hop-а. В eBGP по умолчанию устанавливается в адрес интерфейса, через который пришёл UPDATE. В iBGP не меняется при передаче дальше — поэтому, если eBGP-сосед анонсирует префикс и ваш граничный роутер передаёт его в iBGP, без «next-hop-self» внутренние роутеры могут получить недостижимый next-hop.

LOCAL_PREF — локально значимый атрибут, существующий только внутри AS. Используется для управления выбором исходящего пути из AS. Чем выше — тем предпочтительнее. По умолчанию 100. Применяется при наличии нескольких eBGP-соседей: повышение LOCAL_PREF на одном из них заставит весь iBGP-облако предпочитать этот выход.

MED (Multi-Exit Discriminator) — обратное LOCAL_PREF: используется для подсказки соседней AS, какой из ваших пограничных маршрутизаторов предпочесть для входящего трафика. Чем ниже — тем предпочтительнее. По умолчанию не передаётся между AS, но передаётся до соседней AS. Учитывается обычно только если AS_PATH совпадает по первому AS.

COMMUNITY — 32-битный тег, прикрепляемый к маршруту. Используется как сигнальный механизм для применения политик. Стандартные well-known communities: NO_EXPORT (не передавать за пределы AS), NO_ADVERTISE (не передавать никому), NO_EXPORT_SUBCONFED. Кастомные значения формата AS:VALUE используются провайдерами для управления маршрутами клиентами (например, «не анонсировать в AS X»).

2.4. Алгоритм выбора лучшего пути BGP

Когда маршрутизатор имеет несколько BGP-маршрутов до одного префикса, он применяет следующий упорядоченный алгоритм. Каждый шаг применяется к набору кандидатов, и если он выделяет одного победителя, остальные шаги пропускаются. Этот порядок необходимо знать наизусть для понимания и управления BGP.

Самый высокий WEIGHT (Cisco-специфичный, локально для маршрутизатора, по умолчанию 0).

Самый высокий LOCAL_PREF.

Маршрут, originated на этом маршрутизаторе (network/aggregate).

Самый короткий AS_PATH.

Самый низкий ORIGIN (IGP < EGP < Incomplete).

Самый низкий MED (только при сравнении путей с одинаковым первым AS, по умолчанию).

eBGP предпочтительнее iBGP.

Самый низкий IGP-cost до NEXT_HOP.

Если ECMP включён и атрибуты совпадают — нагрузка балансируется.

Старший маршрут (oldest), если eBGP — для стабильности.

Самый низкий BGP Router ID соседа.

Самый короткий CLUSTER_LIST (для RR).

Самый низкий IP-адрес соседа.

ПРИМЕЧАНИЕ. На практике первые четыре пункта определяют выбор в 95% случаев. WEIGHT и LOCAL_PREF — основные инструменты управления исходящим трафиком, AS_PATH prepend и MED — управления входящим.

2.5. Управление маршрутами: route-map, prefix-list, AS-path filter

BGP без политики — это простой обмен полным интернетом, что для большинства сетей бессмысленно или опасно. Управление осуществляется через несколько типов фильтров и инструментов.

Prefix-list

Список разрешённых/запрещённых префиксов с возможностью указания диапазона длины маски. Применяется для входящих и исходящих анонсов. Например:

ip prefix-list CUSTOMERS seq 10 permit 192.0.2.0/24ip prefix-list CUSTOMERS seq 20 permit 198.51.100.0/24 le 32ip prefix-list CUSTOMERS seq 30 deny 0.0.0.0/0 le 32router bgp 65001 neighbor 10.0.0.1 prefix-list CUSTOMERS in

«le 32» означает «эта подсеть и все более специфичные»; «ge X le Y» — диапазон длин.

AS-Path Access List

Регулярные выражения по AS_PATH. Часто используется для фильтрации транзитных маршрутов или для приёма только маршрутов от конкретных AS:

ip as-path access-list 1 permit ^65002$ip as-path access-list 1 permit ^65002_router bgp 65001 neighbor 10.0.0.1 filter-list 1 in

Знак ^ — начало строки, $ — конец, _ — разделитель (пробел, начало, конец). Шаблон «^65002$» означает «маршруты, originated в AS 65002»; «^65002_» — «маршруты, проходящие через 65002 как первого соседа».

Route-map — самый мощный инструмент

Route-map — это упорядоченный список match/set операций, позволяющий и фильтровать, и модифицировать атрибуты маршрутов:

route-map IN_FROM_ISP1 permit 10 match ip address prefix-list IMPORTANT_PREFIXES set local-preference 200route-map IN_FROM_ISP1 permit 20 match as-path 1 set local-preference 150route-map IN_FROM_ISP1 permit 30router bgp 65001 neighbor 10.0.0.1 route-map IN_FROM_ISP1 in

Здесь маршруты, попавшие в IMPORTANT_PREFIXES, получают LOCAL_PREF 200; маршруты с определённым AS_PATH получают 150; остальные принимаются с дефолтным LOCAL_PREF 100. Важно: последняя строка «permit 30» без match — это catch-all, без неё всё бы блокировалось.

2.6. iBGP-масштабирование: Route Reflectors

Route Reflector (RR) — это решение проблемы full-mesh iBGP. Идея: один или несколько маршрутизаторов получают статус RR, и им разрешено переанонсировать iBGP-маршруты другим клиентам — но с соблюдением правил против петель.

Правила распространения для RR

Маршруты от eBGP-соседа RR анонсирует всем клиентам и всем не-клиентам (обычные iBGP-соседи).

Маршруты от iBGP-клиента RR анонсирует всем другим клиентам, всем не-клиентам и всем eBGP-соседям.

Маршруты от не-клиента (обычный iBGP-сосед) RR анонсирует только клиентам и eBGP, но НЕ другим не-клиентам.

Защита от петель: ORIGINATOR_ID и CLUSTER_LIST

При рефлекции RR добавляет два атрибута:

ORIGINATOR_ID — RID того маршрутизатора, который изначально анонсировал маршрут. Если RR получит обратно маршрут с собственным ORIGINATOR_ID — отбросит.

CLUSTER_LIST — список Cluster-ID-шников RR-кластеров, через которые прошёл маршрут. Если в нём встречается собственный Cluster-ID — маршрут отбрасывается.

В типичной топологии с двумя RR для отказоустойчивости оба назначаются с одинаковым Cluster-ID, и они оба становятся клиентами друг друга. Каждый клиент имеет сессии с обоими RR.

2.7. BGP в датацентре: Spine-Leaf и BGP unnumbered

За последнее десятилетие BGP вышел за рамки маршрутизации между AS и стал стандартом underlay для современных датацентров. Архитектура Clos (Spine-Leaf) с BGP вместо OSPF доминирует в крупных DC по нескольким причинам:

Чёткая иерархия и предсказуемые точки сходимости. SPF в OSPF на 200+ узлах нагружает CPU; BGP не пересчитывает граф, а распространяет изменения построчно.

Возможность точечного управления маршрутами через политику — для multi-tenant сред.

Плоскость управления EVPN строится поверх MP-BGP — единая инфраструктура и для underlay, и для overlay.

eBGP-fabric с уникальными AS на каждом коммутаторе

Типичная схема для Spine-Leaf:

Каждый Spine — отдельный AS (или один общий AS для всех Spine).

Каждый Leaf — отдельный AS (часто из приватного 4-байтного диапазона 4200000000+).

Между Spine и Leaf — eBGP-сессии.

Никакого full-mesh iBGP, никаких RR, никаких areas — просто иерархия eBGP.

BGP unnumbered (RFC 5549 / 8950)

В классическом BGP каждой сессии нужен IPv4-адрес соседа, что в фабрике с сотнями линков становится мучением для адресации. RFC 8950 определяет «unnumbered BGP»: сессия устанавливается через IPv6 link-local адреса, обнаруживаемые автоматически (обычно через IPv6 ND), а IPv4-маршруты передаются с next-hop в виде IPv6-адреса. Это позволяет полностью отказаться от ручной адресации underlay-линков.

2.8. BGP-сессия с провайдером: типичная конфигурация

Для иллюстрации соберём типичный пример настройки BGP-сессии с двумя ISP для базовой избыточности. Предполагается, что у предприятия AS 65001, два ISP — AS 64500 и AS 64501. Цель: предпочитать ISP1 для исходящего трафика, объявлять только свой агрегированный префикс 203.0.113.0/24 наружу.

router bgp 65001 bgp router-id 10.255.255.1 bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 198.51.100.1 remote-as 64500 neighbor 198.51.100.1 description ISP1 neighbor 198.51.100.1 password SecretKey1 neighbor 198.51.100.1 timers 10 30 neighbor 198.51.100.5 remote-as 64501 neighbor 198.51.100.5 description ISP2 neighbor 198.51.100.5 password SecretKey2 address-family ipv4 network 203.0.113.0 mask 255.255.255.0 neighbor 198.51.100.1 activate neighbor 198.51.100.1 prefix-list ANNOUNCE out neighbor 198.51.100.1 prefix-list FROM_ISP1 in neighbor 198.51.100.1 route-map ISP1_IN in neighbor 198.51.100.5 activate neighbor 198.51.100.5 prefix-list ANNOUNCE out neighbor 198.51.100.5 prefix-list FROM_ISP2 in neighbor 198.51.100.5 route-map ISP2_IN in exit-address-familyip prefix-list ANNOUNCE permit 203.0.113.0/24route-map ISP1_IN permit 10 set local-preference 200route-map ISP2_IN permit 10 set local-preference 100

Ключевые моменты этой конфигурации:

MD5-аутентификация (password) — обязательна для интернет-сессий.

«no bgp default ipv4-unicast» отключает автоактивацию IPv4 — каждый AF активируется явно. Лучшая практика для корректной работы с multi-protocol BGP.

Prefix-list «ANNOUNCE» гарантирует, что мы анонсируем только свой агрегат и ничего больше — защита от случайных утечек.

Prefix-list «FROM_ISPx» защищает от приёма мусора — например, своих собственных префиксов от ISP, default-маршрута от тех, кто не должен его слать.

LOCAL_PREF 200 на ISP1 делает его предпочтительным для исходящего трафика.

Управление входящим трафиком через AS-path prepend

Для управления входящим трафиком LOCAL_PREF не годится — он локален. Используется AS-path prepend: при анонсе наружу к менее предпочтительному ISP несколько раз добавляем свой AS, чтобы AS_PATH стал длиннее, и удалённые AS предпочитали короткий путь через другого ISP:

route-map ISP2_OUT permit 10 match ip address prefix-list ANNOUNCE set as-path prepend 65001 65001 65001

Эта техника не гарантирует — некоторые удалённые AS могут предпочитать ISP2 по своим политикам — но в большинстве случаев работает.

2.9. Безопасность BGP

BGP исторически создавался без серьёзных мер безопасности, и это до сих пор источник проблем в интернете — утечки маршрутов, перехваты префиксов (BGP hijacking). Базовые меры защиты, которые должны быть на каждой сессии:

MD5/TCP-AO аутентификация — защита от случайных подключений и базовая защита от подделки.

TTL-Security (GTSM) — для eBGP-соседей с одного hop-а ставим TTL=255 на исходящих и проверяем TTL≥254 на входящих. Это блокирует попытки удалённой подделки.

Maximum-prefix — ограничение количества принимаемых префиксов от соседа. Предотвращает заливку памяти при ошибке у соседа.

Prefix-list IN — никогда не принимаем bogon-ы (RFC 1918, 0.0.0.0, multicast и т.д.) и свои собственные префиксы.

RPKI (Resource Public Key Infrastructure, RFC 6480) — криптографическая проверка того, что AS, анонсирующий префикс, имеет на это право. Маршрут с invalid статусом отбрасывается.

Модуль 3. VXLAN — оверлейная инкапсуляция для современных датацентров

3.1. Зачем нужен VXLAN: ограничения VLAN

VLAN (IEEE 802.1Q) — фундамент сегментации L2-сетей с конца 90-х. Однако в эпоху облачных и мульти-тенантных датацентров классический VLAN сталкивается с тремя серьёзными проблемами.

Проблема 1: 4096 идентификаторов

Тег VLAN ID занимает 12 бит, что даёт 4096 значений (с учётом резерваций — около 4094 пригодных). Для датацентра-провайдера, обслуживающего тысячи клиентов, каждому из которых нужен изолированный сегмент — это критическое ограничение. VXLAN использует 24-битный VNI (VXLAN Network Identifier) → более 16 миллионов сегментов.

Проблема 2: L2-домен не растягивается через L3

Чтобы две стойки в разных частях ДЦ или две географически разнесённые площадки обменивались L2-кадрами (например, для миграции виртуальной машины с сохранением IP), классически нужен L2-туннель — Q-in-Q, MPLS-VPLS или растянутый STP. Это сложно в эксплуатации, ограниченно по масштабу и склонно к авариям. VXLAN инкапсулирует L2-кадр в UDP-пакет и передаёт через любую IP-сеть.

Проблема 3: STP и flooding

Большие L2-домены страдают от STP — он блокирует резервные линки, ограничивает использование ECMP и медленно сходится. ARP/Broadcast флудятся по всему сегменту. VXLAN сам по себе не решает проблему flooding (он его передаёт), но в связке с EVPN MAC-обучение становится плоскостью управления, а не плоскостью данных, и flood-учиться больше не нужно.

3.2. Формат пакета и инкапсуляция

VXLAN определён в RFC 7348. Формат инкапсулированного кадра:

+-----------------+----------------+----------------+----------------+| Outer Ethernet | Outer IP (UDP) | VXLAN Header | Original L2 || (новый MAC) | UDP dst 4789 | VNI 24 bit | Frame (full) |+-----------------+----------------+----------------+----------------+Outer Ethernet: 14 байт (или 18 с тегом VLAN underlay)Outer IP: 20 байт (IPv4) или 40 байт (IPv6)UDP: 8 байт (порт назначения 4789)VXLAN: 8 байт ----Накладные: 50 байт для IPv4 + Ethernet underlay

VXLAN-заголовок (8 байт)

Bit: 0 8 31 +--------+--------+--------+--------+ |R|R|R|R|I|R|R|R| Reserved | Flags + Reserved +--------+--------+--------+--------+ | VNI (24 бита) |Reserved| +--------+--------+--------+--------+I-флаг = 1 указывает, что VNI валиден.VNI (Network Identifier) = идентификатор виртуальной сети.

Зачем UDP, а не GRE или TCP

UDP выбран по двум причинам. Во-первых, он stateless и не накладывает накладных на промежуточные устройства. Во-вторых — и это ключевое — поле Source Port в UDP используется как инструмент для ECMP-балансировки. Source Port в outer UDP вычисляется как хеш от заголовков inner-кадра (src/dst MAC, src/dst IP, src/dst L4-порт). Это даёт промежуточным маршрутизаторам underlay возможность распределять разные потоки по разным линкам ECMP, не зная о VXLAN, — они балансируют по 5-tuple внешнего пакета, и хеш разный для разных внутренних сессий.

ПРИМЕЧАНИЕ. MTU underlay должен быть увеличен на 50 байт (или 70 для IPv6/QinQ) относительно MTU клиентских интерфейсов. Если стандартный Ethernet MTU = 1500, то underlay должен поддерживать 1550 или больше. На практике обычно используется jumbo frame 9000–9216 байт.

3.3. VTEP — точка инкапсуляции

VTEP (VXLAN Tunnel Endpoint) — это устройство (или функция в устройстве), выполняющее инкапсуляцию VXLAN на исходящем направлении и декапсуляцию — на входящем. VTEP-ом может быть:

Hardware VTEP — top-of-rack коммутатор (например, Cisco Nexus 9000, Arista 7050, H3C S6800), Spine-Leaf коммутаторы фабрики.

Software VTEP — гипервизор (vSphere ESXi с NSX, KVM с OVS), серверный software switch.

Gateway VTEP — устройство на границе VXLAN-домена, переводящее трафик между VXLAN и не-VXLAN сегментами (например, классический VLAN или внешний L3).

VTEP идентифицируется IP-адресом — обычно loopback-адресом коммутатора. Все остальные VTEP в фабрике должны иметь IP-связность до этого адреса (это и есть underlay).

Маппинг VLAN ↔ VNI

На клиентской стороне VTEP видит обычный 802.1Q VLAN-тегированный или access трафик. Внутри VTEP-а есть таблица маппинга VLAN ID ↔ VNI: какой кадр из какого VLAN-а нужно инкапсулировать в какой VNI. Это позволяет на каждом VTEP использовать собственное локальное VLAN-пространство, потому что значимый идентификатор сегмента — VNI, а VLAN — лишь локальный «вешалка» для интерфейсов.

3.4. Плоскость управления: проблема BUM-трафика

Базовый VXLAN (RFC 7348) не определяет, как VTEP-ы узнают друг о друге и как обрабатывают BUM-трафик (Broadcast, Unknown unicast, Multicast). Есть три исторических подхода.

Подход 1: Multicast underlay (классический)

Каждому VNI ставится в соответствие multicast-группа (например, 239.1.1.1 для VNI 10000). Все VTEP-ы, обслуживающие этот VNI, подписываются на эту группу. BUM-трафик инкапсулируется в VXLAN с outer destination = multicast-адрес группы. В underlay должен работать PIM (обычно PIM-SM или Bidir-PIM), что усложняет архитектуру и плохо масштабируется через несколько ДЦ.

Подход 2: Ingress Replication (Head-end Replication)

VTEP, отправляющий BUM, дублирует пакет — по одной копии для каждого удалённого VTEP-а, обслуживающего тот же VNI, — и отправляет каждую копию unicast-ом. Никакой PIM не нужен, underlay упрощается. Минус: при большом количестве VTEP-ов на VNI исходящая полоса VTEP-источника может стать узким местом. Список VTEP-ов на VNI должен быть известен (статически или через плоскость управления).

Подход 3: EVPN — современная плоскость управления

MP-BGP EVPN (RFC 7432, RFC 8365) — это address family BGP, специально разработанный для оверлей-сетей. Он распространяет:

Тип 2 (MAC/IP Advertisement) — анонсы локально известных MAC-адресов и связанных IP.

Тип 3 (Inclusive Multicast Ethernet Tag) — анонс участия VTEP-а в конкретном VNI; используется для построения списка VTEP для ingress replication.

Тип 4 (Ethernet Segment) — для multi-homing.

Тип 5 (IP Prefix Route) — для распространения IP-префиксов (а не только хост-маршрутов).

С EVPN VTEP-ы узнают MAC-адреса не из data plane (из flooding-а), а из control plane — заранее. Это полностью устраняет flood-and-learn: ARP может быть подавлен на VTEP-е (ARP suppression), unknown unicast становится редкостью. Это ключевая причина перехода на EVPN: фабрика становится тихой, и L2-домен можно растягивать на десятки VTEP-ов без эффекта broadcast storm.

3.5. EVPN: типы маршрутов и их применение

Тип

Название

Назначение

1

Ethernet Auto-Discovery

Multi-homing: AD per ES и AD per EVI

2

MAC/IP Advertisement

Анонс MAC-адреса и опционально привязанного IP (хост-маршрут)

3

Inclusive Multicast

Анонс участия VTEP в EVI; список для BUM replication

4

Ethernet Segment

DF election при multi-homing

5

IP Prefix

Анонс IP-префикса (subnet) — для L3 EVPN

Тип 2: MAC/IP Advertisement — главный рабочий тип

Когда хост подключается к VTEP-у и отправляет первый кадр (или GARP, или DHCP), VTEP узнаёт его MAC и опционально IP (по ARP-снупингу). VTEP анонсирует это как EVPN Type 2 во все BGP-EVPN сессии. Маршрут содержит:

Route Distinguisher (RD) — обеспечивает уникальность в BGP-таблице.

Ethernet Segment Identifier (ESI) — идентификатор сегмента (для multi-homing).

Ethernet Tag ID — служебный, обычно 0.

MAC-адрес и его длина.

IP-адрес (опционально).

Label1 — VNI для L2-операций.

Label2 — VNI для L3-операций (если рекламируется и IP).

Route Target (RT) extended community — определяет, в какой VRF/EVI импортировать маршрут.

Symmetric vs Asymmetric IRB

Когда EVPN выполняет L3-маршрутизацию между VNI на VTEP-е, существует два режима:

Asymmetric IRB — на VTEP-источнике делается route-and-bridge: пакет маршрутизируется в нужный VNI и отправляется уже в новом VNI. На VTEP-приёмнике — только bridge. Минус: на VTEP-источнике должны быть все целевые VNI.

Symmetric IRB — используется специальный transit VNI (L3VNI) для маршрутизации между сегментами. На источнике bridge → route → encap в L3VNI. На приёмнике decap → route → bridge в целевом VNI. Плюс: масштабируется лучше, на каждом VTEP не нужно держать все VNI. Это де-факто стандарт в современных EVPN-фабриках.

3.6. Архитектура underlay для VXLAN-EVPN

Underlay — это IP-сеть, по которой бегают инкапсулированные VXLAN-пакеты. Требования к underlay:

Полная IP-связность между всеми VTEP loopback-ами (обычно /32).

Поддержка ECMP — желательно много путей, чтобы хеш по UDP-порту реально распределял.

MTU 9000+ для поддержки jumbo-фреймов.

Быстрая сходимость — BFD на underlay-протоколе.

Варианты underlay-протокола

Протокол

Плюсы

Минусы

OSPF

Простота, известность, быстрая сходимость

SPF на крупных фабриках нагружает CPU; иерархия areas сложнее, чем нужно для простой Clos

IS-IS

TLV-расширения, поддержка SR, не зависит от IP

Менее распространён в DC-команды

eBGP

Линейная масштабируемость, плоскость управления = плоскость данных (тот же BGP для underlay и overlay)

Больше конфигурации, нужны разные AS на коммутаторах

Спайн-Лиф (Clos) топология

Стандартная архитектура современного DC выглядит так:

Несколько Spine-коммутаторов (2, 4 или 8 — для отказоустойчивости и масштабирования полосы).

Множество Leaf-коммутаторов (top-of-rack).

Каждый Leaf соединён с КАЖДЫМ Spine.

Spine между собой НЕ соединены.

Серверы подключаются к Leaf (одному или паре через MLAG/EVPN multi-homing).

Эта топология нерекурсивная — между любыми двумя Leaf ровно 2 hop-а через Spine. Полоса между любыми двумя Leaf ограничена только количеством Spine-ов и uplink-ов. ECMP-балансировка использует все доступные Spine.

3.7. Multi-homing хостов: ESI-LAG

Один из ключевых преимуществ EVPN — поддержка all-active multi-homing хостов к нескольким Leaf-коммутаторам без проприетарного MLAG. Хост подключается к двум (или более) Leaf-ам через LAG (LACP). Со стороны Leaf обе пары порта собираются в Ethernet Segment с общим ESI (10-байтный идентификатор).

Принципы работы:

Оба Leaf анонсируют MAC-адреса хоста через EVPN Type 2 с одним и тем же ESI.

Удалённые VTEP-ы видят оба анонса и могут балансировать трафик на уровне ECMP.

Для BUM-трафика выбирается Designated Forwarder (DF) — один Leaf, который ретранслирует BUM в сторону хоста, чтобы тот не получил дубль.

DF-election происходит через EVPN Type 4 на основе ESI и BGP RID.

Преимущество перед MLAG: не нужны пары вендорских коммутаторов с проприетарным sync-протоколом (vPC, MC-LAG, MLAG). EVPN multi-homing работает между коммутаторами разных вендоров — это часть стандарта.

3.8. Конфигурация EVPN-VXLAN: пример на FRR/Cumulus

Для иллюстрации соберём минимальную конфигурацию Leaf-коммутатора в EVPN-VXLAN фабрике с использованием FRR (Free Range Routing) — наиболее распространённой реализации в open-source мире и в Cumulus Linux/NVIDIA Onyx.

! /etc/frr/frr.conf! Underlay BGP — eBGP unnumbered к двум Spinerouter bgp 4200000001 bgp router-id 10.255.255.1 neighbor SPINES peer-group neighbor SPINES remote-as external neighbor swp51 interface peer-group SPINES neighbor swp52 interface peer-group SPINES address-family ipv4 unicast network 10.255.255.1/32 neighbor SPINES activate exit-address-family ! Overlay EVPN — то же peer-group, но другой AF address-family l2vpn evpn neighbor SPINES activate advertise-all-vni exit-address-family! VXLAN-интерфейсы и маппинг VLAN ↔ VNI! (часть конфигурации в /etc/network/interfaces)! VRF для L3 EVPNvrf TENANT_A vni 10000 exit-vrf

В /etc/network/interfaces определяются мост и VNI-интерфейсы:

auto vni10001iface vni10001 bridge-access 100 vxlan-id 10001 vxlan-local-tunnelip 10.255.255.1auto bridgeiface bridge bridge-ports vni10001 swp1 swp2 bridge-vlan-aware yes bridge-vids 100

3.9. Эксплуатационные нюансы

MTU — самая частая проблема

Если underlay MTU не увеличен, а клиентские интерфейсы шлют 1500 байт, то после инкапсуляции пакет станет 1550 байт, и underlay-коммутатор с MTU 1500 его отбросит (или, если установлен DF-бит, отправит ICMP «Fragmentation Needed» — а если не установлен, фрагментирует, что в VXLAN тоже плохо). Симптомы: ping проходит (короткие пакеты), а реальные сессии ломаются (TCP-handshake часто маленький, а потом обмен данными — большие пакеты). Решение: на underlay везде установить MTU не менее 1550, а лучше 9000+.

ARP suppression

Когда VTEP получил EVPN Type 2 с MAC и IP, он знает соответствие. Когда локальный хост шлёт ARP-запрос для удалённого IP, VTEP может ответить сам, не флудя ARP в overlay. Это критично для масштабируемости — без ARP suppression в большом VNI с тысячами хостов broadcast-трафик может задавить фабрику. ARP suppression обычно включается per-VNI или глобально.

Storm Control и BUM-rate-limiting

Даже с EVPN остаются legitimate источники BUM: DHCP-discover, IPv6 ND, нестандартные приложения с broadcast. Обязательно настраивайте storm-control на L2-портах — в момент сбоя приложения или вирусной активности это спасёт фабрику.

BFD на underlay

Стандартный BGP timer 30-90 секунд — это вечность для современного DC. Включите BFD для underlay BGP-сессий с интервалами 50–300 мс. Сходимость в случае отказа Spine-Leaf линка должна быть в субсекундной зоне.

EVPN ARP/ND moves и host mobility

Когда виртуальная машина мигрирует с одного хоста на другой (vMotion, kvm-live-migration), её MAC переезжает на другой VTEP. EVPN отслеживает это через sequence number в Type 2 — VTEP, к которому VM пришёл, увеличивает seq, и его анонс перебивает старый. В нормальной работе это занимает секунды. Если ваш гипервизор шлёт GARP при миграции — переключение почти мгновенное.

Заключение. Где какой протокол использовать

Изучив три технологии в деталях, можно сформулировать четкие рекомендации по их применению в реальных проектах.

Когда использовать OSPF

Корпоративная сеть с десятками-сотнями маршрутизаторов под единым управлением.

Кампусная сеть с иерархией core-distribution-access.

WAN-сеть филиалов с MPLS L3 VPN или IPSec, где OSPF работает как PE-CE протокол.

Underlay для небольшой VXLAN-фабрики (до 50–100 устройств), где простота важнее масштабируемости.

Когда использовать BGP

Подключение к двум и более ISP — в принципе обязательно.

Маршрутизация между датацентрами компании, особенно при разных AS.

Underlay крупных DC-фабрик (Spine-Leaf от 50+ узлов) — eBGP-fabric с уникальными AS.

Плоскость управления EVPN — MP-BGP всегда.

Любая сеть, где требуется тонкое управление политикой маршрутизации, route-leaking между VRF, регулирование симметрии трафика.

Когда использовать VXLAN/EVPN

Multi-tenant датацентр — изоляция сегментов, потребность в более чем 4096 VLAN.

Растяжение L2-домена через L3-фабрику или между ДЦ.

Поддержка VM-mobility без изменения IP-адреса.

Замена устаревшей архитектуры с STP и проприетарным MLAG на современную фабрику с EVPN multi-homing.

Любая частная облачная инфраструктура (OpenStack, VMware NSX, Kubernetes с Calico-VXLAN).

Финальная архитектура современного датацентра

Если бы пришлось проектировать DC «с нуля» на сегодняшний день, типовой стек выглядел бы так:

Физическая топология: Clos Spine-Leaf, 2–8 Spine-ов в зависимости от масштаба, 100G линки между Spine и Leaf.

Underlay: eBGP unnumbered, каждый Leaf — собственный AS из 4-байтного приватного диапазона, Spine-ы — общий или индивидуальный AS, BFD на всех сессиях.

Overlay: VXLAN с VNI per tenant per L2-сегмент.

Плоскость управления overlay: MP-BGP EVPN, та же сессия, что underlay (multi-AF), Type 2 + Type 5 + Type 3.

Multi-homing хостов: EVPN ESI-LAG (без MLAG).

L3-маршрутизация overlay: Symmetric IRB с L3VNI per VRF (per tenant).

Внешний выход: пара Border Leaf с external eBGP к ISP/WAN-устройствам.

OSPF в этой архитектуре не используется в underlay — для крупных DC он уступает eBGP. OSPF остаётся актуален в кампусной сети, в WAN-филиалах и в небольших серверных сегментах. BGP — везде, где есть граница между административными зонами или где нужна политика. VXLAN/EVPN — везде, где нужна виртуализация L2 поверх L3.

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

• Конец лекции —