Привет, хабр. В настоящее время я являюсь руководителем курса "Сетевой инженер" в OTUS.
В преддверии старта нового набора на курс "Сетевой инженер", я подготовил цикл статей по технологии VxLAN EVPN.
Существует огромное множество материалов по работе VxLAN EVPN, поэтому я хочу собрать различные задачи и практики решения задач в современном ЦОД.
В первой части цикла по технологии VxLAN EVPN хочу рассмотреть способ организации L2 cвязанности между хостами поверх сетевой фабрики.
Все примеры будем выполнять на Cisco Nexus 9000v, собранных в топологию Spine-Leaf. Останавливаться на настройке Underlay сети в рамках этой статьи мы не будем.
- Underlay сеть
- BGP пиринг для address-family l2vpn evpn
- Настройка NVE
- Supress-arp
Underlay сеть
Используемая топология выглядит следующим образом:
Зададим адресацию на всех устройствах:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Проверим что есть IP связанность между всеми устройствами:
Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 доступен чеерз два Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraПроверим, что VPC домен создан и оба коммутатора прошли проверку консистенции и настройки на обеих нодах идентичны:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP пиринг
Наконец можно перейти к настройке Overlay сети.
В рамках статьи необходимо организовать сеть между хостами, как показано на схеме ниже:
Для настройки Overlay сети необходимо на Spine и Leaf коммутаторах включить BGP с поддержкой семейства l2vpn evpn:
feature bgp
nv overlay evpnДалее необходимо настроить BGP пиринг между Leaf и Spine. Для упрощения настройки и оптимизации распространения маршрутной информации Spine настраиваем в качестве Route-Reflector server. Все Leaf пропишим в конфиге через шаблоны, чтобы оптимизировать настройку.
Таким образом настройки на Spine выглядит так:
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 коммутаторе выглядит аналогичным образом:
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На Spine проверим пиринг со всеми Leaf коммутаторами:
Spine1# sh bgp l2vpn evpn summary
<.....>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Как видим, с BGP никаких проблем не возникло. Перейдем к настройке VxLAN. Дальнейшая настройка будет производиться только на стороне Leaf коммутаторов. Spine выступает только в качестве ядра сети и занимаются только передачей трафика. Вся работа по инкапсуляции и определении пути происходит только на Leaf коммутаторах.
Настройка NVE
NVE — network virtual interface
Перед началом настройки введем немного терминологии:
VTEP — Vitual Tunnel End Point, устройство на котором начинается или заканчивается VxLAN тоннель. VTEP это не обязательно какое-либо сетевое устройство. Так же может выступать и сервер с поддержкой технологии VxLAN. В нашей топологии все Leaf коммутаторы являются VTEP.
VNI — Virtual Network Index — идентификатор сети в рамках VxLAN. Можно провести аналогию с VLAN. Однако есть некоторые отличия. При использовании фабрики, VLAN становятся уникальными только в рамках одного Leaf коммутатора и не передаются по сети. Но с каждым VLAN может быть проассоциирован номер VNI, который уже передается по сети. Как это выглядит и как это можно использовать будет рассмотрено далее.
Включим feature для работы технологии VxLAN и возможность ассоциировать номера VLAN с номером VNI:
feature nv overlay
feature vn-segment-vlan-basedНастроим интерфейс NVE, который отвечает за работу VxLAN. Данный интерфейс как раз и отвечает за инкапсуляцию кадров в VxLAN заголовки. Можно провести аналогию с Tunnel интерфейсом для работы GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0На Leaf-21 коммутаторе все создается без проблем. Однако, если мы проверим вывод команды show nve peers, то он окажется пустым. Тут необходимо вернуться к настройке VPC. Мы видим, что Leaf-11 и Leaf-12 работают в парe и объединены VPC доменом. От сюда получается следующая ситуация:
Host-2 отправляет один кадр в сторону Leaf-21, чтобы тот передал его по сети в сторону Host-1. Однако Leaf-21 видит что MAC адрес Host-1 доступен сразу через два VTEP. Как в этом случае поступить Leaf-21? Ведь это значит что в сети могла появиться петля.
Для решения этой ситуации нам необходимо чтобы Leaf-11 и Leaf-12 в рамках фабрики так же выступали одним устройством. Решается это довольно просто. На интерфейсе Loopback с которого строим тоннель, добавляем secondary адрес. Secondary адрес должен быть одинаковым на обоих VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryТаким образом с точки зрения других VTEP мы получаем следующую топологию:
То есть теперь тоннель будет строиться между IP адресом Leaf-21 и виртуальным IP между двумя Leaf-11 и Leaf-12. Теперь проблем с изучением MAC адреса от двух устройств возникать не будет и трафик может переходить от одного VTEP на другой. Кто именно из двух VTEP обработает трафик решается с помощью таблицы маршрутизации на Spine:
Spine1# sh ip route
<.....>
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraКак видно выше адрес 10.255.1.10 доступен сразу через два Next-hop.
На данной этапе разобрались с базовой связанностью. Перейдем к настройке интерфейса NVE:
Сразу включим Vlan 10 и проассоциируем его с VNI 10000 на каждом Leaf для хостов. Настроим L2 тоннель между хостами
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения BUM трафика
используем BGPТеперь проверим nve peers и таблицу для BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iВыше видим маршруты только EVPN route-type 3. Данный тип маршрутов рассказывает о peer(Leaf), однако где же наши хосты?
А дело все в том, что информация о MAC хостов передается через EVPN route-type 2
Для того чтобы увидеть наши хосты необходимо настроить EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoСделаем ping с Host-2 на Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msИ ниже мы можем видеть, что в таблице BGP появились route-type 2 c MAC адресом хостов — 5001.0007.0007 и 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iДалее можно посмотреть подробную информацию по Update, в котором получили информацию о MAC Host. Ниже представлен не весь вывод команды
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>Давайте посмотрим как выглядят кадры, когда они передаются через фабрику:
Suppress-ARP
Отлично, L2 связь между хостами у нас появилась и на этом можно было бы закончить. Однако не все так просто. Пока у нас мало хостов проблем не возникнет. Но давайте представим ситуации, что хостов у нас сотни и тысячи. С какой проблемой мы можем столкнуться?
Эта проблема — BUM(Broadcast, Unknown Unicast, Multicast) трафик. В рамках этой статьи рассмотрим вариант борьбы с broadcast трафиком.
Основной генератор Broadcast в Ethernet сетях сами хосты через протокол ARP.
На nexus реализован следующий механизм для борьбы с ARP запросами — suppress-arp.
Работа данной фичи выглядит следующим образом:
- Host-1 отправляет APR запрос на Broadcast адрес своей сети.
- Запрос доходит до Leaf коммутатора и вместо того чтобы передать этот запрос дальше в фабрику в сторону Host-2 — Leaf отвечает сам и указывает нужный IP и MAC.
Таким образом Broadcast запрос не ушел в фабрику. Но как это может работать, если Leaf знает только MAC адрес?
Все довольно просто, EVPN route-type 2 помимо MAC адреса может передавать связку MAC/IP. Для этого на Leaf необходимо настроить IP адрес в VLAN. Появляется вопрос, какой IP задать? На nexus есть возможность создать распределенный (одинаковый) адрес на всех коммутаторах:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macТаким образом с точки зрения хостов сеть будет выглядеть следующим образом:
Проверим BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
* i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
<......>
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 i
<......>Из вывода команды видно, что в EVPN route-type 2 помимо MAC теперь видим еще и IP адрес хоста.
Возвращаемся к настройке suppress-arp. Включается эта настройка для каждого VNI отдельно:
interface nve1
member vni 10000
suppress-arpДальше возникает некоторая сложность:
- Для работы данной фичи необходимо место в TCAM памяти. Приведу пример настройки для suppress-arp:
hardware access-list tcam region arp-ether 256Для данной настройки потребуется double-wide. То есть если задаете 256, то в TCAM необходимо освободить 512. Настройка TCAM выходит за пределы данной статьи, так как настройка TCAM зависит только от задачи поставленной перед Вами и может отличаться от одной сети к другой.
- Внедрение suppress-arp необходимо сделать на всех Leaf коммутаторах. Однако сложность может возникнуть при настройке на парах Leaf, находящихся в домене VPC. При изменении TCAM, консистенция между парами будет нарушена и одна нода может быть выведена из работы. Дополнительно для применения настройки изменении TCAM может потребоваться перезагрузка устройства.
В результате надо как следует подумать, стоит ли в вашей ситуации внедрить данную настройку на работающую фабрику.
На этом закончим первую часть цикла. В следующей части рассмотрим маршрутизацию через VxLAN фабрику с разделением сетей по различным VRF.
А сейчас приглашаю всех на бесплатный вебинар, в рамках которого я подробно расскажу про курс. Первые 20 участников, зарегистрировавшихся на этот вебинар, получат Сертификат на скидку на электронную почту в течение 1-2 дней после трансляции.