DC

Overlay Networks

Положительные особенности 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.

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) передается между двумя равнозначными линками. Ну то есть это балансировка и есть. Ну и со стороны BGP это включение multipath.

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