Ciao, Habr. Continuo il ciclo di articoli sulla tecnologia VxLAN EVPN, che sono stati scritti appositamente per il lancio del corso da OTUS. Oggi esamineremo una parte interessante delle sfide: la routing. Anche se può sembrare banale, nell'ambito del lavoro della rete di fabric, tutto potrebbe non essere così semplice.
Nella parte precedente siamo riusciti a ottenere un dominio di broadcast costituito sopra la rete di fabric su Nexus 9000v. Tuttavia, questo non copre l'intera gamma di sfide che devono essere affrontate all'interno della rete del Data Center. Oggi esamineremo il prossimo compito: la routing tra le reti o tra i VNI.
Ricordo che viene utilizzata la topologia Spine-Leaf:
Per iniziare, esaminiamo come avviene la routing e quali sono le peculiarità.
Per facilitarne la comprensione, semplifichiamo lo schema logico e aggiungiamo un altro VNI 20000 per Host-2. In definitiva, otteniamo:
In questo caso, come si può trasferire il traffico da un Host all'altro?
Ci sono due opzioni:
- Mantenere informazioni su tutti i VNI su tutti gli switch Leaf, in modo che tutta la routing avvenga sul primo Leaf nella rete;
- Utilizzare un VNI L3 appositamente dedicato.
Il primo metodo è semplice e comodo. Poiché è sufficiente inserire tutti i VNI su tutti gli switch Leaf. Tuttavia, inserire diverse centinaia o migliaia di VNI su tutti i Leaf non sembra più un compito semplice. Pertanto, viene applicato molto raramente.
Esaminiamo il secondo metodo, che è più interessante e leggermente più complesso, ma offre maggiore flessibilità nella configurazione della fabric.
Aggiungiamo alla topologia un VRF "PROD". Aggiungeremo l'interfaccia vlan 10 su un paio di Leaf-11/12 e l'interfaccia VLAN 20 su Leaf-21. Associamo VLAN 20 con VNI 20000.
vrf context PROD
rd auto ! Il Route Distinguisher non è cruciale e possiamo utilizzare quello generato automaticamente
address-family ipv4 unicast
route-target both auto ! specifichiamo il Route-target con cui verranno importati ed esportati i prefissi in/da VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayPer utilizzare L3VNI, è necessario creare un nuovo VLAN, associarlo con un nuovo VNI. Il nuovo VNI deve essere lo stesso su tutti i Leaf, interessati alle informazioni sui VLAN 10 e 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Creiamo L3 VNI
vrf context PROD
vni 99000 ! Colleghiamo L3 VNI a un determinato VRFDi conseguenza, lo schema sarà rappresentato in questo modo:
Manca poco da completare — aggiungere un ulteriore interfaccia — interface vlan 99 nel VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Su quest'interfaccia non deve esserci IP. Usata solo per il passaggio dei pacchetti tra LeafIn sintesi, la logica di transito del pacchetto da Host-1 a Host-2 è la seguente:
- Il pacchetto inviato da Host-1 arriva su Leaf nella VLAN 10, associata al VNI 10000;
- Leaf verifica dove si trova l'indirizzo di destinazione e lo trova tramite L3 VNI sul secondo switch Leaf;
- Non appena la rotta per l'indirizzo di destinazione viene trovata, Leaf impacchetta il pacchetto nell'intestazione con il necessario L3VNI 99000 — e lo invia verso il secondo Leaf;
- Il secondo switch Leaf riceve dati da L3VNI 99000. Estrae il pacchetto originale e lo trasferisce nel necessario L2VNI 20000 e poi nella VLAN 20.
Il risultato di un tale lavoro è che L3VNI elimina la necessità di mantenere su tutti gli switch Leaf informazioni su tutti i VNI presenti nella rete.
Quindi, quando inviamo traffico da Host-1 a Host-2, il pacchetto viene impacchettato all'interno di VxLAN con un nuovo VNI — 99000:
Rimane da capire come esattamente Leaf-1 possa conoscere l'indirizzo MAC da un altro VNI. Questo avviene anche tramite EVPN route-type 2 (MAC/IP).
Di seguito è mostrato il processo di diffusione della rotta riguardante il prefisso situato in un altro VNI:
Cioè, gli indirizzi ricevuti dal VNI 20000 hanno due RT.
Ricordo che le rotte ricevute dall'Update vanno nella tabella BGP con Route-target specificato nelle impostazioni del VRF (il processo è un po' più complesso, ma nell'ambito di questo articolo non ci approfondiremo).
Il RT stesso viene formato secondo la formula: AS:VNI (se si utilizza la modalità automatica).
Esempio di formazione del RT in modalità automatica e manuale:
vrf context PROD
address-family ipv4 unicast
route-target import auto - modalità automatica
route-target export 65001:20000 - modalità manuale di formazione del RTDi conseguenza, come si vede sopra, i prefissi di un altro VNI hanno due valori RT.
Uno di essi è 65001:99000 — un L3 VNI aggiuntivo. Poiché questo VNI è identico su tutti i Leaf e rientra nelle nostre regole di import nelle impostazioni del VRF — il prefisso entra nella tabella BGP, come si può vedere dall'output:
sh bgp l2vpn evpn
Rete Prossima Hop Metri LocPrf Peso Percorso
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.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]\/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefisso ottenuto da VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iSe osserviamo più attentamente l'update ricevuto, possiamo vedere che questo prefisso ha due RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Informazioni sulla tabella di routing BGP per VRF default, famiglia di indirizzi L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
Voce della tabella di routing BGP per [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, versione 5164
Percorsi: (2 disponibili, migliore #2)
Flags: (0x000202) (high32 00000000) su xmit-list, non è in l2rib\/evpn, non è in HW
Tipo di percorso: interno, percorso è valido, non migliore motivo: Indirizzo del vicino, nessun nexthop etichettato
AS-Path: NONE, percorso originato internamente all'AS
10.255.1.20 (metrico 81) da 10.255.1.102 (10.255.1.102)
Origine IGP, MED non impostato, localpref 100, peso 0
Etichetta ricevuta 20000 99000 ! Due etichette per il funzionamento di VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Due valori Route-target, sui quali si basa questo prefisso
Router MAC:5001.0005.0007
Originaore: 10.255.1.21 Lista cluster: 10.255.1.102Nella tabella di routing su Leaf-1 si può osservare anche il prefisso 192.168.20.20\/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Indirizzo Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, interno, tag 65001 ! Disponibile tramite Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Tramite VNI 99000Hai notato l'assenza del prefisso principale 192.168.20.0\/24 nella tabella di routing?
Esatto, non c'è. Cioè, i Leaf remoti ricevono informazioni solo sugli host presenti nella tua rete. E questo è un comportamento corretto. Nei precedenti update è evidente che arrivano informazioni riguardanti MAC\/IP. Non si parla di prefissi.
Funziona il protocollo Host Mobility Manager (HMM), che riempie la tabella ARP da cui viene poi popolata la tabella BGP (in questo articolo tralasceremo questo processo). Sulla base delle informazioni ottenute da HMM si formano i tipi di percorso EVPN 2 (viene trasmesso MAC\/IP).
Tuttavia, cosa fare se c'è la necessità di trasmettere informazioni su un prefisso?
Per questo tipo di informazione esiste il tipo di route EVPN 5 — consente di trasmettere prefissi attraverso l'address-family l2vpn evpn (questo tipo di route al momento della stesura dell'articolo è disponibile solo in versione draft , per questo motivo il comportamento di questo tipo di route può differire tra i vari produttori)
Per trasmettere prefissi, è necessario aggiungere i prefissi da annunciare nel processo BGP per VRF:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! In questo caso annunciamo i prefissi connessi direttamente a Leaf nel VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Indichiamo quale prefix-list utilizzare
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Indichiamo quali reti verranno incluse nell'EVPN route-type 5In sintesi, nell'Update sarà:
Esaminiamo la tabella BGP. Oltre ai route-type EVPN 2 e 3, sono comparsi anche i route tipo 5, che contengono informazioni sul numero della rete:
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 con numero prefisso
10.255.1.10 0 100 0 ?
* i Nella tabella di routing è apparso anche il prefisso:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, interno, tag 65001 ! Prefisso remoto, disponibile tramite Leaf1/2 (indirizzo Next-hop = virtual IP tra coppie VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefisso disponibile tramite L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, interno, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmCon questo concludiamo la seconda parte del ciclo di articoli su VxLAN EVPN. Nella prossima parte esamineremo diverse opzioni di routing tra VRF.
Fonte: habr.com
