Ciao habr. Sò attualmente u capu di cursu per "Ingegnere di rete" in OTUS.
In anticipazione di l'iniziu di una nova iscrizzione per u corsu , Aghju preparatu una seria d'articuli nantu à a tecnulugia VxLAN EVPN.
Ci hè una quantità enorme di materiale nantu à u funziunamentu di VxLAN EVPN, cusì vogliu cullà diverse attività è pratiche per risolve i prublemi in un centru di dati mudernu.
In a prima parte di u ciculu di tecnulugia VxLAN EVPN, vogliu cunsiderà un modu per urganizà a cunnessione L2 trà l'ospiti nantu à una fabbrica di rete.
Tutti l'esempii seranu realizati nantu à Cisco Nexus 9000v, assemblati in a topologia Spine-Leaf. Ùn ci fermamu micca nantu à a creazione di a rete Underlay in questu articulu.
- rete di sottu
- Peering BGP per l'indirizzu-famiglia l2vpn evpn
- Configurazione NVE
- Suppress-arp
rete di sottu
A topologia aduprata hè a siguenti:
Fixemu l'indirizzu nantu à tutti i dispositi:
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.20Cuntrollamu chì ci hè una cunnessione IP trà tutti i dispositi:
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, intraCuntrollamu chì u duminiu VPC hè statu creatu è i dui switches anu passatu u cuntrollu di coerenza è i paràmetri di i dui nodi sò identici:
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
Infine, pudemu passà à cunfigurà a reta Overlay.
Comu parte di l'articulu, hè necessariu urganizà una reta trà l'ospiti, cum'è mostra in u diagramma sottu:
Per cunfigurà una rete Overlay, avete bisognu di attivà BGP nantu à i switches Spine è Leaf cù supportu per a famiglia l2vpn evpn:
feature bgp
nv overlay evpnDopu, avete bisognu di cunfigurà u peering BGP trà Leaf è Spine. Per simplificà a cunfigurazione è ottimisimu a distribuzione di l'infurmazioni di routing, cunfiguremu Spine cum'è un servitore Route-Reflector. Scriveremu tutte e Leaf in a cunfigurazione attraversu mudelli per ottimisà u paràmetru.
Allora i paràmetri di Spine sò cusì:
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 LEAFA cunfigurazione nantu à l'interruttore Leaf hè simile:
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 SPINEIn Spine, verificate u peering cù tutti i switch 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 0Comu pudete vede, ùn ci era micca prublemi cù BGP. Passemu à a stallazione di VxLAN. Ulteriori cunfigurazione serà realizatu solu à u latu di i switch Leaf. Spine agisce solu cum'è u core di a reta è hè solu implicatu in a trasmissione di u trafficu. Tuttu u travagliu nantu à l'incapsulazione è a definizione di a strada si trova solu nantu à i switch Leaf.
Configurazione NVE
NVE - interfaccia virtuale di rete
Prima di inizià a cunfigurazione, introducemu qualchì terminologia:
VTEP - Vitual Tunnel End Point, u dispusitivu nantu à quale u tunnel VxLAN principia o finisce. VTEP ùn hè micca necessariamente un dispositivu di rete. Un servitore chì sustene a tecnulugia VxLAN pò ancu agisce. In a nostra topologia, tutti i switch Leaf sò VTEP.
VNI - Virtual Network Index - identificatore di rete in VxLAN. Pudete fà una analogia cù VLAN. Tuttavia, ci sò qualchi differenzi. Quandu si usa un tissu, i VLAN diventanu unichi solu in un switch Leaf è ùn sò micca trasmessi nantu à a reta. Ma ogni VLAN pò esse assuciatu cù un numeru VNI chì hè digià trasmessu nantu à a reta. Ciò chì pare è cumu si pò esse usatu serà discututu quì sottu.
Habilita a funzione per a tecnulugia VxLAN per travaglià è a capacità di associà numeri VLAN cù un numeru VNI:
feature nv overlay
feature vn-segment-vlan-basedCunfiguremu l'interfaccia NVE, chì hè rispunsevule per l'operazione di VxLAN. Questa interfaccia hè rispunsevuli di incapsulating frames in headers VxLAN. Pudete fà una analogia cù l'interfaccia Tunnel per GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0In u switch Leaf-21, tuttu hè creatu senza prublemi. Tuttavia, s'è no verificate u risultatu di u cumandamentu show nve peers, allura sarà viotu. Quì avete bisognu di vultà à a cunfigurazione VPC. Avemu vistu chì Leaf-11 è Leaf-12 sò assuciati è uniti da un duminiu VPC. Questu risultatu in a situazione seguente:
Host-2 manda un quadru à Leaf-21 per esse trasmessu nantu à a reta à Host-1. Tuttavia, Leaf-21 vede chì l'indirizzu MAC di Host-1 hè dispunibule via dui VTEP à una volta. Chì duverebbe fà Leaf-21 in questu casu? Dopu tuttu, questu significa chì un ciclu puderia apparisce in a reta.
Per risolve sta situazione, avemu bisognu di Leaf-11 è Leaf-12 per agisce ancu cum'è un dispositivu in a fabbrica. Hè risolta abbastanza simplice. Nant'à l'interfaccia Loopback da quale custruemu u tunnel, aghjunghje l'indirizzu secundariu. L'indirizzu secundariu deve esse u stessu nantu à i dui VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryCusì, da u puntu di vista di l'altri VTEP, avemu a seguente topologia:
Questu hè, avà u tunnel serà custruitu trà l'indirizzu IP di Leaf-21 è l'IP virtuale trà dui Leaf-11 è Leaf-12. Avà ùn ci sarà micca prublemi cù amparà l'indirizzu MAC da dui dispusitivi, è u trafficu pò esse trasferitu da un VTEP à l'altru. Quale di i dui VTEP prucederà u trafficu hè decisu utilizendu a tabella di routing in 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, intraComu pudete vede sopra, l'indirizzu 10.255.1.10 hè dispunibule immediatamente attraversu dui Next-hops.
In questu stadiu, avemu capitu a cunnessione di basa. Passemu à cunfigurà l'interfaccia NVE:
Abiliteremu immediatamente Vlan 10 è l'associemu cù VNI 10000 nantu à ogni Leaf per l'ospiti. Stallà un tunnel L2 trà l'ospiti
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPAvà cuntrollemu nve peers è table per 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 iSopra avemu vistu rotte solu EVPN route-type 3. Stu tipu di rotte parla di peer (Leaf), ma induve sò i nostri ospiti?
È a cosa hè chì l'infurmazioni nantu à l'ospiti MAC sò trasmessi via EVPN route-type 2
Per vede i nostri ospiti, avete bisognu di cunfigurà EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoFacemu ping da 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È quì sottu pudemu vede chì u tipu di rotta 2 apparsu in a tavola BGP cù l'indirizzu MAC di l'ospiti - 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 iIn seguitu, pudete vede infurmazioni detallati nantu à l'aghjurnamentu, in quale avete ricevutu infurmazioni nantu à u MAC Host. Quì sottu ùn hè micca tutta a pruduzzioni di u cumandamentu
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
<........>Videmu cumu si vede i frames quandu sò passati per a fabbrica:
Suppress-ARP
Grande, avemu una cunnessione L2 trà l'ospiti è questu puderia esse a fine di questu. Tuttavia, micca tutti cusì sèmplice. Sempre chì avemu pochi ospiti, ùn ci saranu micca prublemi. Ma imaginemu situazioni chì avemu centinaie è millaie di ospiti. Chì prublema pudemu affruntà ?
Stu prublema hè u trafficu BUM (Broadcast, Unknown Unicast, Multicast). In u quadru di questu articulu, cunsideremu l'opzione di cumbattimentu di u trafficu di trasmissione.
U principale generatore di trasmissione in rete Ethernet hè l'ospiti stessi via u protocolu ARP.
Nexus implementa u mekanismu seguitu per trattà e dumande ARP - suppress-arp.
Questa funzione funziona cusì:
- Host-1 manda una dumanda APR à l'indirizzu Broadcast di a so reta.
- A dumanda ghjunghje à l'interruttore Leaf è invece di passà sta dumanda più à a fabbrica versu l'Host-2, u Leaf si risponde è indica l'IP è MAC desiderate.
Cusì, a dumanda Broadcast ùn hè micca andata à a fabbrica. Ma cumu si pò travaglià se Leaf cunnosci solu l'indirizzu MAC?
Tuttu hè abbastanza simplice, EVPN route-type 2, in più di l'indirizzu MAC, pò trasmette un bundle MAC / IP. Per fà questu, u Leaf deve esse cunfiguratu cù un indirizzu IP in a VLAN. A quistione sorge, chì IP dumandà? In u nexus, hè pussibule di creà un indirizzu distribuitu (stessu) in tutti i switches:
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 macCusì, da u puntu di vista di l'ospiti, a reta sarà cusì:
Verificate 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
<......>Da l'output di u cumandamentu, pò esse vistu chì in EVPN route-type 2, in più di u MAC, avemu avà ancu vede l'indirizzu IP di l'ospite.
Riturnemu à u paràmetru suppress-arp. Questa impostazione hè attivata per ogni VNI separatamente:
interface nve1
member vni 10000
suppress-arpAllora ci hè una certa difficultà:
- Questa funzione richiede spaziu in memoria TCAM. Daraghju un esempiu di impostazione per suppress-arp:
hardware access-list tcam region arp-ether 256Questa configurazione richiederà doppia larghezza. Vale à dì, se stabilisce 256, allora 512 deve esse liberatu in TCAM. L'installazione di TCAM hè fora di u scopu di questu articulu, postu chì a creazione di TCAM dipende solu da u compitu assignatu à voi è pò differisce da una reta à l'altru.
- L'implementazione di suppress-arp deve esse fatta nantu à tutti i switch Leaf. Tuttavia, a cumplessità pò nasce quandu si cunfigurà in coppie Leaf situate in un duminiu VPC. Quandu cambiassi TCAM, a coherenza trà e coppie serà rottu è un node pò esse fora di serviziu. Inoltre, un reboot di u dispositivu pò esse necessariu per applicà l'impostazione di cambiamentu TCAM.
In u risultatu, duvete cunsiderà currettamente s'ellu vale a pena implementà stu paràmetru in una fabbrica di travagliu in a vostra situazione.
Questu cuncludi a prima parte di u ciculu. In a prossima parte, cunsideremu u routing attraversu una fabbrica VxLAN cù a separazione di a rete in diverse VRF.
È avà invitu à tutti , in quale parleraghju in dettu nantu à u corsu. I primi 20 participanti chì si registranu per stu webinar riceveranu un Certificatu di Discount per email in 1-2 ghjorni dopu a trasmissione.
Source: www.habr.com