In questo post precedente ho mostrato come realizzare segmenti VXLAN su una rete costituita da switch Cisco Nexus, che non utilizza alcun piano di controllo, ma solo un protocollo di routing IP multicast nella IP Fabric. La costruzione delle mappe MAC-to-VTEP avviene in questo caso interamente sul piano dati (VXLAN Flood & Learn), senza ausilio alcuno di un piano di controllo.
In questo post vedremo invece come realizzare segmenti VXLAN utilizzando un piano di controllo, che come visto in vari post di questo blog, è il protocollo EVPN, ampiamente trattato in post precedenti. La rete test è costituita anche in questo caso da switch Cisco Nexus della serie 9000.
NOTA: La lettura di questo post richiede una buona conoscenza del protocollo EVPN e del suo utilizzo come piano di controllo per la realizzazione di segmenti VXLAN. Potete trovare tutti le informazioni necessarie in questo blog, per cui prima di avventuravi nella lettura di questo post vi consiglio un ripasso, a meno che non siate particolarmente ferrati sull'argomento.
TOPOLOGIA DELLA RETE TEST
Questo lab test è basato su una rete test la cui topologia è riportata nella figura seguente. La topologia è una classica topologia di tipo Leaf-and-Spine, con due Spine (gli switch SP-1 e SP-2) e tre Leaf (Leaf-1, Leaf-2 e Leaf-3).
I Leaf di questo Lab test sono switch multilayer fisici che svolgono il ruolo di switch ToR (Top of Rack). Gli Spine sono invece configurati come classici router, e di norma non hanno bisogno di alcunché che riguarda le VXLAN, se non del routing IP classico e del supporto dell’address-family BGP L2VPN EVPN (AFI/SAFI = 25/70). Agli switch Spine è stata inoltre assegnata la funzione di BGP Route Reflector e di Rendezvous-Point per il traffico multicast.
NOTA: benché la maggior parte del traffico BUM nel modello VXLAN+EVPN viene di molto mitigata dal meccanismo dell'ARP Suppression, non bisogna cadere nell'errore di pensare che il traffico BUM venga eliminato completamente. Per cui, anche in presenza di un piano di controllo, il routing multicast (oppure Head-End Replication) è comunque necessario.
Poiché gli apparati a disposizione non supportavano le nuove funzionalità di EVPN multihoming, per gestire un caso di multihoming abbiamo utilizzato la funzionalità virtual Port Channel (vPC) supportata dagli switch Nexus, creando un vPC domain tra gli switch Leaf-2 e Leaf-3.
Il tenant ha le sue applicazioni suddivise su tre diversi segmenti VXLAN, identificati dai valori di VNI 10000 (Host S-10-1, S-10-23 e S-10-3), 20000 (Host S-40-1, S-20-2 e S-20-23) e 50000 (Host S-50-2). Gli Host S-X-Y appartengono alla VLAN X. Oltre alla realizzazione dei tre segmenti VXLAN, è richiesto l’inter-VXLAN routing tra questi.
La rete underlay utilizza gli stessi identici protocolli del post precedente. Come protocollo di routing unicast OSPF in area singola (= 0), e come protocollo di routing multicast PIM-BiDir, utilizzando come metodo (standard) di selezione del Rendezvous-Point il semplice Phantom-RP.
La figura riporta, oltre alla topologia della rete, anche gli indirizzi IP delle interfacce di Loopback utilizzate. In particolare, si noti che come indirizzi per le VTEP sono utilizzati gli indirizzi delle Loopback54. Ulteriori dettagli nel seguito.
NOTA IMPORTANTE: l’Host S-40-1, benché associato alla VLAN 40, è parte dello stesso segmento VXLAN 20000 degli Host S-20-2 e S-20-23. Questo è possibile poiché l’associazione VLAN↔VNI è locale allo switch Leaf, e quindi è possibile localmente associare un diverso valore di VLAN-ID a Host appartenenti allo stesso segmento VXLAN. Quello che conta è il valore di VNI assegnato, che invece deve essere globale.
CONFIGURAZIONI DELLA RETE UNDERLAY
Le configurazioni da eseguire per la rete underlay sono identiche a quelle già viste nel post precedente, per cui non verranno ripetute.
Sugli switch Spine è sufficiente abilitare le prime quattro, essendo questi totalmente agnostici rispetto ai segmenti VXLAN (ricordo che gli switch Spine hanno il solo scopo di instradare traffico IP, e niente che riguardi la funzione VTEP, svolta solamente dagli switch Leaf). Sugli switch Spine, l'unica configurazione che riguarda in qualche modo la realizzazione dei segmenti VXLAN è l'abilitazione delle sessioni BGP EVPN (da qui la necessità della feature "nv overlay evpn").
RETI OVERLAY: CONFIGURAZIONE DELLE SESSIONI BGP EVPN
La configurazione delle sessioni BGP EVPN segue le linee classiche della configurazione del BGP nell'NX-OS, che è molto simile, ma non identica alle configurazioni in ambiente IOS/IOS-XE. L'aspetto chiave è l'attivazione dell'address-family BGP L2VPN EVPN (AFI/SAFI = 25/70). Nella rete test, come sovente accade nelle applicazioni pratiche, ho assegnato agli switch Spine la funzione di Route Reflection.
La configurazione del BGP negli switch Leaf è la seguente:
router bgp 65001
router-id 192.168.0.X ! X = 1, 2, 3
address-family l2vpn evpn
template peer TO-RR
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community extended
neighbor 192.168.1.1
inherit peer TO-RR
description *** SESSIONE CON SP-1 (RR) ***
neighbor 192.168.1.2
inherit peer TO-RR
description *** SESSIONE CON SP-2 (RR) ***
dove per maggiore eleganza di configurazione ho utilizzato il meccanismo dei BGP Peer template. Come si può notare, la configurazione è abbastanza classica, l’unica nota importante da sottolineare è l’abilitazione dell’address family L2VPN EVPN. Inoltre, è necessaria l’abilitazione all’invio delle Extended Community BGP, per il trasporto dei Route Target, di cui vedremo nel seguito l'utilizzo.
Sugli switch Spine la configurazione è la seguente:
router bgp 65001
router-id 192.168.1.X ! X = 1, 2
address-family l2vpn evpn
template peer RR-CLIENT
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community extended
route-reflector-client
neighbor 192.168.0.1
inherit peer RR-CLIENT
description *** Leaf-1 ***
neighbor 192.168.0.2
inherit peer RR-CLIENT
description *** Leaf-2 ***
neighbor 192.168.0.3
inherit peer RR-CLIENT
description *** Leaf-3 ***
Una volta eseguite le configurazioni sugli switch Leaf e Spine, le sessioni raggiungono lo stato Established, come mostrato dall’esecuzione del comando "show bgp l2vpn evpn summary" (nell’esempio seguente, eseguito sullo switch Leaf-1):
CONFIGURAZIONE DELLE ASSOCIAZIONI VLAN → VNI E DELL'INTERFACCIA VTEP
Riporto ora le configurazioni di altri due passi fondamentali, da eseguire solo ed esclusivamente negli degli switch Leaf:
vlan 10
vn-segment 10000
vlan 40
vn-segment 20000
vlan 1020
vn-segment 31020
Si noti che rispetto al caso già trattato del modello di VXLAN Flood&Learn, su ciascun switch Leaf è configurata una associazione in più: <VLAN 1020 → VNI 31020>. Il valore di VLAN 1020 è un valore fittizio, non utilizzato nell’incapsulamento dei pacchetti VXLAN, né nelle trame Ethernet. Il valore di VNI = 31020 è invece il valore utilizzato nell’inter-VXLAN routing simmetrico (L3VNI).
Il secondo passo è la configurazione dell’interfaccia VTEP. Per questo è necessario specificare l’indirizzo IP della VTEP, in questo esempio assunto identico a quello dell’interfaccia Loopback54, e l’associazione tra i valori di VNI e dei gruppi multicast. Inoltre è necessario specificare che il MAC learning avviene via BGP (comando "host-reachability protocol bgp", senza di questo il MAC learning avverrebbe solo utilizzando il protocollo di routing multicast). Altro aspetto importante nella configurazione dell’interfaccia "nve1", è l’associazione del L3VNI (= 31020) a una VRF (comando "member vni 31020 associate-vrf"). Infine, ma questo è in realtà opzionale, è possibile (e conveniente) abilitare la funzionalità di ARP Suppression con il comando "member vni ... suppress-arp". Riporto per semplicità la configurazione sullo switch Leaf-1:
interface nve1
host-reachability protocol bgp
source-interface loopback54
member vni 10000
suppress-arp
mcast-group 239.1.10.1
member vni 20000
suppress-arp
mcast-group 239.1.20.1
member vni 31020 associate-vrf
NOTA: qualora si volesse utilizzare per il traffico multi-destinazione Head-End Replication in luogo del routing multicast, la configurazione alternativa da utilizzare è la seguente:
CONFIGURAZIONE DELLA VRF DEL TENANT E DELL'INDIRIZZO AGM
Nel caso si volesse abilitare l’inter-VXLAN routing tra le (tre) subnet IP del tenant, è necessario creare una VRF, alla quale saranno associate (vedi prossima sezione), le VLAN del tenant e la VLAN fittizia utilizzata per l’inter-VXLAN routing. Questa è la configurazione della VRF denominata TENANT-TT, su Leaf-1:
vrf context TENANT-TT
vni 31020
rd auto
address-family ipv4 unicast
route-target both auto
route-target both auto evpn
Nella configurazione della VRF il primo parametro da definire è il valore di VNI utilizzato per l’inter-VXLAN routing (di tipo simmetrico, che è la sola modalità supportata dall’NX-OS). Questo valore di VNI, proprio perché viene utilizzato esclusivamente per il routing di Livello 3, viene denominato L3VNI, e così compare nelle visualizzazioni prodotte dai vari comandi "show …".
La VRF avrà, come le classiche VRF utilizzate nei servizi L3VPN, un Route Distiguisher (RD), e uno o più Route Target (RT), import e/o export. Per semplificare le configurazioni, l’NX-OS consente la determinazione automatica di entrambi questi parametri. Per quanto riguarda il RD, questo viene determinato come BGP-RID:VRF-ID, dove il VRF-ID è un valore interno assegnato dall’NX-OS a ciascuna VRF, e che può essere visualizzato con il comando "show vrf". Ad esempio, per la VRF TENANT-TT configurata su Leaf-1, il valore di RD assegnato sarà 192.168.0.1:1, dove 192.168.0.1 è il valore del BGP-RID, e 3 è il valore del VRF-ID, che si evince dalla seguente visualizzazione:
Ai RT vengono invece assegnati automaticamente i valori Numero-AS:L3VNI. Ad esempio, sempre nel caso della VRF TENANT-TT configurata su Leaf-1, ad entrambi i RT import ed export vengono assegnati i valori 65001:31020, dove 65001 è il numero di AS del Data Center e 31020 è il valore del L3VNI configurato all’interno della VRF TENANT-TT. Si noti che i valori di RT dove non compare nel comando di configurazione la clausola "evpn", sono utilizzati per i soli annunci BGP EVPN di tipo 5.
La configurazione della VRF va completata all’interno del processo BGP, abilitando tramite il comando "advertise l2vpn evpn", gli annunci BGP EVPN.
router bgp 65001
vrf TENANT-TT
address-family ipv4 unicast
advertise l2vpn evpn
Altro aspetto importante nella configurazione dell’inter-VXLAN routing, è la definizione dell’Anycast Gateway MAC address (AGM). L’NX-OS consente la sua configurazione tramite il comando seguente, eseguito in modalità globale:
fabric forwarding anycast-gateway-mac 0000.0003.1020
Si noti che l’indirizzo AGM è univoco per tutte le VRF e come best practice va configurato identico su tutti gli switch Leaf.
ASSOCIAZIONE DELLE INTERFACCE IRB ALLA VRF
Una volta creata la VRF del tenant, è necessario istruire gli switch Leaf tra quali subnet IP del tenant deve fare inter-VXLAN routing. A tale scopo è sufficiente associare le rispettive «interfacce VLAN» (chiamate spesso interfacce IRB, Integrated Routing and Bridging) alla VRF del tenant.
Di seguito le configurazioni su Leaf-1. Si noti che gli indirizzi IP delle interfacce VLAN 10 e 40, sono gli indirizzi dei default gateway configurati negli Host.
interface Vlan10
vrf member TENANT-TT
ip address 10.0.10.254/24 tag 123
fabric forwarding mode anycast-gateway
!
interface Vlan40
vrf member TENANT-TT
ip address 10.0.20.254/24 tag 123
fabric forwarding mode anycast-gateway
!
interface Vlan1020
vrf member TENANT-TT
ip forward
route-map RD
match tag 123
!
router bgp 65001
vrf TENANT-TT
address-family ipv4 unicast
redistribute direct route-map RD
Tra le interfacce VLAN, anche quella fittizia necessaria per l’inter-VXLAN routing va associata alla VRF del tenant (nella figura la VLAN 1020). Si noti che questa interfaccia non ha un indirizzo IP, e quindi secondo le regole dei router Cisco, non è in grado di inoltrare traffico. Per ovviare a questo problema, è necessario configurare all’interno dell’interfaccia il comando "ip forward", che consente comunque all’interfaccia di inoltrare traffico anche se non ha alcun indirizzo IP assegnato. Faccio notare che senza questo comando l’inter-VXLAN routing non funziona ! Lo sottolineo perché ho visto in giro delle configurazioni che "dimenticano" questo comando, e vi posso garantire che è un errore di configurazione.
La redistribuzione delle network direttamente connesse non è strettamente necessaria ma consigliata. Consente infatti il routing verso un Host «silente», di cui il Leaf non conosce ancora l’indirizzo IP. Ad esempio, nell’ipotesi che un Host attestato a Leaf-1 voglia inviare traffico a un Host remoto di un altro segmento VXLAN, che ancora non ha avuto modo di annunciare il suo indirizzo IP (Host «silente»), senza la redistribuzione, e quindi senza la presenza nella tabella di routing associata alla VRF della subnet IP che contiene l’indirizzo dell’Host destinazione, il pacchetto IP verrebbe scartato da Leaf-1. Con la presenza della redistribuzione, Leaf-1 apprende attraverso un annuncio BGP EVPN di tipo 5, il prefisso della subnet IP che contiene l’indirizzo dell’Host destinazione.
Qui bisogna distinguere due casi. Nel primo, Leaf-1 potrebbe avere il prefisso IP già direttamente connesso se Leaf-1 avesse almeno un Host dello stesso segmento VXLAN. In questo caso, nella tabella di routing associata alla VRF finirebbe il prefisso direttamente connesso (e non quello annunciato via BGP EVPN, che ha Distanza Amministrativa maggiore !). Questo fa si che quando un Host di Leaf-1 invia un pacchetto IP all’Host silente, verrà eseguito un lookup sulla tabella di routing associata alla VRF, che ha però il prefisso della subnet IP che lo contiene, prefisso che punta nella tabella di forwarding (tabella CEF), a una glean adjacency. Questo implica che verrà generato un messaggio ARP Request per cercare il MAC corrispondente all’indirizzo IP destinazione. L’Host fino a quel momento silente risponderà con un ARP reply e da qui in poi tutto procede come ampiamente spiegato in precedenza.
Il secondo caso si ha quando Leaf-1 non ha alcun Host della subnet IP destinazione. In questo caso nella tabella di routing vi sarà comunque la subnet IP destinazione, annunciata via BGP EVPN di tipo 5, da un qualche Leaf che ha almeno un Host della subnet IP destinazione. Il pacchetto VXLAN verrà quindi indirizzato verso questo Leaf, che avrà nella tabella di routing associata alla VRF la subnet IP direttamente connessa, che punta a una glean adjacency della tabella di forwarding. A questo punto tutto procede come prima.
CONFIGURAZIONE DELLE EVI
L’aspetto finale della configurazione degli switch Leaf consiste nella determinazione delle EVPN Instance (EVI).
All’interno della definizione di una EVI è necessario definire il VNI, il Route Distinguisher (RD) e i Route Target (RT) import/export. A parte il valore di RD, è bene notare che gli altri parametri, VNI e RT, devono necessariamente coincidere su tutte le EVI dello stesso tenant, configurate negli altri switch Leaf. E inoltre devono essere diversi da EVI a EVI.
Poiché al crescere del numero di EVI, tenere in mente tutti questi parametri e quindi evitare errori di configurazione, potrebbe essere un problema di non poco conto, l’NX-OS da la possibilità di determinarli automaticamente, come mostrato nella configurazione seguente (relativa allo switch Leaf-1). E questa è la best practice consigliata, che ben si presta tra l’altro all’automazione delle configurazioni.
evpn
vni 10000 l2
rd auto
route-target import auto
route-target export auto
vni 20000 l2
rd auto
route-target import auto
route-target export auto
Il valore di RD automatico viene definito come: RD = BGP-RID : (32767 + VLAN-ID). Ad esempio, per il Leaf-1, le configurazioni riportate nella diapositiva implicano che per il segmento VXLAN con VNI = 10000, corrispondente al segmento VLAN 10, RD = 192.168.0.1:32777. Allo stesso modo, per il segmento VXLAN con VNI = 20000, corrispondente al segmento VLAN 20, RD = 192.168.0.1:32787.
I valori di RT import ed export sono invece definiti con il valore comune ASN:VNI, dove ASN è il numero di Autonomous System a cui appartiene lo switch Leaf. Ad esempio, per lo switch Leaf-1, le configurazioni riportate sopra implicano che per il segmento VXLAN con VNI = 10000, RT import = RT export = 65001:10000, mentre per il segmento VXLAN con VNI = 20000, RT import = RT export = 65001:20000.
CONFIGURAZIONE DEL vPC DOMAIN
Poiché gli switch della rete di laboratorio che sto utilizzando non supportano le funzionalità EVPN multihoming, per realizzare un collegamento multi-homed ho utilizzato la classica funzionalità di virtual Port Channel (vPC) proprietaria Cisco. A differenza della funzionalità EVPN multihoming, il vPC può essere realizzato tra due soli switch, e inoltre richiede almeno due collegamenti diretti tra gli switch, non richiesti invece dalla funzionalità EVPN multihoming.
I due collegamenti inter-switch servono a creare il primo il vPC peer-keepalive link e il secondo il vPC peer-link. Le best practice per questo tipo di funzionalità, alle quali mi sono attenuto, consigliano di utilizzare per il vPC peer-keepalive link un collegamento punto-punto realizzato utilizzando l'interfaccia di management ("mgmt 0" nel nostro esempio) e per il vPC peer-link almeno due link in port channel.
La figura seguente riporta lo schema di collegamenti utilizzati e le relative configurazioni di base.
Lo switch L2 SW-23, collegato un dual-homing agli switch Leaf-2 e Leaf-3 sulle interfacce E1/8, necessita delle sole configurazioni di un classico port channel. In realtà, lo switch SW-23 è totalmente ignaro che i suoi collegamenti terminano su switch diversi, logicamente vede i due collegamenti come attestati a un singolo switch logico.
Un aspetto importante da notare è la presenza all'interno della configurazione dell'interfaccia Loopback54 di un indirizzo secondario (= 192.168.23). Questo indirizzo, denominato Virtual IP (VIP), è l'indirizzo utilizzato come BGP Next-Hop dagli annunci BGP EVPN originati dagli switch Leaf-2 e Leaf-3. Da un punto di vista logico è come se i due switch Leaf formassero un unico switch Leaf virtuale, che utilizza l'indirizzo VIP come BGP Next-Hop per gli annunci BGP EVPN.
La configurazione riportata nella figura andrebbe, sempre come best practice, corredata con l’attivazione di collegamento Layer 3 inter-Leaf. Questo per fare in modo che se uno dei due switch Leaf del vPC domain dovesse perdere la connettività con entrambi gli switch Spine (evento assai raro per la verità), ci sarebbe una via alternativa tra le interfacce di Loopback utilizzate per le sessioni iBGP tra lo switch Leaf e i Route Reflector, evitando in tal modo la perdita delle sessioni stesse. Il collegamento Layer 3 inter-Leaf è utile anche nel caso in cui uno dei due switch Leaf perdesse la connettività con entrambi gli switch Spine e vi sia perdita di connettività tra lo switch multi-homed e l'altro switch Leaf (ossia, tre link down contemporaneamente, è vero che alla sfortuna non c'è limite, ma mi sembra proprio un caso limite !).
Solo per completezza, riporto la configurazione su Leaf-2 di questo collegamento Layer 3 inter-switch (NOTA: la configurazione su Leaf-3 è identica, a parte ovviamente l’indirizzo IP che sarà 172.16.23.3/31):
interface Vlan23
description *** INTERFACCIA LAYER 3 PEER-LINK ***
ip address 172.16.23.2/31
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
ip pim sparse-mode
Con questo ho terminato la prima parte di questo post. Nella seconda parte illustrerò la verifica del funzionamento del piano di controllo e del piano dati. E vi metterò a disposizione anche le configurazioni degli switch del test, che potrete utilizzare per replicarlo.
CONFIGURAZIONI DELLA RETE UNDERLAY
Le configurazioni da eseguire per la rete underlay sono identiche a quelle già viste nel post precedente, per cui non verranno ripetute.
NOTA: poiché il sistema operativo NX-OS utilizzato dai Cisco Nexus è di tipo modulare, affinché i comandi possono essere eseguiti è necessario attivare delle feature. In particolare, in questo test di laboratorio, ho utilizzato sugli switch Leaf le seguenti feature:
- feature ospf: abilita l'esecuzione del protocollo OSPF;
- feature pim: abilita l'esecuzione del protocollo PIM;
- nv overlay evpn: serve ad abilitare la realizzazione di segmenti VXLAN con piano di controllo EVPN;
- feature bgp: serve ad abilitare la configurazione del protocollo BGP;
- feature interface-vlan: abilita la possibilità di creare interfacce SVI;
- feature vn-segment-vlan-based; abilita la possibilità di creare associazioni VLAN-VXLAN;
- feature nv overlay: abilita il piano dati VXLAN;
- feature fabric forwarding: serve ad abilitare l’Host Mobility Manager (HMM).
RETI OVERLAY: CONFIGURAZIONE DELLE SESSIONI BGP EVPN
La configurazione delle sessioni BGP EVPN segue le linee classiche della configurazione del BGP nell'NX-OS, che è molto simile, ma non identica alle configurazioni in ambiente IOS/IOS-XE. L'aspetto chiave è l'attivazione dell'address-family BGP L2VPN EVPN (AFI/SAFI = 25/70). Nella rete test, come sovente accade nelle applicazioni pratiche, ho assegnato agli switch Spine la funzione di Route Reflection.
La configurazione del BGP negli switch Leaf è la seguente:
router bgp 65001
router-id 192.168.0.X ! X = 1, 2, 3
address-family l2vpn evpn
template peer TO-RR
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community extended
neighbor 192.168.1.1
inherit peer TO-RR
description *** SESSIONE CON SP-1 (RR) ***
neighbor 192.168.1.2
inherit peer TO-RR
description *** SESSIONE CON SP-2 (RR) ***
dove per maggiore eleganza di configurazione ho utilizzato il meccanismo dei BGP Peer template. Come si può notare, la configurazione è abbastanza classica, l’unica nota importante da sottolineare è l’abilitazione dell’address family L2VPN EVPN. Inoltre, è necessaria l’abilitazione all’invio delle Extended Community BGP, per il trasporto dei Route Target, di cui vedremo nel seguito l'utilizzo.
Sugli switch Spine la configurazione è la seguente:
router bgp 65001
router-id 192.168.1.X ! X = 1, 2
address-family l2vpn evpn
template peer RR-CLIENT
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community extended
route-reflector-client
neighbor 192.168.0.1
inherit peer RR-CLIENT
description *** Leaf-1 ***
neighbor 192.168.0.2
inherit peer RR-CLIENT
description *** Leaf-2 ***
neighbor 192.168.0.3
inherit peer RR-CLIENT
description *** Leaf-3 ***
Una volta eseguite le configurazioni sugli switch Leaf e Spine, le sessioni raggiungono lo stato Established, come mostrato dall’esecuzione del comando "show bgp l2vpn evpn summary" (nell’esempio seguente, eseguito sullo switch Leaf-1):
Leaf-1# show bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 192.168.0.1, local AS number 65001
BGP table version is 38, L2VPN EVPN config peers 2, capable peers 2
16 network entries and 25 paths using 4040 bytes of memory
BGP attribute entries [18/2880], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [4/16]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.1.1 4 65001 26 13 38 0 0 00:06:47 7
192.168.1.2 4 65001 18 11 38 0 0 00:06:40 7
CONFIGURAZIONE DELLE ASSOCIAZIONI VLAN → VNI E DELL'INTERFACCIA VTEP
Riporto ora le configurazioni di altri due passi fondamentali, da eseguire solo ed esclusivamente negli degli switch Leaf:
- Definizione delle associazioni VLAN → VNI;
- Configurazione dell’interfaccia VTEP ("nve").
vlan 10
vn-segment 10000
vlan 40
vn-segment 20000
vlan 1020
vn-segment 31020
Si noti che rispetto al caso già trattato del modello di VXLAN Flood&Learn, su ciascun switch Leaf è configurata una associazione in più: <VLAN 1020 → VNI 31020>. Il valore di VLAN 1020 è un valore fittizio, non utilizzato nell’incapsulamento dei pacchetti VXLAN, né nelle trame Ethernet. Il valore di VNI = 31020 è invece il valore utilizzato nell’inter-VXLAN routing simmetrico (L3VNI).
Il secondo passo è la configurazione dell’interfaccia VTEP. Per questo è necessario specificare l’indirizzo IP della VTEP, in questo esempio assunto identico a quello dell’interfaccia Loopback54, e l’associazione tra i valori di VNI e dei gruppi multicast. Inoltre è necessario specificare che il MAC learning avviene via BGP (comando "host-reachability protocol bgp", senza di questo il MAC learning avverrebbe solo utilizzando il protocollo di routing multicast). Altro aspetto importante nella configurazione dell’interfaccia "nve1", è l’associazione del L3VNI (= 31020) a una VRF (comando "member vni 31020 associate-vrf"). Infine, ma questo è in realtà opzionale, è possibile (e conveniente) abilitare la funzionalità di ARP Suppression con il comando "member vni ... suppress-arp". Riporto per semplicità la configurazione sullo switch Leaf-1:
interface nve1
host-reachability protocol bgp
source-interface loopback54
member vni 10000
suppress-arp
mcast-group 239.1.10.1
member vni 20000
suppress-arp
mcast-group 239.1.20.1
member vni 31020 associate-vrf
NOTA: qualora si volesse utilizzare per il traffico multi-destinazione Head-End Replication in luogo del routing multicast, la configurazione alternativa da utilizzare è la seguente:
interface nve1
host-reachability protocol bgp
source-interface loopback54
member vni 10000
suppress-arp
ingress-replication protocol bgp
member vni 20000
suppress-arp
ingress-replication protocol bgp
member vni 31020 associate-vrf
member vni 31020 associate-vrf
CONFIGURAZIONE DELLA VRF DEL TENANT E DELL'INDIRIZZO AGM
Nel caso si volesse abilitare l’inter-VXLAN routing tra le (tre) subnet IP del tenant, è necessario creare una VRF, alla quale saranno associate (vedi prossima sezione), le VLAN del tenant e la VLAN fittizia utilizzata per l’inter-VXLAN routing. Questa è la configurazione della VRF denominata TENANT-TT, su Leaf-1:
vrf context TENANT-TT
vni 31020
rd auto
address-family ipv4 unicast
route-target both auto
route-target both auto evpn
Nella configurazione della VRF il primo parametro da definire è il valore di VNI utilizzato per l’inter-VXLAN routing (di tipo simmetrico, che è la sola modalità supportata dall’NX-OS). Questo valore di VNI, proprio perché viene utilizzato esclusivamente per il routing di Livello 3, viene denominato L3VNI, e così compare nelle visualizzazioni prodotte dai vari comandi "show …".
La VRF avrà, come le classiche VRF utilizzate nei servizi L3VPN, un Route Distiguisher (RD), e uno o più Route Target (RT), import e/o export. Per semplificare le configurazioni, l’NX-OS consente la determinazione automatica di entrambi questi parametri. Per quanto riguarda il RD, questo viene determinato come BGP-RID:VRF-ID, dove il VRF-ID è un valore interno assegnato dall’NX-OS a ciascuna VRF, e che può essere visualizzato con il comando "show vrf". Ad esempio, per la VRF TENANT-TT configurata su Leaf-1, il valore di RD assegnato sarà 192.168.0.1:1, dove 192.168.0.1 è il valore del BGP-RID, e 3 è il valore del VRF-ID, che si evince dalla seguente visualizzazione:
Leaf-1# show vrf
VRF-Name VRF-ID State Reason
TENANT-TT 3 Up --
default 1 Up --
management 2 Up --
Ai RT vengono invece assegnati automaticamente i valori Numero-AS:L3VNI. Ad esempio, sempre nel caso della VRF TENANT-TT configurata su Leaf-1, ad entrambi i RT import ed export vengono assegnati i valori 65001:31020, dove 65001 è il numero di AS del Data Center e 31020 è il valore del L3VNI configurato all’interno della VRF TENANT-TT. Si noti che i valori di RT dove non compare nel comando di configurazione la clausola "evpn", sono utilizzati per i soli annunci BGP EVPN di tipo 5.
La configurazione della VRF va completata all’interno del processo BGP, abilitando tramite il comando "advertise l2vpn evpn", gli annunci BGP EVPN.
router bgp 65001
vrf TENANT-TT
address-family ipv4 unicast
advertise l2vpn evpn
Altro aspetto importante nella configurazione dell’inter-VXLAN routing, è la definizione dell’Anycast Gateway MAC address (AGM). L’NX-OS consente la sua configurazione tramite il comando seguente, eseguito in modalità globale:
fabric forwarding anycast-gateway-mac 0000.0003.1020
Si noti che l’indirizzo AGM è univoco per tutte le VRF e come best practice va configurato identico su tutti gli switch Leaf.
ASSOCIAZIONE DELLE INTERFACCE IRB ALLA VRF
Una volta creata la VRF del tenant, è necessario istruire gli switch Leaf tra quali subnet IP del tenant deve fare inter-VXLAN routing. A tale scopo è sufficiente associare le rispettive «interfacce VLAN» (chiamate spesso interfacce IRB, Integrated Routing and Bridging) alla VRF del tenant.
Di seguito le configurazioni su Leaf-1. Si noti che gli indirizzi IP delle interfacce VLAN 10 e 40, sono gli indirizzi dei default gateway configurati negli Host.
interface Vlan10
vrf member TENANT-TT
ip address 10.0.10.254/24 tag 123
fabric forwarding mode anycast-gateway
!
interface Vlan40
vrf member TENANT-TT
ip address 10.0.20.254/24 tag 123
fabric forwarding mode anycast-gateway
!
interface Vlan1020
vrf member TENANT-TT
ip forward
route-map RD
match tag 123
!
router bgp 65001
vrf TENANT-TT
address-family ipv4 unicast
redistribute direct route-map RD
Tra le interfacce VLAN, anche quella fittizia necessaria per l’inter-VXLAN routing va associata alla VRF del tenant (nella figura la VLAN 1020). Si noti che questa interfaccia non ha un indirizzo IP, e quindi secondo le regole dei router Cisco, non è in grado di inoltrare traffico. Per ovviare a questo problema, è necessario configurare all’interno dell’interfaccia il comando "ip forward", che consente comunque all’interfaccia di inoltrare traffico anche se non ha alcun indirizzo IP assegnato. Faccio notare che senza questo comando l’inter-VXLAN routing non funziona ! Lo sottolineo perché ho visto in giro delle configurazioni che "dimenticano" questo comando, e vi posso garantire che è un errore di configurazione.
La redistribuzione delle network direttamente connesse non è strettamente necessaria ma consigliata. Consente infatti il routing verso un Host «silente», di cui il Leaf non conosce ancora l’indirizzo IP. Ad esempio, nell’ipotesi che un Host attestato a Leaf-1 voglia inviare traffico a un Host remoto di un altro segmento VXLAN, che ancora non ha avuto modo di annunciare il suo indirizzo IP (Host «silente»), senza la redistribuzione, e quindi senza la presenza nella tabella di routing associata alla VRF della subnet IP che contiene l’indirizzo dell’Host destinazione, il pacchetto IP verrebbe scartato da Leaf-1. Con la presenza della redistribuzione, Leaf-1 apprende attraverso un annuncio BGP EVPN di tipo 5, il prefisso della subnet IP che contiene l’indirizzo dell’Host destinazione.
Qui bisogna distinguere due casi. Nel primo, Leaf-1 potrebbe avere il prefisso IP già direttamente connesso se Leaf-1 avesse almeno un Host dello stesso segmento VXLAN. In questo caso, nella tabella di routing associata alla VRF finirebbe il prefisso direttamente connesso (e non quello annunciato via BGP EVPN, che ha Distanza Amministrativa maggiore !). Questo fa si che quando un Host di Leaf-1 invia un pacchetto IP all’Host silente, verrà eseguito un lookup sulla tabella di routing associata alla VRF, che ha però il prefisso della subnet IP che lo contiene, prefisso che punta nella tabella di forwarding (tabella CEF), a una glean adjacency. Questo implica che verrà generato un messaggio ARP Request per cercare il MAC corrispondente all’indirizzo IP destinazione. L’Host fino a quel momento silente risponderà con un ARP reply e da qui in poi tutto procede come ampiamente spiegato in precedenza.
Il secondo caso si ha quando Leaf-1 non ha alcun Host della subnet IP destinazione. In questo caso nella tabella di routing vi sarà comunque la subnet IP destinazione, annunciata via BGP EVPN di tipo 5, da un qualche Leaf che ha almeno un Host della subnet IP destinazione. Il pacchetto VXLAN verrà quindi indirizzato verso questo Leaf, che avrà nella tabella di routing associata alla VRF la subnet IP direttamente connessa, che punta a una glean adjacency della tabella di forwarding. A questo punto tutto procede come prima.
CONFIGURAZIONE DELLE EVI
L’aspetto finale della configurazione degli switch Leaf consiste nella determinazione delle EVPN Instance (EVI).
All’interno della definizione di una EVI è necessario definire il VNI, il Route Distinguisher (RD) e i Route Target (RT) import/export. A parte il valore di RD, è bene notare che gli altri parametri, VNI e RT, devono necessariamente coincidere su tutte le EVI dello stesso tenant, configurate negli altri switch Leaf. E inoltre devono essere diversi da EVI a EVI.
Poiché al crescere del numero di EVI, tenere in mente tutti questi parametri e quindi evitare errori di configurazione, potrebbe essere un problema di non poco conto, l’NX-OS da la possibilità di determinarli automaticamente, come mostrato nella configurazione seguente (relativa allo switch Leaf-1). E questa è la best practice consigliata, che ben si presta tra l’altro all’automazione delle configurazioni.
evpn
vni 10000 l2
rd auto
route-target import auto
route-target export auto
vni 20000 l2
rd auto
route-target import auto
route-target export auto
I valori di RT import ed export sono invece definiti con il valore comune ASN:VNI, dove ASN è il numero di Autonomous System a cui appartiene lo switch Leaf. Ad esempio, per lo switch Leaf-1, le configurazioni riportate sopra implicano che per il segmento VXLAN con VNI = 10000, RT import = RT export = 65001:10000, mentre per il segmento VXLAN con VNI = 20000, RT import = RT export = 65001:20000.
CONFIGURAZIONE DEL vPC DOMAIN
Poiché gli switch della rete di laboratorio che sto utilizzando non supportano le funzionalità EVPN multihoming, per realizzare un collegamento multi-homed ho utilizzato la classica funzionalità di virtual Port Channel (vPC) proprietaria Cisco. A differenza della funzionalità EVPN multihoming, il vPC può essere realizzato tra due soli switch, e inoltre richiede almeno due collegamenti diretti tra gli switch, non richiesti invece dalla funzionalità EVPN multihoming.
I due collegamenti inter-switch servono a creare il primo il vPC peer-keepalive link e il secondo il vPC peer-link. Le best practice per questo tipo di funzionalità, alle quali mi sono attenuto, consigliano di utilizzare per il vPC peer-keepalive link un collegamento punto-punto realizzato utilizzando l'interfaccia di management ("mgmt 0" nel nostro esempio) e per il vPC peer-link almeno due link in port channel.
La figura seguente riporta lo schema di collegamenti utilizzati e le relative configurazioni di base.
Un aspetto importante da notare è la presenza all'interno della configurazione dell'interfaccia Loopback54 di un indirizzo secondario (= 192.168.23). Questo indirizzo, denominato Virtual IP (VIP), è l'indirizzo utilizzato come BGP Next-Hop dagli annunci BGP EVPN originati dagli switch Leaf-2 e Leaf-3. Da un punto di vista logico è come se i due switch Leaf formassero un unico switch Leaf virtuale, che utilizza l'indirizzo VIP come BGP Next-Hop per gli annunci BGP EVPN.
La configurazione riportata nella figura andrebbe, sempre come best practice, corredata con l’attivazione di collegamento Layer 3 inter-Leaf. Questo per fare in modo che se uno dei due switch Leaf del vPC domain dovesse perdere la connettività con entrambi gli switch Spine (evento assai raro per la verità), ci sarebbe una via alternativa tra le interfacce di Loopback utilizzate per le sessioni iBGP tra lo switch Leaf e i Route Reflector, evitando in tal modo la perdita delle sessioni stesse. Il collegamento Layer 3 inter-Leaf è utile anche nel caso in cui uno dei due switch Leaf perdesse la connettività con entrambi gli switch Spine e vi sia perdita di connettività tra lo switch multi-homed e l'altro switch Leaf (ossia, tre link down contemporaneamente, è vero che alla sfortuna non c'è limite, ma mi sembra proprio un caso limite !).
interface Vlan23
description *** INTERFACCIA LAYER 3 PEER-LINK ***
ip address 172.16.23.2/31
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
ip pim sparse-mode
Con questo ho terminato la prima parte di questo post. Nella seconda parte illustrerò la verifica del funzionamento del piano di controllo e del piano dati. E vi metterò a disposizione anche le configurazioni degli switch del test, che potrete utilizzare per replicarlo.
Grazie ammiraglio come sempre i tuoi test sono sempre ottimi e ben fatti .
RispondiEliminaSarebbe stupendo se poteste aggiornare questo post con l'ESI Multihoming!
RispondiElimina