Предыдущие части цикла можно найти по ссылкам:
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:
При этом Leaf находятся в разных AS и все update от одного Leaf спокойно дойдут до всех остальных:
Таким образом, 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 LEAFLeaf:
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.
Записаться на демоурок