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

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

До этого момента тема eBGP в overlay практически не затрагивалась, за исключением Multipod топологии, однако, и там все было довольно поверхностно и не хватает деталей для полной реализации в одном поде. Так что исправим это допущение и рассмотрим поближе eBGP.

Для начала предлагаю определиться для чего использовать eBGP и для чего iBGP(тут чисто субъективный взгляд. Ваше мнение может сильно отличаться от мнения автора):

iBGP - удобно использовать, когда в underlay сети настроен протокол семейства IGP, например, OSPF или IS-IS. В этом случае нет смысла усложнять топологию различными AS в BGP и вполне логично использовать только iBGP.
eBGP - используется, когда в underlay так же настроен BGP. При этом довольна частая ситуация, что сеть underlay разделяют на различные AS(возможно в данном случае удобно делать фильтры по AS-path). Тогда ничего не остается и приходится использовать eBGP еще и в Overlay(большая редкость, когда устройства позволяют запустить несколько процессов BGP с разным номер AS)

Перейдем непосредственно к сравнению различных реализаций протокола. Сеть underlay у нас остается неизменна и представлена ниже:

При использовании eBGP в underlay сеть принято разделять на зоны следующим образом:

Каждый Spine находится в одной автономной системе. Будем использовать AS 65000
Каждый Leaf находится в своей автономной системе. Номера AS начинаются с 65500 и далее

Такой подход позволяет избежать петель в сети, так как update пришедший от одного Spine к другому Spine будет отброшен из-за одинаково номера AS:

Решение для без петлевой сети, при одинаковом номере AS на Spine

При этом Leaf находятся в разных AS и все update от одного Leaf спокойно дойдут до всех остальных:

Распространение update к Leaf в разных AS

Таким образом, underlay сеть может работать стабильно без дополнительных конфигураций и добавления роли Route-reflector в сеть. Но такая простота в одном месте способна усложнить жизнь в другом. Для начала рассмотрим конфигурации iBGP:

Spine:

feature bgp
nv overlay evpn
router bgp 65001
  template peer LEAF 
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
      route-reflector-client
  neighbor 10.255.1.11
    inherit peer LEAF
  neighbor 10.255.1.12
    inherit peer LEAF
  neighbor 10.255.1.21
    inherit peer LEAF

И на Leaf:

feature bgp
nv overlay evpn
router bgp 65001
  template peer SPINE
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.1.101
    inherit peer SPINE
  neighbor 10.255.1.102
    inherit peer SPINE

В целом все выглядит довольно просто и никаких сложностей тут не должно возникнуть. Далее рассмотрим конфигурации route-targer на Leaf коммутаторе для L2VNI, который используется при передаче update по overlay сети и позволяет отдельным VTEP добавлять только определенные update, а не update из всей в сети overlay.

evpn
  vni 10000 l2
    route-target import auto 
    route-target export auto

Как видно все довольно просто и не требует каких-либо сложностей и дополнительных вопросов.

Думаю с iBGP разобрались, все-таки большая часть цикла посвящена именно данной задаче и пора бы приступить к рассмотрению eBGP.

Для начала рассмотрим настройку BGP Spine:

feature bgp
nv overlay evpn
router bgp 65000
  template peer LEAF 
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.1.11
    remote-as 65501
    inherit peer LEAF
  neighbor 10.255.1.12
    remote-as 65502
    inherit peer LEAF
  neighbor 10.255.1.21
    remote-as 65503
    inherit peer LEAF

Leaf:

feature bgp
nv overlay evpn
router bgp 65501
  template peer SPINE
    address-family l2vpn evpn
      send-community
      send-community extended
  neighbor 10.255.1.101
    remote-as 65000
    inherit peer SPINE
  neighbor 10.255.1.102
    remote-as 65000
    inherit peer SPINE

Настройка eBGP особо не отличается от iBGP, за исключением номеров AS и удаление Route-reflector. Однако, попробуйте остановиться и подумать что может пойти не так, если мы оставим настройку в таком состоянии.

А пойти не так может следующее:

Первая проблема - в отличии от iBGP в eBGP меняется Next-hop при переходе из одной AS в другую, то есть Leaf в AS 65502 увидит не NH Leaf в 65501, а адрес Spine из AS 65000 и попытается построить VxLAN до этого NH. Вполне логично, что это не заработает:

На Spine нет того клиента к которому обращается Leaf
Spine не имеет включенных фич для работы с VxLAN и не может выступать в роли VTEP.

Такая задача решается принудительным запретов Spine менять адрес Next-hop в сторону leaf коммутаторов. Необходимо создать route-map в котором будет следующая настройка:

route-map UNCHANCHED_NH permit 10
    set ip next-hop unchanged

Далее применяем это все к соседям Leaf:

template peer LEAF 
    route-map UNCHANCHED_NH out

После применения команды Spine перестанет менять NH. Дополнительно замечу, что на Cisco Nexus не предусмотрена отдельная команда для запрета смены NH. Этот вопрос можно решить только с помощью route-map, что в свою очередь дает возможность применять команду только к отдельным update(например, использовать различные ACL или Prefix-list и т.п. для выбора определенного update).

Вторая проблема, на первый взгляд, не такая явная и связана она с route-target и будет основным не удобством eBGP в Overlay. Тут появляется сразу два неудобства:

Первое неочевидное неудобство заключается в невозможности использовать параметр auto, так как в этом случае route-target берет значения AS:VNI, в eBGP же AS всегда будет разный, а значит route-target не совпадет между разными Leaf. Решается проблема довольно просто - заданием данной настройки вручную:

evpn
  vni 10000 l2
    route-target import 9999:10000 
    route-target export 9999:10000

Под каждый VNI необходимо задавать свои настройки и соблюдать идентичность RT между VTEP. Это задача довольно просто решается автоматизацией настройки VTEP, вручную вполне можно запутаться. Можно сказать, что тут наступает момент когда сетевику надо пойти в автоматизацию.

Второе неочевидное неудобство, как ни странно, находится на Spine. Все дело в том, что Spine тоже смотрит в поле RT и если значение пришло не из внутренней AS - update отбрасывается. Тут придется немного схитрить и добавить команды:

router bgp 65000
    address-family l2vpn evpn
      retain route-target all

Подведем некий итог. Если посмотрим более внимательно на логику работы Spine, то получается он берет на себя некую роль Route-reflector и просто пересылает update без какой-либо обработки. То есть:

Не меняется NH, как при использовании RR.
На Spine принимаются абсолютно все update, даже если устройство не знает путь до хоста назначения, и передается на Leaf, что нарушает логику выбора лучшего маршрута BGP(маршрут должен быть валидным. При неопределённом route-target, маршрут никогда таковым не станет)

На Leaf же настройки особо не меняются, за исключением ручной записи RT, что, опять же, решает автоматизацией такой задачи.

В результате, выбирая между iBGP и eBGP в unerlay, нет точного решения что использовать. Однако, я в своих проектах придерживаюсь логики:

iBGP, если в underlay работает протокол IGP
eBGP, если в underlay работает eBGP.

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

И, конечно же, не используйте Overlay. Используйте только маршрутизацию.

Данная статья написана специально для курса "Дизайн сетей ЦОД". В преддверии старта курса приглашаем всех желающих на бесплатный демоурок в рамках которого мы рассмотрим плюсы и минусы реализации iBGP. Преимущества перед eBGP.

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

VxLAN iBGP vs eBGP