Привіт, хабр. В даний час я керівник курсу "Мережевий інженер" в OTUS.
Напередодні старту нового набору на курс я підготував цикл статей за технологією VxLAN EVPN.
Існує безліч матеріалів по роботі VxLAN EVPN, тому я хочу зібрати різні завдання та практики вирішення завдань у сучасному ЦОД.
У першій частині циклу за технологією VxLAN EVPN хочу розглянути спосіб організації L2 зв'язаності між хостами поверх мережевої фабрики.
Всі приклади виконуватимемо на 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 працюють у парі та об'єднані 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 ! указываем, что для распространения информации о хосте используем 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 днів після трансляції.
Джерело: habr.com