DC

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 ресурсы сервера.

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

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

VTEP имеет 2 iface:

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

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

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

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

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

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

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

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

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

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

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

L2 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.

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

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

VXLAN Routing

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

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

На одном свитче будет настроен 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 соответственно.

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

Bare metal server

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

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

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

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

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

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 пира.
• 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 пиры при любом раскладе не будут флудить префиксами.

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.