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 можем спокойно рулить трафиком.
• Using IBGP in an IP fabric: все свитчи в одной AS. Для получения полной маршрутной информации - full mesh. Ну или более разумно использовать route reflector. RR втискиваем в уровень SPINE. Делаем пару RR, для резервирования. Все нормально НО! при таком раскладе не выйдет делать балансировку (использовать multipath), т.к. RR выбирает и отдает своим пирам только лучший маршрут.