Ciao, Habr. Continuo il ciclo di articoli sulla tecnologia VxLAN EVPN, che sono stati scritti appositamente per il lancio del corso di OTUS. E oggi esamineremo una parte interessante delle sfide — il routing. Per quanto banale possa sembrare, tuttavia, nel contesto di un fabric di rete, potrebbe non essere così semplice.
Nella parte precedente abbiamo ottenuto un dominio di broadcast, costruito sopra il fabric di rete su Nexus 9000v. Tuttavia, questo non è l'unico aspetto delle sfide che devono essere risolte all'interno della rete del data center. Oggi esamineremo il problema successivo — il routing tra reti o tra VNI.
Ricordo che si utilizza una topologia Spine-Leaf:
Per iniziare, analizziamo come avviene il routing e quali sono le sue particolarità.
Per comprendere meglio, semplifichiamo lo schema logico e aggiungiamo un altro VNI 20000 per Host-2. Alla fine si ottiene:
In questo caso, come è possibile 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 tutto il routing avvenga sul primo Leaf nella rete;
- Utilizzare un VNI L3 appositamente dedicato
Il primo metodo è semplice e comodo, poiché richiede solo di configurare tutti i VNI su tutti gli switch Leaf. Tuttavia, configurare diverse centinaia o migliaia di VNI su tutti i Leaf non sembra più un compito semplice. Pertanto, viene utilizzato piuttosto raramente.
Analizzeremo il secondo metodo, che è più interessante e leggermente più complesso, ma offre maggiore flessibilità nella configurazione della fabbrica.
Aggiungeremo alla topologia il VRF "PROD". In questo inseriremo l'interface vlan 10 su entrambi i Leaf-11/12 e l'interface VLAN 20 su Leaf-21. Assoceremo VLAN 20 con VNI 20000.
vrf context PROD
rd auto ! Il Route Distinguisher non è significativo 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 una nuova VLAN e associarla a un nuovo VNI. Il nuovo VNI deve essere identico su tutti i Leaf interessati dalle informazioni sulle 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 VRF specificoDi conseguenza, lo schema sarà rappresentato così:
Manca poco da completare: aggiungere un altro interfaccia — interface vlan 99 nel VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Non deve esserci un IP sull'interfaccia. Utilizzata solo per il passaggio dei pacchetti tra i LeafIn sintesi, la logica del passaggio del frame da Host-1 a Host-2 è la seguente:
- Il frame inviato da Host-1 arriva al Leaf nella VLAN 10, associata al VNI 10000;
- Il Leaf verifica dove si trova l'indirizzo di destinazione e lo trova tramite L3 VNI sul secondo switch Leaf;
- Una volta trovato il percorso per l'indirizzo di destinazione, il Leaf incapsula il frame nell'intestazione con il necessario L3VNI 99000 — e lo invia verso il secondo Leaf;
- Il secondo switch Leaf riceve i dati dall'L3VNI 99000. Estrae il frame originale e lo trasferisce nel necessario L2VNI 20000 e poi nella VLAN 20.
Il risultato di tale operazione è che l'L3VNI elimina la necessità di mantenere su tutti i Leaf switch informazioni riguardo a tutti i VNI presenti nella rete.
Di conseguenza, quando inviamo traffico da Host-1 a Host-2, il pacchetto viene incapsulato all'interno del VxLAN con il nuovo VNI — 99000:
Rimane da capire come esattamente Leaf-1 apprenda del MAC address da un altro VNI. Questo avviene anche tramite EVPN route-type 2 (MAC/IP).
Di seguito è mostrato il processo di distribuzione del percorso per un prefisso situato in un altro VNI:
Vale a dire, gli indirizzi ricevuti dal VNI 20000 hanno due RT.
Ricordo che i percorsi ottenuti dall'Update entrano nella tabella BGP con il Route-target specificato nelle impostazioni del VRF (il processo è un po' più complesso, ma non ci addentreremo oltre in questo articolo).
L'RT stesso viene formulato secondo la formula: AS:VNI (se è utilizzata la modalità automatica).
Esempio di generazione di RT in modalità automatica e manuale:
vrf context PROD
address-family ipv4 unicast
route-target import auto - modalità automatica operativa
route-target export 65001:20000 - modalità manuale di generazione dell'RTDi conseguenza, risulta evidente che i prefissi provenienti da un altro VNI hanno due valori RT.
Uno di essi è 65001:99000 — un VNI L3 aggiuntivo. Poiché questo VNI è identico su tutti i Leaf e rientra nelle nostre regole di importazione nelle impostazioni del VRF, il prefisso entra nella tabella BGP, come si può vedere dall'output:
sh bgp l2vpn evpn
Rete Prossimo Salto Metrica LocPrf Peso Percorso
Distintore di Rotta: 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
Distintore di Rotta: 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 guardiamo più da vicino 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 la VRF predefinita, 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.2
0]/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 motivazione: Indirizzo vicino, nessun next-hop etichettato
AS-Path: NESSUNO, percorso sorgente interno all'AS
10.255.1.20 (metrica 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 la gestione di VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Due valori Route-target, sulla base dei quali è stato aggiunto questo prefisso
Router MAC:5001.0005.0007
Origina: 10.255.1.21 Lista cluster: 10.255.1.102Nella tabella di routing su Leaf-1 è visibile 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 ! Accessibile 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'è. Questo significa che i Leaf remoti ricevono informazioni solo sui nodi presenti nella vostra rete. E questo è il comportamento corretto. Nelle precedenti aggiornamenti, è evidente che si ricevono informazioni contenenti MAC/IP. Non si parla affatto di prefissi.
Funziona il protocollo Host Mobility Manager (HMM), che riempie la tabella ARP da cui viene successivamente compilata la tabella BGP (in questo articolo ometteremo questo processo). Sulla base delle informazioni ottenute da HMM si formano i percorsi EVPN di tipo 2 (viene trasmesso MAC/IP).
Tuttavia, cosa fare se è necessario trasmettere informazioni su un qualche prefisso?
Per questo tipo di informazione esiste il percorso EVPN di tipo 5 — consente di trasmettere prefissi attraverso l'address-family l2vpn evpn (questo tipo di rotta al momento della stesura dell'articolo si trova solo in versione draft. , per questo motivo il comportamento di questo tipo di rotta può variare tra diversi produttori)
Per trasmettere prefissi, è necessario aggiungere i prefissi nel processo BGP per il VRF, che saranno annunciati:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! In questo caso annunciamo i prefissi connessi direttamente a Leaf in VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Indichiamo quale utilizzare nel prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Indichiamo quali reti saranno incluse nell'EVPN route-type 5Alla fine, nell'Update sarà presente:
Diamo un'occhiata alla tabella BGP. Oltre ai route-type 2 e 3 di EVPN, sono apparsi i percorsi di 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 di prefisso
10.255.1.10 0 100 0 ?
* i Nella tabella di instradamento è comparso 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 = IP virtuale tra la coppia 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, hmmConcludiamo qui la seconda parte del ciclo di articoli su VxLAN EVPN. Nella prossima parte esamineremo diverse opzioni di instradamento tra VRF.
Fonte: habr.com
