Overlay Networks

Разделяют 2 вида сетей: overlay и underlay.

Underlay - физическая IP сеть. Это база (транспорт) поверх которого уже строится overlay netw.

Примеры underlay: MPLS, IP-сеть построенная на IGP/EGP.

Также в underlay входят bare metal servers (или могу ошибаться и это не так). Подразумевается, что underlay - это прям железо-железо в голом виде.

Overlay - это наложенная сеть на underlay. Виртуальные свитчи, серверы и другие VM соединены virt logical links (VTEPs - virtual tunnel endpoints).

host machine - сервер, на котором запущен hypervisor.
guest machine - каждая VM.

Hypervisor предоставляет OS с virt платформой для guest и далее управляет работой guest OS. Несколько разных guest OS будут делать hardware ресурсы сервера.

VXLAN - overlay technology, которая строит virt туннели на основе IP/MPLS netw (VTEPs)

VM на одном хосте будут коммуницировать между собой через virt switch - L2. VM на разных хостах будут коммуницировать между собой через VTEP - L3. То есть прибегать к инкапсуляции L2 в L3 и передаче трафика через underlay сеть.

VTEP - располагаются на hypervisor или есть брать сервера, включенные с обычные access switches, то на свитчах тоже можно создавать VTEP. VTEP - туннель между хостами VTEP имеет 2 iface:

switching interface - в сторону VM
IP interface - в сторону IP сети (L3 netw)

Для инкапсуляции используется обычно VXLAN. О нем ниже.

Положительные особенности overlay network (наложенных сетей):

Отделение сети от физического оборудования позволяет сетям дата-центров быть развернутыми за считанные секунды.
Поддержка L2 и L3 между VM и серверами.
В отличие от стандартной сети поддерживает до 16,4 млн "заказчиков" (вланов).

Чем приходится платить за использование overlay network:

- virtual tunnel endpoints (VTEPs) ипользует MAC и route. В отличие от традиционной модели, где каждая VM и каждый сервер использует MAC и route. В overlay трафик от VM и сервером инкапсулируется между VTEP. mac и route каждого сервера теперь не виден для оборудования overlay сети. mac и route теперь перенесены с физического уровня на уровень hypervisor.

Bare metal server

Редко в каких сетях получится найти полностью виртуализированую сеть. Какая-то часть серверов все-равно останется железной (в основном из-за производительности).

Как не бросить те самые железные сервачки и сохранить с ними сетевую связность?

Один из методов: соединить VTEP с физическим access switch.

Каждый гипервизор имеет VTEP. VTEP передает инкапсулированный трафик data plane между VM. Также VTEP делает mac-learning, предоставляет новые virt netw и другие изменения конфигурации.

На железных серверах нет VTEP. Чтобы железный сервер включить в overlay netw архитектуру, нужно чтобы кто-то инкапсулировал трафик от сервера и делал mac-learning. Пусть это делает обычный access-switch от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

Fabric Design

Traditional – MC-LAG (multichassis link aggregation group)

Virtual Chassis

top-of-rack topology

end-of-row topology

Virtual Chassis Fabric

top-of-rack topology

end-of-row topology

.

Большое приемущество в том, что между каждыми двумя host в фабрике есть только 2 hops. В отличие от VC, где число hops может достигать до 9.

Limitations:

-Virtual Chassis = 10 members

-Virtual Chassis Fabric = 20 members [2-4 spine + 16-18 leaf]

Master + backup используют один и тот же MAC + IP для GW.

Можно легко вставлять/вытаскивать членов VC. На них автоматически будет сделан upgrade софта если нужно, подъедет конфиг, новый член будет назначен linecard.

В VC для вычисления кратчайшего пути используется Dejkstra и путь выбирается один.

В VC fabric VCCP отвчечает за эту процедуру и при возникновении нескольких равнозначных путей трафик балансируется.

Virtual Chassis Fabric works really well for a top-of-rack based solution, but for end-of-row it becomes a little more problematic.

Junos Fusion

top-of-row topology

IP CLOS Fabrics

finely grained failure domains

IP Fabrics

Самое важное условие для IP Fabric: VTEP должны соединяться по L3.

Clos придумал распределенную топологию для L3, при которой возможно достаточно хорошее масштабирование сети. В такой сети есть разделение на уровни: ingress, middle, egress.

На основе CLOS произошла топология spine anf leaf, которую иногда называют сложенной CLOS сетью. То ест тут ingress и egress уровни сложены друг на друга (если можно так выразиться).

Spine - это L3 свитчи.

Leaf - это top-of-the-rack свитчи, который связывают сервер и VTEP.

Масштабируемость определяется двумя параметрами: "толщиной" spine, коэффициентов переподключенийleaf светчей.

Spine L3 свитчи можно собирать в кластер, а можно и нет. Причем говорится про кластре, в котором будут и SPINE и LEAF, все вместе.

Если я правильно поняла, то обычно, когда требуется особо большая масштабируемость сети, то VChassis не собирают.

При фабрике без VChassis емкость рассчитывается как умножение кол-во портов под серверы на кол-во LEAF, используемых на SPINE.

Пример:

При использовании такого оборудования:
SPINE = QFX5100-24Q [32 x 40GbE]
LEAF = QFX5100-96S [96 x 10G + 8 x 40GbE]
получаем фабрику размерностью = (32*96) x 10GbE = 3072 x 10GbE и oversubscription ratio 3:1

Control Plane

Для фабрик с VChassis беспокоиться о Control Plane не приходится. Она прост работает. Но если требуется более масштабируемся сеть, то придется отойти от VChassis и подумать о ControlPlane.

В фабрике каждому LEAF потребуется отправлять и получать маршрутную инфу вместе с остальными LEAF.

В той или иной степени для ControlPlane фабрики могут подойти следующие протоколы: BGP, OSPF, ISIS. Сравним их по разным параметрам:

Scale + Advertise Prefixes: Adveritse prefixes - у всех протоколов - норм, но OSFP и ISIS флудят префиксами. Чем больше префиксов в сети, тем больше флуда. Для уменьшения флуда можно и нужно в данном случае разбивать сегменты на area. Но при этом утратятся возможности CSPF. При этом BGP специально был придуман для работы с большим кол-вом префиксов. В плане масштабируемости он значительно выигрывает!

Traffic engineering + traffic tagging: иногда нужно управлять трафиком в фабриках, например, чтобы пустить его в обход какого-то SPINE. Тут понятно, что OSPF и ISIS сильно проигрывают. В отличие от них у BGP есть дофига атрибутов, которыми можно управлять трафиком.

Multivendor stability: Вроде и OSPF и ISIS неплохо себя должны вести, но кто знает, кто проверял. Гораздо чаще разные компании, использующие разное оборудование настраивают взаимодействие между собой именно посредством BGP. Так что именно BGP можно считать самым неприхотливым в работе в разными вендорами.

Ну в итоге для IP Fabric самый адекватный протокол - BGP.

BGP Design

Using EBGP in an IP fabric: каждому свитчу свою AS. Каждый LEAF пирится с каждым SPINE. Тут все просто и понятно и красиво. И также с помощью LPF и AS-PATH можем спокойно рулить трафиком. Защита от петель, напомню в том, что при отправке префикса проверяется AS-path. Префикс не отправляется пиру, если в AS-path есть AS пира.

top-of-the-rack

end-of-the-rack

.

Using IBGP in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector (или conederation - реже). RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут. Для восстановления справедливости потребуется заморочиться с AddPath на RR (draft-ietf-idr-add-paths). Плюсом IBGP считается еще защита от петель: имеется ввиду, что IBGP пиры при любом раскладе не будут флудить префиксами.

top-of-the-rack

end-of-the-rack

.

ECMP - equal-cost multi-path - технология, когда один поток (один source + один dest) передается между двумя равнозначными линками. Подразумевается включение обычной балансировки, то есть:

protocols {
   bgp {
       group CLOS {
           ...
           multipath multiple-as;

policy-options {
   policy-statement PFE-LB {
       then {
           load-balance per-packet;

routing-options {
   forwarding-table {
       export PFE-LB;

Хорошей практикой для IP Fabric также считается использование следующих фич:

protocols {
   bgp {
       log-updown;
       graceful-restart;
       group CLOS {
           mtu-discovery;
           bfd-liveness-detection { 
               minimum-interval 350;
               multiplier 3;
               session-mode single-hop;

Подробно на каждой из них в этой главе останавливаться не буду.

Requirements

Для того, чтобы построить IP Fabric с BGP, придерживайтесь следующих требований:

Base IP prefix. Один пул адресов для служебных целей (p2p, loopback, ...). Лучше сразу прикинуть размеры фабрики и выделить достаточный пул адресов.
P2P network. Экономно и удобно использовать /31.
P2P addresses. Удобно, когда при построении фабрики придерживаются одного принципа назначение ip. Первый - не spine, второй - на leaf.
Loopback. Выделить из большого пула. Лучше использовать loopback, это облегчает диагностику.
Server facing network. Сеть для сервачков. Leaf выступает как шлюз. Все зависит от масштабов фабрики, но понятно, что будет удобно использовать, например: /24 на один leaf, в ней работают только сервера, включенные к этому leaf. В фабрике 8 leaf, соответственно можно выделить 8*/24 = /21 сеть на фабрику. Подразумевается, что server facing netw и base ip netw - разные.
AS num. Для каждого свитча (SPINE или LEAF) отдельная AS num - для работы EBGP. Выбор использовать 32-bit/16-bit. 16-bit: диапазон приватных: 64512 - 65535 то есть 1023 шт, то есть максимум 1023 свитчей в фабрике. Если этого мало, то можно переходить либо в public диапазон, либо на 32-bit AS num.
BGP export. LEAF передает свой loopback и server facing netw.
BGP import. Разрешаем только Base IP prefix и Server facing network.
ECMP. Включаем load balancing на SPINE и LEAF.

Edge connect

Речь про связность с внешним миром и фабриками в других локациях, если такие есть.

В идеальном мире каждый дата-центр с IP Fabric должен:

на всех фабриках иметь одинаковую структуру и даже распределение AS.
иметь 2 edge роутера с уникальными AS num.
быть подключенным к двум разным ISP.
быть подключенным в внутренней MPLS сети.

Одинаковые AS num внутри фабрик разных дата-центров могут немного вводить в смятение. Можно с edge роутеров просто анонсировать агрегат своей фабрики.

Для ISP подключения: edge роутер к IP Fabric передает default, к ISP передает агрегаты фабрик. Все остальное - reject. От ISP на Edge лучше получать full view.

VXLAN

VXLAN инкапсулирует L2 frame в L3 UDP packets.

Состоит из:

VNI - VXLAN Network ID 24-bit [то есть более 16 млн ID] (= vlan-id если проводить аналогию с VLAN)
VTEP - VXLAN tunnel Endpoint

Передаем frame от VM1 к VM2 с одним VNI, расположенные на разных hypervisors

в forw table уже есть изученные mac-add удаленной VM и есть инфа о исх интерфейсе (VTEP)
VTEP местный добавляет VXLAN header, который содержит VNI. VTEP инкапсулирует frame в L3 UDP пакет.
VTEP маршрутизирует пакет через underlay L3-сеть к удаленному VTEP.
удаленный VTEP делает деинкапсуляцию и отдает frame к VM2.

VM не знают ничего про VXLAN и протоколы на L3. Для VM все выглядит, как-будто они сидят в одном L2 домене.

VXLAN добавляет 50-54 дополнительных bytes! Поэтому лучше включать везде jumbo frame.

Если у нас VM и bare metal server (BMS): Все происходит также, только на свитче, куда включен BMS VTEP будет соотноситься с интерфейсом в сторону сервера.

Как VTEPs будут находить друг друга?

Есть 2 способа обнаружения:

data plane learning [like ethernet switch = L2 learning]
control plane learning

Как будет обрабатываться BUM traffic [broadcast, unknown unicast, multicast]:

Multicast - common solution, когда каждому VNI приравнивается какая-то multicast group. На underlay сети должен быть развернут mcast. :) [для лабы достаточно просто добавить pim на iface и назначить anycast RP].

VTEP знает какой VNI (mcast group) у него => шлет igmp-join, чтобы подписаться в домен этого VNI. Когда какой-то VTEP шлет пакет с dest mcast, остальные VTEP его получают.

Когда VTEP должен отправить BUM traffic, он шлет его с dest ip = mcast address.

Data plane Learning [L2 learning | Flooding learning]

Когда VTEP получает пакет, он записывает в fw table:

IP-source VTEP
MAC VM
VNI

Когда приходит пакет с назначением к этой VM в этом же VNI, то VTEP уже будет знать что делать.

Если dest mac - не известен, то VTEP начинает флудить, вдруг кто другой знает такой адрес. Но чтобы уменьшить флуд, каждому VNI будет соответствовать своя multicast группа. И флуд будет распространен только в рамках этой группы.

Пример: 2 VM на разных хостах.

VNI 100 = mcast group: 239.1.1.100.

VM1 шлет arp-request к VM2 (who has 192.168.0.11?)
VTEP1 инкапсулирует в arp-request в mcast packet и шлет пакет к mcast group 239.1.1.100.
Все VTEP в группе 239.1.1.100 получают пакет, деинкаспулируют его проверяет VNI. Если совпадает, то шлет arp в VXLAN сегмент, если не совпадает, то дропает пакет. При этом локальный VTEP также добавляет инфу: IP VTEP1 <> MAC VM1 в свою локальную VXLAN table.
VM2 получила arp и ответила на него, раскрыв свой MAC.
VTEP2 инкапсулировала ответ и передала его к VTEP1.
VTEP1 получила arp-response, деинкапсулировала и отдала его VM1. И еще записала в VXLAN table IP VTEP2 <> MAC VM2.
Далее VM1 и VM2 общаются via unicast.

Можно для нескольких VNI назначать одну группу. VTEP все-равно при передаче пакета проверяет VNI, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном L2 домене - это главный минус такой системы.

Кстати, VTEP не поддерживают аутентификацию, поэтому злоумышленник запросто может вторгнуться в ваш домен. Поэтому рекомендовано все-же использовать control plane learning.

Control plane learning [BGP-EVPN]

Подразумевается, что switches learning делается до того, как начинается процесс передачи трафика. Работает аналогично протоколам маршрутизации.

Свитчи пирятся по BGP и делятся своими префиксами. Для обмена используется evpn family.

Некоторые свитчи будут иметь VTEPs и понятно, что по BGP проанонсятся их адреса.

В control plane learning и VTEP появляется "аутентификация". Когда адреса VTP анонсятся по BGP, они также заносятся в white list. Когда кто-то левый захочет приконнектиться - он не сможет этого сделать до тех пор, пока он не появится в white-list.

VM MAC добавляются в процесс BGP. Соответственно, когда одна VM передает другой фрейм, роутинг к нужному хосту происходит на основании BGP. {это все подробно описано в EVPN}

При использовании control plane learning - появляется и arp suppression. VM посылает ARP-req, который доходит до свитча. А свитч уже по BGP знает соответствие IP<>mac, и отдает mac удаленной VM.

Для BUM трафика советуют также использовать Multicast, как хорошо масштабируемый.

VXLAN Routing

Заставляем общаться разные VNI при помощи L3 gateway.

L3 gateway можно делать как на LEAF, так и на SPINE.

Могут использоваться: L2VNI, L3VNI.

L2VNI: для бриджей. То есть когда трафик остается внутри одного LAN-сегмента.

L3VNI: для роутинга. То есть когда трафик должен выйти за переделы LAN. L3VNI опциональны, но если хотите роутить на локальном свитче - придется воспользоваться.

VTEPs должны знать только про локальные L2VNI, которые они локально обслуживают. С другой стороны ВСЕ VTEPs должны знать обо всех L3VNI, что называется anycast gateway.

В этом случает каждый свитч - это GW в VNI [10.1.1.1]. На соседнем физическом свитче с тем же VNI настраивается такой же адрес шлюза [10.1.1.1]. И все свитчи в этом VNI будут иметь одинаковый virt mac-add для шлюза. Это приемущество по сравнению с VRRP/HSRP в том, что: не нужны какие-то таймеры или hello-massages для синхронизации между двумя свитчами.

То есть для одного VNI, все VM, которые ему принадлежат - имеют один и тот же шлюз! Все зависимости от того к какому свитчу физически включен сервер.

Это способствует быть VM - мобильной и перемещаться на другие сервачки!

L3VNI связаны с VRF. То есть один VNI = один Customer = один RD+RT.

Пример: На одном свитче будет настроен VRF с двумя irb интерфейсами: irb.100 [10.1.100.1], irb.101 [10.1.101.1]. Каждый будет обслуживать свой L2 домен: VTEP with VLAN100, a VNI1000 и VTEP with VLAN101, a VNI1001 соответственно.

QFX получает VXLAN пакет с outer dest ip. Деинкасулирует его.
QFX делает lookup dest mac-адреса, который = IRB VIP MAC.
Делает L3 lookup внутри VRF для IP-dest.
Далее делается ARP lookup для IP dest. Если есть mapping, то шлется в iface. Если нет, то выясняется куда слать by looking at the MAC table of the other VNI.
QFX генерирует новый L2 header с dest-mac для dest server. Потом шлет инкапсулированный VXLAN к remote VTEP.

EVPN-VXLAN

EVPN решает две проблемы:

MAC learning control plane for overlay networks
the need for workload mobility. Приложениям требуется L2 для взаимодействия друг с другом. Когда речь про app в разных DC, обычным вланом не обойтись.

EVPN относится а BGP family. Он использует MP BGP для MAC learning. Благодаря этому роутеры/свитчи обрабатывают MAC как маршруты. Что позволяет использовать несколько path одновременно (без физического гашения избыточных портов).

EVPN позволяет маршрутизировать не только MAC, но и ARP (IP + MAC). В дальнейшем ARP можно будет привязать и к VLAN-tag.

По сравнению с VPLS - тут явно больше преимуществ для использования.

Немного новой терминологии для EVPN в IP Fabric:

Ethernet Tags = VLAN-ID
MAC-VRF = Mac-table [в EVPN можно использовать import/export policies]
export-policy = обычная политика, которая на все изученные местные (local) mac-addr навешивает target и отправляет route к remote sites.
import-policy = обычная политика, которая по наличию правильного target кладет route в MAC-VFR.
RD - uniq ID, который назначается на MAC-VRF. Уникальный в пределах IP Fabric.
RT community - навешивается на routes посредством политик. На роутерах обозначает принадлежность к той или иной routing-table.
EVPN services = включает в себя разные vlan-mapping options.

VLAN Services

VLAN-based service - один влан на весь EVPN. То есть все девайсы на всех sites работают в одном влане. Можно делать vlan-map vlan-id 1 на vlan-id 2. Когда, например на разных фабриках используются разные vlan-id. It's ok. Плюс такого метода - ограничение broadcast. Но он не сильно масштабируем.
VLAN bundle service - в одном EVPN много разных вланов. Полезно, когда услуга одна для нескольких арендаторов. У арендаторов используются разные вланы и никак по-другому. Плюсы: удобно для конфига. Но брадакст в таком домене будет влиять на ВСЕ вланы в нем.
VLAN aware service - тут, кажется, используются bridge-domain внутри одного EVPN instance. Каждый со своим vlan-id внутри. То есть это дает возможность использовать в ENI (EVPN instance) несколько vlan-id, но которые не будут в одном broadcast домене. При флудах будут страдать конкретные вланы.

Data Plane

В качестве dataplane для EVPN из близкого к теме могут быть: MPLS, VXLAN. Есть еще и другие: PBB, STT, NVGRE..

VXLAN encapsulation метод основан на VNIs, тогда ваши vlan-id 1, vlan-id 2 > vni-1, vni-2 > vxlan-1, vxlan-2 (с изученными Mac-addr) > в EVPN instance-1 с uniq RD.

BGP Route Types for EVPN

-Ethernet Auto-Discovery (AD) Route: когда новый свитч вступает в EVPN, он пользуется этими роутами, чтобы объявить о себе.

  RD [8], _ESI [10], _ET [4], MPLS LBL [3]

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

Например, у нас один сервер включен двумя ногами в разные свитчи. Когда LEAF4 получит auto-discovery route от LEAF1 и LEAF2, то route будет вставлен в таблицу, но также, LEAF4 будет знать, что до данного сервера у него два VXLAN, которые можно использовать.

Это как раз различие в active/active links [flag set to 0] и single link [flag is set to 1].

Auto-discovery process отрабатывает намного быстрее, так как при стандартном включении в свитч при падении линка (за которым были тысячи mac-addr) таблица будет чистить эти тысячи маков гораздо дольше, чем один route, который соответствует (ассоциирован с) линку.

-MAC/IP Advertisement Route: MAC advertisement (также может передавать IP+MAC).

   RD [8], ESI [10], _ET [4],
   _MAC Addr Lenght [1], _MAC Addr [6],
   _IP Addr Lenght [1], _IP Addr [0|4|16]
   MPLS LBL1 [3]
   MPLS LBL2 [0|3]

LEAF4 изучил Mac server2. Начал передавать его другим sites EVPN с соответствующим community, которое навешивается согласно export policy.

LEAF1 исходя из import policy решает принять ли маршрут. Если import policy отсутствует - это равнозначно discard.

-Inclusive Multicast Ethernet Tag Route: BUM flooding.

   ET [4], IP Addr Lenght [1], Originating Router's IP Addr [4|16]

В Juniper EVPN/VXLAN свитчи поддерживают ingress replication BUM. То есть свитч получил BUM, создал unicast копии этого трафик и отправил remote sites этого EVPN.

Route информирует remote PE - как обработать BUM traffic и PMSI аттрибуты. Он определяет следует использовать PIM или PMSI и на какой dst adddr отправлять BUM traffic.

LEAF2 передает инфу, что он ждет и использует ingress replication и что LEAF1 должен использовать 4.4.4.4 как dst addr VXLAN пакетов, которые передают BUM.

-Ethernet Segment Route: ES and DF election.

   _ESI [10], _IP Addr Lenght [1], _IP Addr [4|16]

-IP Prefix Route: IP route advertisement

Controllers

Речь про SDN контроллеры

DC

Содержание