Questo post è il seguito di un post precedente che potete trovare a questo link. E il terzo, non ultimo, di una serie di lab test che dimostrano la fattibilità dell'implementazione di Overlay Virtual Networks realizzate attraverso lo standard VXLAN.
IL COMANDO "advertise-pip"
Nei vPC domain è possibile il caso in cui Host di una subnet IP siano attestati a un solo Leaf del vPC domain. Di default questa subnet IP viene annunciata via BGP EVPN di tipo 5, con BGP Next-Hop l’indirizzo VIP del vPC domain. Questo può portare però a una perdita di traffico verso la subnet IP, poiché a causa del Load Balancing effettuato all’interno della IP Fabric, questo traffico potrebbe finire sul Leaf sbagliato, ossia sul Leaf dove non è attestato alcun Host della subnet IP.
La figura seguente riporta un esempio di cosa potrebbe accadere nella nostra rete test, per il traffico diretto all’Host S-50-2 (IP = 10.0.50.2).
Poiché l’Host è attestato solo a Leaf-2 (NOTA: nel gergo dei vPC domain, questo viene detto Orphan Host), Leaf-2 annuncerà via BGP EVPN di tipo 5 la subnet IP a cui appartiene (= 10.0.50.0/24) con BGP Next-Hop l’indirizzo VIP del vPC domain (= 192.168.54.23, vedi post precedente). L’annuncio viene ricevuto da Leaf-1 (NOTA: in realtà Leaf-1 riceverà due annunci, uno per ciascun Route Reflector), che inserirà il best path nella tabella di routing associata alla VRF TENANT-TT, con Next-Hop l’indirizzo VIP. In realtà l’annuncio viene anche ricevuto da Leaf-3, che al pari di Leaf-1 è anche un Route Reflector Client, ma questo lo scarta a causa della presenza (automatica) nell’annuncio di una Extended Community di tipo SoO (Site of Origin).
Ora, supponiamo che un Host attestato a Leaf-1 invii un pacchetto IP all’Host S-50-2 (IP destinazione = 10.0.50.2). Leaf-1 deve risolvere il BGP Next-Hop (remoto) 192.168.54.23 e per questo ha quattro percorsi disponibili. Supponiamo che scelga il percorso Leaf-1→SP-1→Leaf-3. Il pacchetto finirà quindi sul Leaf-3, che però non ha nella tabella di routing associata alla VRF TENANT-TT, un percorso verso la subnet IP 10.0.50.0/24, e quindi lo scarta.
La soluzione del problema è semplice, per evitare queste situazioni è necessario annunciare le subnet IP con BGP Next-Hop l’indirizzo VTEP del singolo switch e non l’indirizzo VIP. E poiché nei vPC domain il default è annunciare le subnet IP con BGP Next-Hop l’indirizzo VIP, è necessario un opportuno comando di configurazione che consenta di alterare il default. Il comando è advertise-pip, che va configurato come segue:
router bgp 65001
address-family l2vpn evpn
advertise-pip
Abilitando questo comando, ad esempio, la subnet IP 10.0.50.0/24 verrà annunciata da Leaf-2 con BGP Next-Hop = 192.168.54.2, ossia l’indirizzo IP della VTEP su Leaf-2.
NOTA: in accordo alla documentazione Cisco, oltre al comando advertise-pip è necessario configurare il comando:
interface nve1
advertise virtual-rmac
Questo comando implica l’invio, tramite un annuncio BGP EVPN di tipo 2, del Router’s MAC del Leaf.
VERIFICA DEL FUNZIONAMENTO DEL PIANO DI CONTROLLO
Prima di accendere gli Host, dopo aver effettuato le configurazioni sui vari switch Leaf, questi si scambiano, ove applicabile, annunci BGP EVPN di tipo 5 (IP Route). In realtà, di norma gli switch si scambiano anche annunci BGP EVPN di tipo 3 (Inclusive Multicast Ethernet Tag route), che consentono di costruire automaticamente le mappe VNI-VTEP, necessarie qualora si utilizzi Ingress Replication in luogo del routing multicast, ma la versione di NX-OS che stiamo utilizzando non supporta lo scambio di questo tipo di annunci.
Tramite gli annunci di tipo 5 vengono annunciati i prefissi IP conosciuti dagli switch Leaf. Nella visualizzazione della tabella BGP L2VPN EVPN riportata di seguito:
Leaf-1# show bgp l2vpn evpn
. . .
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 192.168.0.2:3
* i[2]:[0]:[0]:[48]:[5012.0006.0007]:[0]:[0.0.0.0]/216
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
*>i[5]:[0]:[0]:[24]:[10.0.10.0]/224
192.168.54.2 0 100 0 ?
* i 192.168.54.2 0 100 0 ?
*>i[5]:[0]:[0]:[24]:[10.0.20.0]/224
192.168.54.2 0 100 0 ?
* i 192.168.54.2 0 100 0 ?
*>i[5]:[0]:[0]:[24]:[10.0.50.0]/224
192.168.54.2 0 100 0 ?
* i 192.168.54.2 0 100 0 ?
Route Distinguisher: 192.168.0.3:3
* i[2]:[0]:[0]:[48]:[5012.0005.0007]:[0]:[0.0.0.0]/216
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
* i[5]:[0]:[0]:[24]:[10.0.10.0]/224
192.168.54.3 0 100 0 ?
*>i 192.168.54.3 0 100 0 ?
* i[5]:[0]:[0]:[24]:[10.0.20.0]/224
192.168.54.3 0 100 0 ?
*>i 192.168.54.3 0 100 0 ?
Route Distinguisher: 192.168.0.1:3 (L3VNI 31020)
l[5]:[0]:[0]:[24]:[10.0.10.0]/224
192.168.54.1 0 100 32768 ?
l[5]:[0]:[0]:[24]:[10.0.20.0]/224
192.168.54.1 0 100 32768 ?
è possibile vedere, nella parte superiore, gli annunci di tipo 5 che Leaf-1 riceve da Leaf-2. Il fatto che gli annunci siano ricevuti da Leaf-2, si capisce sia dal valore di Route Distinguisher, pari a 192.168.0.2:3, che dal BGP Next-Hop, pari a 192.168.0.2. Gli annunci sono relativi alle tre subnet IP 10.0.10.0/24, 10.0.20.0/24, e 10.0.50.0/24, tutte direttamente connesse a Leaf-2. Un aspetto interessante da notare è che per ciascuna subnet IP, vi sono due annunci (provenienti dai due switch Spine, che hanno la funzione di Route Reflector), e che il BGP Next-Hop è l’indirizzo IP della VTEP configurata su Leaf-2, e non l’indirizzo utilizzato per il BGP peering, come di norma avviene.
Nella tabella BGP L2VPN EVPN compaiono anche due annunci BGP EVPN di tipo 2, che annunciano i Router’s MAC di Leaf-2 (= 5012.0006.0007) e di Leaf-3 (= 5012.0005.0007). Questo è conseguenza del comando "interface nve1 → advertise virtual-rmac" citato nella sezione precedente.
Infine, si noti nell'ultima sezione del comando, quella relativa al Route Distinguisher 192.168.0.1:3, la presenza di due annunci BGP EVPN di tipo 5 locali, relativi alla presenza su Leaf-1 di due Host appartenenti rispettivamente alle subnet IP 10.0.10.0/24 e 10.0.20.0/24.
Supponiamo a questo punto di accendere un Host. Quando si accende un Host, per validare l’unicità del suo indirizzo IP, questo genera un messaggio Gratuitous ARP (GARP) allo switch Leaf di attestazione (o agli switch nel caso di attestazione multi-homed). Nel nostro esempio, l’Host S-10-1 invia il messaggio GARP allo switch Leaf-1.
Alla ricezione del messaggio GARP, lo switch Leaf:
- Aggiorna la sua MAC Address Table aggiungendo l’entry relativa al MAC address sorgente del messaggio GARP e la porta su cui è stato ricevuto.
- Diffonde il messaggio GARP agli altri switch utilizzando il routing multicast della IP Fabric.
- Genera due messaggi BGP EVPN di tipo 2, uno per annunciare il solo indirizzo MAC e l’altro per annunciare la coppia MAC/IP.
La figura seguente riporta la cattura, ottenuta via wireshark, del messaggio GARP diffuso da Leaf-1, dopo la ricezione dall’Host S-10-1.
Si noti che il messaggio, come qualsiasi trama Ethernet, viene incapsulato in VXLAN. Il valore di VNI è quello ottenuto via configurazione dalla corrispondenza VLAN-VNI configurata su Leaf-1. In particolare, poiché l’Host S-10-1 appartiene alla VLAN 10, il valore di VNI corrispondente è 10000. Poiché il messaggio GARP ha indirizzo MAC destinazione broadcast (= ffff.ffff.ffff), il pacchetto VXLAN avrà come indirizzo IP destinazione il gruppo multicast 239.1.10.1, associato via configurazione al VNI 10000.
NOTA: tutte le operazioni di MAC Learning, switching, incapsulamento/decapsulamento VXLAN, gestione degli annunci BGP EVPN, sono gestite nell’NX-OS dal processo L2FWDER. Se si volessero controllare tutte le fasi di MAC Learning e di update della tabella BGP L2VPN EVPN (L2RIB), è possibile farlo tramite il comando "show system internal l2fwder event-history events", di cui riportiamo un esempio:
Leaf-1# show system internal l2fwder event-history events | i 680a
[117] [27230]: l2fwder_dbg_ev, 690 l2fwder_vxlan_mac_update, 886MAC move 0050.7966.680a (10) 0x0 -> 0x1a000400
[117] [27230]: l2fwder_dbg_ev, 690 l2fwder_l2rib_add_delete_local_mac_routes, 154 Adding route topo-id: 10, macaddr: 0050.7966.680a, nhifindx: 0x1a000400
[117] [27230]: l2fwder_dbg_ev, 690 l2fwder_l2rib_mac_update, 736MAC move 0050.7966.680a (10) 0x0 -> 0x1a000400
A seguito della ricezione del messaggio GARP, lo switch Leaf-1 genera due annunci locali BGP EVPN di tipo 2, uno per il solo indirizzo MAC, l’altro per la coppia MAC/IP, e quindi propaga questi due annunci verso gli altri switch Leaf (via Route Reflector).
La figura seguente riporta i due entry generati nella tabella BGP L2VPN EVPN dello switch Leaf-1, a fronte della ricezione da parte dell’Host S-10-1 del messaggio GARP.
Di seguito una versione dettagliata dei due entry, con evidenziati in rosso i campi più importanti nota: 0050.7966.680a è l'indirizzo MAC dell'Host S-10-1).
Leaf-1# show bgp l2vpn evpn 0050.7966.680a
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.168.0.1:32777 (L2VNI 10000)
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.680a]:[0]:[0.0.0.0]/216, version 76
Paths: (1 available, best #1)
Flags: (0x000102) on xmit-list, is not in l2rib/evpn
Advertised path-id 1
Path type: local, path is valid, is best path
AS-Path: NONE, path locally originated
192.168.54.1 (metric 0) from 0.0.0.0 (192.168.0.1)
Origin IGP, MED not set, localpref 100, weight 32768
Received label 10000
Extcommunity: RT:65001:10000 ENCAP:8
Path-id 1 advertised to peers:
192.168.1.1 192.168.1.2
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.680a]:[32]:[10.0.10.1]/272, version 37
Paths: (1 available, best #1)
Flags: (0x000102) on xmit-list, is not in l2rib/evpn
Advertised path-id 1
Path type: local, path is valid, is best path
AS-Path: NONE, path locally originated
192.168.54.1 (metric 0) from 0.0.0.0 (192.168.0.1)
Origin IGP, MED not set, localpref 100, weight 32768
Received label 10000 31020
Extcommunity: RT:65001:10000 RT:65001:31020 ENCAP:8 Router MAC:5012.0003.0007
Path-id 1 advertised to peers:
192.168.1.1 192.168.1.2
Dopo l’accensione di tutti gli Host, le tabelle BGP L2VPN EVPN vengono popolate con tutti gli annunci, locali e ricevuti. Di seguito riporto, per motivi di spazio, i soli annunci relativi al segmento VXLAN 10000.
Leaf-1# show bgp l2vpn evpn vni-id 10000
. . .
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 192.168.0.1:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[0050.7966.680a]:[0]:[0.0.0.0]/216
192.168.54.1 100 32768 i
*>i[2]:[0]:[0]:[48]:[0050.7966.680f]:[0]:[0.0.0.0]/216
192.168.54.23 100 0 i
* i 192.168.54.23 100 0 i
*>i[2]:[0]:[0]:[48]:[0050.7966.6811]:[0]:[0.0.0.0]/216
192.168.54.23 100 0 i
*>l[2]:[0]:[0]:[48]:[0050.7966.680a]:[32]:[10.0.10.1]/272
192.168.54.1 100 32768 i
* i[2]:[0]:[0]:[48]:[0050.7966.680f]:[32]:[10.0.10.3]/272
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
*>i[2]:[0]:[0]:[48]:[0050.7966.6811]:[32]:[10.0.10.23]/272
192.168.54.23 100 0 i
Infine, per chiudere questa parte sulla verifica del piano di controllo, riporto di seguito l’insieme degli annunci BGP EVPN relativi al L3VNI = 31020, che è il valore di VNI utilizzato per l’inter-VXLAN routing:
Leaf-1# show bgp l2vpn evpn vni-id 31020
. . .
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 192.168.0.1:3 (L3VNI 31020)
* i[2]:[0]:[0]:[48]:[0050.7966.680c]:[32]:[10.0.20.2]/272
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
*>i[2]:[0]:[0]:[48]:[0050.7966.680d]:[32]:[10.0.50.2]/272
192.168.54.23 100 0 i
* i[2]:[0]:[0]:[48]:[0050.7966.680f]:[32]:[10.0.10.3]/272
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
* i[2]:[0]:[0]:[48]:[0050.7966.6811]:[32]:[10.0.10.23]/272
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
* i[2]:[0]:[0]:[48]:[0050.7966.6812]:[32]:[10.0.20.23]/272
192.168.54.23 100 0 i
*>i 192.168.54.23 100 0 i
VERIFICA DEL FUNZIONAMENTO DEL PIANO DATI
Per verificare il funzionamento del test di laboratorio realizzato, eseguirò dei ping intra-VXLAN e inter-VXLAN.
Questo è il risultato del ping intra-VXLAN tra gli Host S-10-1 e S-10-23, entrambi appartenenti allo stesso segmento VXLAN 10000:
S-10-1> ping 10.0.10.23
84 bytes from 10.0.10.23 icmp_seq=1 ttl=64 time=21.210 ms
84 bytes from 10.0.10.23 icmp_seq=2 ttl=64 time=21.205 ms
84 bytes from 10.0.10.23 icmp_seq=3 ttl=64 time=21.214 ms
84 bytes from 10.0.10.23 icmp_seq=4 ttl=64 time=21.192 ms
84 bytes from 10.0.10.23 icmp_seq=5 ttl=64 time=21.198 ms
Gli Host hanno indirizzo IP rispettivamente 10.0.10.1/24 e 10.0.10.23/24, e sono connessi a switch Leaf diversi, il primo a Leaf-1 e il secondo allo switch L2 puro SW-23, connesso in modalità multi-homing a Leaf-2 e Leaf-3.
Un aspetto molto importante da notare, non visibile dal solo ping, è che poiché è stata abilitata la funzionalità di ARP Suppression, l’ARP Reply in risposta all’ARP Request inviato dall’Host S-10-1, viene inviato all’Host direttamente da Leaf-1, evitando così il flooding del messaggio ARP Request sulla IP Fabric, e riducendo così di molto il traffico multicast all’interno di questa. Solo nel caso in cui un ARP Suppression-Cache lookup risulti in un miss (ossia, manca la corrisponedenza <MAC; IP>), allora il messaggio ARP Request segue la procedura ordinaria, ossia viene propagato via flooding agli altri switch Leaf utilizzando nella IP Fabric il gruppo multicast associato al VNI.
La figura seguente riporta la parte della ARP Suppression-cache di Leaf-1 relativa agli Host della VLAN 10, ottenuta tramite il comando "show ip arp suppression-cache vlan 10".
Da questa si evince la presenza dell’ARP entry <0050.7966.6811; 10.0.10.23>, che conferma quanto appena affermato. Si noti che non vi è alcun aging timer per gli entry della ARP Suppression-cache. Questo perché gli entry sono rimossi solo quando Leaf-1 riceve un messaggio BGP UPDATE dal Leaf che ha annunciato l’ARP entry remoto, per ritirare l'ARP entry stesso.
Questo è invece il risultato del ping inter-VXLAN tra gli Host S-40-1 e S-10-23, appartenenti rispettivamente ai segmenti VXLAN 20000 e 10000.
S-40-1> ping 10.0.10.23
84 bytes from 10.0.10.23 icmp_seq=1 ttl=62 time=48.353 ms
84 bytes from 10.0.10.23 icmp_seq=2 ttl=62 time=19.845 ms
84 bytes from 10.0.10.23 icmp_seq=3 ttl=62 time=18.092 ms
84 bytes from 10.0.10.23 icmp_seq=4 ttl=62 time=28.480 ms
84 bytes from 10.0.10.23 icmp_seq=5 ttl=62 time=30.530 ms
Gli Host hanno indirizzo IP rispettivamente 10.0.20.1/24 e 10.0.10.23/24, e sono connessi a switch Leaf diversi, il primo a Leaf-1 e il secondo allo switch L2 puro SW-23, connesso in modalità multi-homing a Leaf-2 e Leaf-3.
Nella figura seguente è riportata la cattura, ottenuta via wireshark, del messaggio ARP Reply che Leaf-1 invia all’Host S-40-1, in risposta all’ARP Request inviato da quest’ultimo, per ottenere l’indirizzo MAC del Default Gateway (= 10.0.20.254).
Si noti che l’ARP Reply comunica all’Host, come indirizzo MAC associato al Default Gateway, l’indirizzo Anycast Gateway MAC address 00:00:00:03:10:20, configurato su ciascun switch Leaf con il comando "fabric forwarding anycast-gateway-mac 0000.0003.1020", visto nel post precedente.
Infine, la figura seguente riporta la cattura di un pacchetto VXLAN che contiene una trama Ethernet, che a sua volta contiene un pacchetto ICMP Echo Request inviato da S-40-1 a S-10-23.
La cattura è stata presa in uscita dall’interfaccia E1/1 di Leaf-1. Il pacchetto VXLAN ha come VNI il valore di L3VNI 31020, VTEP sorgente l’indirizzo della VTEP su Leaf-1 e VTEP destinazione l’indirizzo IP del VIP del vPC domain definito su Leaf-2 e Leaf-3. Si noti che la trama Ethernet che contiene il messaggio ICMP ha indirizzo MAC destinazione il Router MAC address di Leaf-2, annunciato a Leaf-1 tramite una Extended Community associata all’annuncio BGP EVPN di tipo 2 della coppia MAC/IP dell’Host S-10-23. La verifica può essere effettuata analizzando il dettaglio degli annunci BGP EVPN. Lascio al lettore come utile esercizio, controllarne i vari attributi BGP contenuti.
Leaf-1# show bgp l2vpn evpn rd 192.168.0.1:3 10.0.10.23
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.168.0.1:3 (L3VNI 31020)
BGP routing table entry for [2]:[0]:[0]:[48]:[0050.7966.6811]:[32]:[10.0.10.23]/272, version 3014
Paths: (2 available, best #2)
Flags: (0x000202) on xmit-list, is not in l2rib/evpn, is not in HW
Path type: internal, path is valid, not best reason: Router Id
Imported from 192.168.0.3:32777:[2]:[0]:[0]:[48]:[0050.7966.6811]:[32]:[10.0.10.23]/272
AS-Path: NONE, path sourced internal to AS
192.168.54.23 (metric 81) from 192.168.1.1 (192.168.1.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 31020
Extcommunity: RT:65001:10000 RT:65001:31020 SOO:192.168.54.23:0 ENCAP:8 Router MAC:5012.0005.0007
Originator: 192.168.0.3 Cluster list: 192.168.1.1
Advertised path-id 1
Path type: internal, path is valid, is best path
Imported from 192.168.0.2:32777:[2]:[0]:[0]:[48]:[0050.7966.6811]:[32]:[10.0.10.23]/272
AS-Path: NONE, path sourced internal to AS
192.168.54.23 (metric 81) from 192.168.1.1 (192.168.1.1)
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 31020
Extcommunity: RT:65001:10000 RT:65001:31020 SOO:192.168.54.23:0 ENCAP:8 Router MAC:5012.0004.0007
Originator: 192.168.0.2 Cluster list: 192.168.1.1
Path-id 1 not advertised to any peer
NOTA: come più volte citato, il Cisco NX-OS supporta la sola modalità di inter-VXLAN routing simmetrica. Per verificarlo è possibile utilizzare il comando "show nve peers detail", di cui riporto un esempio di esecuzione su Leaf-1:
Leaf-1# show nve peers detail
Details of nve Peers:
----------------------------------------
Peer-Ip: 192.168.54.4
NVE Interface : nve1
Peer State : Up
Peer Uptime : 08:09:16
Router-Mac : 5012.0006.0007
Peer First VNI : 31020
Time since Create : 08:09:16
Configured VNIs : 10000,20000,31020
Provision State : peer-add-complete
Learnt CP VNIs : 31020
vni assignment mode : SYMMETRIC
Peer Location : N/A
E qui finisce l'avventura del Signor Bonaventura ... Arrivederci al prossimo post, in cui tratterò dell'interconnessione del Data Center con una rete IP/MPLS, mostrando come sia possibile estendere la virtual network a Host connessi alla rete IP/MPLS.
Nessun commento:
Posta un commento