Привет, Хабр! Наконец заканчиваю цикл статей, посвященных запуску курса "Дизайнер сетей ЦОД" от OTUS, по технологии VxLAN EVPN. И сегодня обсудим реализацию подключений различных ЦОД или сайтов.

Предыдущие части цикла можно найти по ссылкам:

•1 часть цикла - L2 связанность между серверами
•2 часть цикла - Маршрутизация между VNI
•2.5 часть цикла - Теоретическое отступление
•3 часть цикла - Подключение внешнего маршрутизатора/firewall
•4 часть цикла - Multipod

Сегодня рассмотрим второй способ подключение различных ЦОД - Multisite.

Для начала вспомним как строится Underlay при построении фабрики с помощью Multipod. И снова получаем несколько вариантов построения такой сети. То есть:

1. Underlay сеть может быть единой и, например, использовать OSPF для IP связанности между всеми устройствами в фабрике.

2. Underlay повторяет логику BGP для настройки EVPN и каждый POD находится в своей AS, как показано на рисунке ниже

Однако, вспоминая предыдущую часть, приходим к тому, что во всех случаях возникают свои проблемы. Так в 1 случае, при едином OSPF процессе, может появиться слишком большое количество устройств (например более 100-150 устройств) и динамическая маршрутизация станет работать заметно медленнее и больше нагружать сетевые устройства. Во 2-м случае возникает еще больше проблем (ниже указаны не все проблемы, а только основные):

1. Смена Next-Hop. С использованием eBGP, при выходе update из AS, Next-hop меняется. То есть не забываем делать соответствующие настройки;

2. Общая проблема для обоих случаев - значение Route-target в автоматическом режиме работать не будет. То есть необходимо использовать статическую настройку, однако это решается автоматизацией таких настроек и сети в целом;

3. С увеличением количества клиентов, увеличивается и количество MAC/IP адресов и BUM трафик соответственно.

Исходя из перечисленных выше недостатков приходим к тому, что необходимо сегментировать сеть и реализуется это через технологию Multisite.

Для начала обсудим какие преимущества дает сегментация сети:

1. Уменьшение домена рассылки Broadcast для поиска какого-либо клиента сети;

2. Упрощается объединение различных подов через сеть интернет;

3. Проблемы в одном сайте никак не влияют на другой сайт;

4. Так как теперь каждый сайт независим от другого, то возможно использовать на одном сайте ingress replication, а на другом Multicast. То есть ЦОДы с различными технологиями объединяются без каких-либо проблем миграции.

Осталось разобраться как работает данная технология. Для начала рассмотрим теоретическую часть.

При реализации Multisite в сети появляется еще одна роль устройства - BGW(Border Gateway), которая может быть присвоена Spine, а может стать отдельным устройством в сети. В логической схеме дополнительное устройство встраивается выше Spine, как показано на рисунке ниже:

Но на самом деле, поставить BGW возможно в любое место в сети, главное обеспечить IP связанность

Осталось разобраться как же это все работает. Однако, для начала вернемся к предыдущим частям и вспомним как все работает в рамках одного POD. В одном POD тоннель устанавливается напрямую между VTEP, как показано ниже и LEAF коммутаторы напрямую обмениваются информацией о MAC/IP адресах.

То есть каждый LEAF должен знать о всех VTEP находящихся в его сети.
Теперь, когда вспомнили как работает сеть в рамках одно пода или нескольких, можем перейти к логике Multisite. Для начала приведу общую схему с логикой работы сети. Объяснение происходящего приведу ниже.

Получается что в Multisite тоннель от Leaf строится до BGW, далее BGW строит совершенно другой тоннель до второго BGW, находящего на другом сайте, и далее строится еще один тоннель уже в рамках другого сайта. Именно такая логика работы, когда между сайтами строится отдельный тоннель, позволяет сегментировать сеть, упростить поиск и устранение неисправностей, так как удаленный сайт полностью скрывается за 1 устройством(но рекомендуется использовать как минимум 2 BGW на каждом сайте для отказоустойчивости). Далее перейдем к настройке BGW, так как все остальные устройства не меняют свою настройку и никакие изменения на них не совершаются. Для начала на BGW необходимо включить следующие feature:

feature ospf - для организации Underlay в своем сайте

Настройка самой Underlay сети в данном разделе рассматриваться не будет, так как ничем не отличается от обычной реализации пода. При этом для IP связанности так же можно использовать IP unnumbered или адреса на point-to-point линках с маской /30 или /31.

После настройки Uderlay сети на BGW необходимо указать интерфейс, который смотрит в локальный сайт:

Interface Ethernet1/50
description SITE-INTERNAL
evpn multisite fabric-tracking - указываем где находится локальный сайт

Далее готовим настройки для Overlay сети. Выглядят они практически аналогично настройкам на Leaf коммутаторах. В целом это логично, так как BGW так же имеет роль VTEP.

feature bgp
feature nv overlay
nv overlay evpn

После включения необходимых фич, определяем коммутаторов как BGW и привязываем его к номеру сайта. Каждый BGW в одном сайте должен иметь одинаковый идентификатор.

evpn multisite border-gateway <site-id> номер сайта одинаковый у всех BGW в одном сайте

Продолжаем настройку BGW и создаем интерфейс NVE

interface nve1
  host-reachability protocol bgp
  source-interface loopback1 - как и на LEAF, интерфейс используется для построения тоннеля в рамках своего сайта
  multisite border-gateway interface loopback100 - новая настройка, используется для построения тоннеля между сайтами

Если у вас есть несколько BGW(а их должно быть хотя бы 2), то loopback100 должен иметь одинаковый адрес на всех устройствах с этой ролью - anycast адрес для сайта

Далее настраиваем протокол BGP для работы в локальном сайте. Настройка ничем не отличается от настройки на других устройствах в сетевой фабрике:

router bgp 65501
  neighbor 10.100.100.201
    remote-as 65501
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
   neighbor 10.100.100.202
    remote-as 65501
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended

На данном этапе мы произвели настройки необходимые для первого тоннеля между LEAF и BGW

Переходим ко второй части настройки - тоннель между сайтами. Сразу уточню, что этот тоннель всегда должен работать только в режиме ingress replication.

interface Ethernet1/1
  evpn multisite dci-tracking - команда указания, что интерфейс является внешним локального сайта и смотрит в сторону второго сайта

Последнее, что осталось настроить - BGP соседство со вторым сайтом:

router bgp 65501
  neighbor 10.52.52.52 - удаленный сосед
    remote-as 65036
    update-source loopback0 - устанавливаем так же с loopback
    ebgp-multihop 5
    peer-type fabric-external - указываем, что удаленный пир, относится к фабрике в другом сайте
    address-family l2vpn evpn
      send-community
      send-community extended
      rewrite-evpn-rt-asn - Так как можем использоваться автоматическая настройки RT, то его необходимо изменить на новое значение

Напомню, что RT - это route-target и в автоматическом режиме формируется из двух значений AS:VNI

Аналогично необходимо завести всех остальных соседей в других сайтах. При этом необходимо настроить Full-Mesh между всеми маршрутизаторами с ролью BGW во всех сайтах. Либо возможно использовать Route-reflector в eBGP. Настройка RR выглядит следующим образом:

router bgp 65036
  address-family l2vpn evpn
    retain route-target all - принимаем все анонсы с любом RT
  template peer OVERLAY-PEERING
    update-source loopback0
    ebgp-multihop 5
    address-family l2vpn evpn
      send-community both
      route-map UNCHANGED out - запрещаем менять значение атрибута Next-Hop

 neighbor 10.100.100.21 remote-as 65501
    inherit peer OVERLAY-PEERING
    address-family l2vpn evpn
      rewrite-evpn-rt-asn - так же переписываем значение RT, при автоматическом режиме установки RT

route-map UNCHANGED permit 10 - route-map в котором указываем запрет смены NH
  set ip next-hop unchanged 

Этап выше настраивает тоннель между сайтами, как показано на рисунке ниже:

Настройка Multisite, закончена, однако предлагаю рассмотреть варианты работы нескольких BGW в одном сайте. На сегодняшний день доступно 3 вида подключения BGW:

1. Вариант, что рассмотрели выше, без каких-либо настроек;

2. VPC BGW - до 2-х устройств;

3. Anycast BGW - до 4-х устройств.

Первый подход подробно рассматривать не будет, но, замечу, что для его реализации необходимо иметь линк между BGW в рамках одного сайта, как показано ниже.

Далее рассмотрим оставшиеся 2 подхода к реализации BGW и начнем с VPC BGW:

• только 2 устройства с физическим Peer-link и keepalive link(возможно использовать виртуальный, однако с точки зрения надежности я бы рекомендовал использовать прямой физический канал), что добавляет еще больше линков, нежели в 1 варианте подключения;

• Используется для небольших внедрений

Настройка VPC ничем не отличается от настройки VPC на Leaf коммутаторах. Так же требуется на интерфейсе Loopback создать secondary адрес, до которого будет строится VxLAN тоннель.

Anycast BGW и тут может возникнуть вопрос, чем же Anycast лучше. Разберемся по порядку. :

• до 6 устройств BGW в одном сайте;

• простой сценарий отработки проблем в сети, то есть все устройства независимы друг от друга, в отличии от VPC(да-да, там тоже разный Controle-Plane, однако это не спасает от багов);

• сеть любой сложности;

• простое развертывание с нуля устройств BGW, не влияя на сеть в целом.

То есть все устройства BGW Anycast прячутся за одним виртуальным адресом, как показано на рисунке ниже

Настройка мало чем отличается от реализации рассмотренной в начале данного материала:

 interface loopback100 - интерфейс указанный как multisite border-gateway
 description MULTI-SITE INTERFACE
  ip address 10.10.10.10/32 - одинаковый адрес на всех BGW
  ip router ospf UNDERLAY area 0.0.0.0 - IP связанность в рамках локального сайта

На этом настройка связанности между сайтами закончена. На момент написания данного материала не получается реализовать mulisite в виртуальной среде. На железе все запускается без особых проблем. Возможно в новых виртуальных образах ситуация исправлена.

Ниже предлагаю пройти опрос, на какой стадии использования VxLAN EVPN вы сейчас находитесь.

Подробнее про работу технологии можно посмотреть в RFC-7432 и в draft-ietf-bess-evpn-overlay, draft-ietf-bess-evpn-prefix-advertisement, draft-ietf-bess-evpn-inter-subnet-forwarding

Современная IT инфраструктура все больше виртуализируется, уплывая в Облака. Модели "все как сервис"- SaaS, PaaS, IaaS используются повсеместно, но все эти решения, по-прежнему используют сети передачи данных и машинные ресурсы для их обработки. За последние 20 лет, сети ЦОД, претерпели множество изменений, с которыми попробуем познакомиться ближе и разобрать основные технологические этапы этой эволюции с присущими им технологиями и архитектурными решениями в рамках бесплатного демо-урока по теме: "Эволюция сетевых технологий в ЦОД".

Записаться на демо-урок