DC

Материал из Juniper Exam Wiki
Перейти к навигации Перейти к поиску

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 (наложенных сетей):

  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 от имени сервера. Сервер при этом просто думает, что посылает от себя трафик дальше в сеть.

Fabric Design

  • Traditional – MC-LAG (multichassis link aggregation group)
MC-LAG.png
  • 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

.

IBGP-eBGP CLOS.png

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

  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 будет соотноситься с интерфейсом в сторону сервера.

  • Как 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.

  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, а флуд при этом все-равно уменьшится.

Подходит только для девайсов, находящихся в одном 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 соответственно.

  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.

EVPN

Controllers

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

Источник — https://juniper-exam.ru/index.php?title=DC&oldid=1358