Ahoj habr. Momentálne som vedúcou kurzu pre kurz Network Engineer v OTUS.
V očakávaní začiatku nového zápisu do kurzu , pripravil som sériu článkov o technológii VxLAN EVPN.
Existuje obrovské množstvo materiálu o tom, ako funguje VxLAN EVPN, preto chcem zhromaždiť rôzne úlohy a postupy na riešenie problémov v modernom dátovom centre.
V prvej časti série o technológii VxLAN EVPN sa chcem pozrieť na spôsob, ako zorganizovať L2 konektivitu medzi hostiteľmi na vrchole sieťovej štruktúry.
Všetky príklady budú realizované na Cisco Nexus 9000v zostavenom v topológii Spine-Leaf. V tomto článku sa nebudeme zaoberať nastavením siete Underlay.
- Podkladová sieť
- Partnerský vzťah BGP pre rodinu adresy l2vpn evpn
- Nastavenie NVE
- Potlačiť-arp
Podkladová sieť
Použitá topológia je nasledovná:
Nastavíme adresovanie na všetkých zariadeniach:
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.20Skontrolujte, či je medzi všetkými zariadeniami pripojenie 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, intraSkontrolujeme, či bola vytvorená doména VPC a oba prepínače prešli kontrolou konzistencie a nastavenia na oboch uzloch sú identické:
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 1Peering BGP
Nakoniec môžete prejsť k nastaveniu siete Overlay.
Ako súčasť článku je potrebné zorganizovať sieť medzi hostiteľmi, ako je znázornené na obrázku nižšie:
Ak chcete nakonfigurovať sieť Overlay, musíte povoliť BGP na prepínačoch Spine a Leaf s podporou pre rodinu l2vpn evpn:
feature bgp
nv overlay evpnĎalej musíte nakonfigurovať peering BGP medzi Leaf a Spine. Aby sme zjednodušili nastavenie a optimalizovali distribúciu smerovacích informácií, konfigurujeme Spine ako Route-Reflector server. Všetky Leaf napíšeme do konfigurácie pomocou šablón na optimalizáciu nastavenia.
Takže nastavenia na Spine vyzerajú takto:
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 LEAFNastavenie na prepínači Leaf vyzerá podobne:
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 SPINENa Spine skontrolujme peering so všetkými prepínačmi 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 0Ako vidíte, s BGP neboli žiadne problémy. Prejdime k nastaveniu VxLAN. Ďalšia konfigurácia bude vykonaná len na strane Leaf prepínačov. Chrbtica funguje len ako jadro siete a podieľa sa len na prenose prevádzky. Všetky práce na zapuzdrení a určovaní cesty sa vyskytujú iba na prepínačoch Leaf.
Nastavenie NVE
NVE - sieťové virtuálne rozhranie
Pred začatím nastavenia si predstavme nejakú terminológiu:
VTEP - Vitual Tunnel End Point, zariadenie, na ktorom začína alebo končí tunel VxLAN. VTEP nie je nevyhnutne žiadne sieťové zariadenie. Server podporujúci technológiu VxLAN môže fungovať aj ako server. V našej topológii sú všetky prepínače Leaf VTEP.
VNI - Virtual Network Index - sieťový identifikátor v rámci VxLAN. Analógiu možno nakresliť s VLAN. Existujú však určité rozdiely. Pri použití tkaniva sa siete VLAN stanú jedinečnými iba v rámci jedného prepínača Leaf a neprenášajú sa cez sieť. Každá VLAN však môže mať priradené číslo VNI, ktoré sa už prenáša cez sieť. Ako to vyzerá a ako sa dá použiť, sa bude diskutovať ďalej.
Umožnime fungovanie funkcie technológie VxLAN a možnosť priradiť čísla VLAN k číslu VNI:
feature nv overlay
feature vn-segment-vlan-basedPoďme nakonfigurovať rozhranie NVE, ktoré je zodpovedné za prevádzku VxLAN. Toto rozhranie je zodpovedné za zapuzdrenie rámcov v hlavičkách VxLAN. Môžete nakresliť analógiu s rozhraním tunela pre GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Na prepínači Leaf-21 je všetko vytvorené bez problémov. Ak však skontrolujeme výstup príkazu show nve peers, potom bude prázdny. Tu sa musíte vrátiť do konfigurácie VPC. Vidíme, že Leaf-11 a Leaf-12 pracujú v pároch a sú spojené doménou VPC. To nám dáva nasledujúcu situáciu:
Hostiteľ-2 posiela jeden rámec smerom k listu-21, takže ho prenáša cez sieť smerom k hostiteľovi-1. Leaf-21 však vidí, že MAC adresa hostiteľa-1 je dostupná cez dva VTEP naraz. Čo by mal Leaf-21 urobiť v tomto prípade? Koniec koncov to znamená, že v sieti by sa mohla objaviť slučka.
Na vyriešenie tejto situácie potrebujeme, aby Leaf-11 a Leaf-12 fungovali aj ako jedno zariadenie v továrni. Riešenie je celkom jednoduché. Na rozhraní Loopback, z ktorého vytvárame tunel, pridajte sekundárnu adresu. Sekundárna adresa musí byť rovnaká na oboch VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryZ pohľadu iných VTEP teda dostávame nasledujúcu topológiu:
To znamená, že teraz bude tunel vybudovaný medzi IP adresou Leaf-21 a virtuálnou IP medzi dvoma Leaf-11 a Leaf-12. Teraz nebudú žiadne problémy s učením MAC adresy z dvoch zariadení a prevádzka sa môže presunúť z jedného VTEP do druhého. Ktorý z dvoch VTEP spracuje prevádzku, sa rozhodne pomocou smerovacej tabuľky na 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, intraAko môžete vidieť vyššie, adresa 10.255.1.10 je dostupná okamžite cez dva Next-hopy.
V tejto fáze sme sa zaoberali základnou konektivitou. Prejdime k nastaveniu rozhrania NVE:
Okamžite povoľme Vlan 10 a priraďme ho k VNI 10000 na každom liste pre hostiteľov. Nastavme L2 tunel medzi hostiteľmi
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPTeraz sa pozrime na nových partnerov a tabuľku pre 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 iVyššie vidíme iba trasy typu EVPN typu 3. Tento typ trasy hovorí o peer (Leaf), ale kde sú naši hostitelia?
Ide o to, že informácie o hostiteľoch MAC sa prenášajú prostredníctvom trasy EVPN typu 2
Ak chcete vidieť našich hostiteľov, musíte nakonfigurovať smerovanie EVPN typu 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoPoďme ping z hostiteľa-2 na hostiteľa-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 msA nižšie vidíme, že v tabuľke BGP sa objavila trasa typu 2 s hostiteľskou MAC adresou - 5001.0007.0007 a 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Ďalej môžete vidieť podrobné informácie o aktualizácii, v ktorej ste dostali informácie o hostiteľovi MAC. Nižšie nie je celý výstup príkazu.
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
<........>Pozrime sa, ako rámy vyzerajú, keď prechádzajú továrňou:
Potlačiť-ARP
Skvelé, teraz máme medzi hostiteľmi komunikáciu L2 a tam by sme mohli skončiť. Nie všetko je však také jednoduché. Pokiaľ budeme mať málo hostiteľov, nebudú žiadne problémy. Predstavme si však situáciu, že máme stovky a tisíce hostiteľov. Akému problému môžeme čeliť?
Tento problém je BUM (Broadcast, Unknown Unicast, Multicast) prevádzka. V tomto článku sa budeme zaoberať možnosťou riešenia vysielanej prevádzky.
Hlavným generátorom vysielania v sieťach Ethernet sú samotní hostitelia prostredníctvom protokolu ARP.
Nexus implementuje nasledujúci mechanizmus na boj proti požiadavkám ARP - potlačenie-arp.
Táto funkcia funguje nasledovne:
- Hostiteľ-1 odošle požiadavku APR na vysielaciu adresu svojej siete.
- Požiadavka sa dostane k prepínaču Leaf a namiesto toho, aby túto požiadavku odovzdala ďalej látke smerom k hostiteľovi-2, Leaf odpovie sám a uvedie požadovanú IP a MAC.
Žiadosť o vysielanie teda nešla do továrne. Ale ako to môže fungovať, ak Leaf pozná iba MAC adresu?
Všetko je celkom jednoduché, EVPN route-type 2 okrem MAC adresy dokáže prenášať aj kombináciu MAC/IP. Aby ste to dosiahli, musíte nakonfigurovať IP adresu vo VLAN na Leaf. Vyvstáva otázka, akú IP mám nastaviť? Na nexuse je možné vytvoriť distribuovanú (rovnakú) adresu na všetkých prepínačoch:
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 macZ pohľadu hostiteľov teda bude sieť vyzerať takto:
Skontrolujeme 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
<......>Z výstupu príkazu môžete vidieť, že v EVPN route-type 2 teraz okrem MAC vidíme aj IP adresu hostiteľa.
Vráťme sa k nastaveniu supresia-arp. Toto nastavenie je povolené pre každý VNI samostatne:
interface nve1
member vni 10000
suppress-arpPotom vzniká určitá zložitosť:
- Aby táto funkcia fungovala, je potrebné miesto v pamäti TCAM. Tu je príklad nastavení pre potlačenie-arp:
hardware access-list tcam region arp-ether 256Toto nastavenie bude vyžadovať dvojnásobnú šírku. To znamená, že ak nastavíte 256, musíte v TCAM uvoľniť 512. Nastavenie TCAM je nad rámec tohto článku, pretože nastavenie TCAM závisí len od úlohy, ktorá vám bola pridelená a môže sa líšiť v závislosti od siete.
- Implementácia potlačenia-arp sa musí vykonať na všetkých prepínačoch Leaf. Zložitosť však môže vzniknúť pri konfigurácii na pároch listov, ktoré sa nachádzajú v doméne VPC. Ak sa zmení TCAM, konzistencia medzi pármi sa naruší a jeden uzol môže byť vyradený z prevádzky. Okrem toho môže byť potrebné reštartovanie zariadenia na použitie nastavenia zmeny TCAM.
V dôsledku toho musíte dôkladne zvážiť, či sa vo vašej situácii oplatí implementovať toto nastavenie do bežiacej fabriky.
Týmto sa končí prvá časť série. V ďalšej časti sa pozrieme na smerovanie cez tkaninu VxLAN s oddelením sietí do rôznych VRF.
A teraz všetkých pozývam , v rámci ktorej vám podrobne poviem o kurze. Prvých 20 účastníkov, ktorí sa zaregistrujú na tento webinár, dostane certifikát o zľave e-mailom do 1-2 dní po vysielaní.
Zdroj: hab.com