Circa un paio di anni fa, in questo post sull'evoluzione del piano di controllo delle VXLAN, avevo illustrato un breve test di laboratorio utilizzando router Cisco (virtuali) CSR1000v, con la promessa che appena avessi avuto la possibilità di replicarlo in ambiente Cisco Nexus, lo avrei condiviso. Il test di laboratorio riguardava l'utilizzo di VXLAN senza un piano di controllo, con il MAC learning che avviene interamente sul piano dati utilizzando all'interno della IP Fabric un protocollo di routing multicast (VXLAN Flood & Learn).
NOTA: questo è il primo di una serie di post sull'implementazione di VXLAN in ambiente sia Cisco Nexus che Juniper QFX. In particolare, a parte questo post iniziale, nei prossimi illustrerò in dettaglio l'implementazione pratica della soluzione VXLAN + EVPN, ossia la realizzazione di segmenti VXLAN utilizzando come piano di controllo EVPN (ampiamente trattato in questo blog). Quindi, stay tuned ...
LO SCENARIO
La rete test utilizzata è identica a quella del post precedente, una classica topologia Leaf-and-Spine, con tre switch Leaf e due switch Spine, ed è riportata nella figura seguente.
La funzione VTEP è in questo esempio localizzata direttamente nei Leaf, ma come detto in post precedenti, potrebbe anche essere integrata negli Hypervisor dei server (anzi, sarebbe anche meglio). In quest'ultimo caso, i Leaf svolgerebbero, al pari degli Spine, solo le semplici funzioni di Livello 3.
La
rete underlay
utilizza come protocollo di routing
unicast
OSPF
in area singola (= 0). Sulla rete underlay è
stato poi configurato il protocollo di routing multicast PIM-BiDir,
utilizzando come metodo (standard) di selezione del Rendezvous-Point il
semplice Phantom-RP.
Su
questa rete sono state configurati due segmenti VXLAN,
aventi rispettivamente VNI 5010 e 5020. I due segmenti VXLAN 5010
e 5020 utilizzano per il traffico BUM
rispettivamente i due gruppi multicast
239.1.10.1 e 239.1.20.1.
La
figura riporta anche l’appartenenza dei singoli server a una VLAN. Si noti che
il valore di VLAN tag
è
locale al switch e
può essere diverso di switch a switch,
all’interno dello stesso segmento VXLAN. Ciò che lega l’appartenenza dei server
allo stesso segmento VXLAN è il valore di VNI. Ad esempio, il server H1-3
alla VLAN 30,
ma sullo switch Leaf L3 è
configurata un’associazione VLAN→VNI
= 30→5010. Quindi H1-3, pur appartenendo alla
VLAN 30, è parte dello stesso segmento VXLAN di H1-1 e H1-2 (= 5010).
NOTA: su ciascun switch
Leaf sono state configurate due interfacce di Loopback. L’interfaccia Loopback0 non è
importante e viene utilizzata (anche se non servirebbe, perché ?) come RID OSPF.
L’interfaccia Loopback54 viene invece utilizzata come indirizzo IP delle VTEP.
In realtà sarebbe sufficiente una sola interfaccia, ma è best practice utilizzare interfacce diverse per le
VTEP perché questo velocizza la convergenza in alcune situazioni (ad esempio,
nel caso di Graceful
Insertion and Removal (GIR)).
RETE UNDERLAY
La configurazione della rete Underlay richiede l'attivazione di un protocollo di routing dinamico unicast e uno multicast.
La scelta del protocollo di routing unicast è stata ampiamente discussa in questo post. Sintetizzo il risultato: nei Data Center di dimensioni medio-piccole, diciamo con un numero al più di un centinaio di switch, è bene utilizzare un protocollo di routing IGP classico, come OSPF o IS-IS. Quale dei due è lasciato alla libera scelta dell'amministratore di rete. Benché come noto ai lettori di questo blog, io abbia una predilezione per IS-IS, consiglio sempre di utilizzare quello che si sa "smanettare" meglio; in uno scenario come questo che sto analizzando, uno vale l'altro. In questo test di laboratorio, facendo un po' di violenza su me stesso, ho utilizzato OSPF in area singola (area 0), ma solo perché è più conosciuto di IS-IS. E in ogni caso in quello che illustrerò, non comparirà praticamente nulla di OSPF.
La scelta del protocollo di routing unicast è stata ampiamente discussa in questo post. Sintetizzo il risultato: nei Data Center di dimensioni medio-piccole, diciamo con un numero al più di un centinaio di switch, è bene utilizzare un protocollo di routing IGP classico, come OSPF o IS-IS. Quale dei due è lasciato alla libera scelta dell'amministratore di rete. Benché come noto ai lettori di questo blog, io abbia una predilezione per IS-IS, consiglio sempre di utilizzare quello che si sa "smanettare" meglio; in uno scenario come questo che sto analizzando, uno vale l'altro. In questo test di laboratorio, facendo un po' di violenza su me stesso, ho utilizzato OSPF in area singola (area 0), ma solo perché è più conosciuto di IS-IS. E in ogni caso in quello che illustrerò, non comparirà praticamente nulla di OSPF.
Diverso è il discorso per il protocollo di routing multicast. Qui, a parte la scelta obbligata del protocollo PIM SM, vi è la possibilità di utilizzare diverse varianti di questo protocollo. Ho utilizzato la variante PIM BiDir, poiché secondo me più idonea in quanto ciascuno dei switch Leaf può agire sia come sorgente che destinazione del traffico. Poi, dovendo comunque transitare il traffico attraverso gli switch Spine, ha poco senso utilizzare il PIM SM base, che effettua, dopo il primo pacchetto multicast (o al superamento di una soglia di traffico, dipende dall'implementazione), un switchover da un albero condiviso (RPT, Rendezvous-Point Tree) ad un albero sorgente (SPT, Shortest Path Tree).
Il protocollo PIM-BiDir utilizza per la ridondanza dei Rendezvous-Point (RP), una sorta di trucchetto noto come Phantom-RP (RP fantasma). Nel Phantom-RP, un RP è configurato con un indirizzo IP che non appartiene effettivamente a un particolare Spine (da qui il nome di RP fantasma). L’idea di fondo è molto semplice e si basa sul ben noto algoritmo Longest Match Prefix (LPM) con cui viene instradato il traffico IP. Per spiegarlo utilizzerò l’esempio del test di laboratorio, dove ho ripartito la funzionalità di RP in funzione dei gruppi multicast. In particolare, lo switch Spine S1 ha la funzione di RP per i gruppi multicast 239.1.10.0/24, mentre lo switch Spine S2 ha la funzione di RP per i gruppi multicast 239.1.20.0/24.
Il protocollo PIM-BiDir utilizza per la ridondanza dei Rendezvous-Point (RP), una sorta di trucchetto noto come Phantom-RP (RP fantasma). Nel Phantom-RP, un RP è configurato con un indirizzo IP che non appartiene effettivamente a un particolare Spine (da qui il nome di RP fantasma). L’idea di fondo è molto semplice e si basa sul ben noto algoritmo Longest Match Prefix (LPM) con cui viene instradato il traffico IP. Per spiegarlo utilizzerò l’esempio del test di laboratorio, dove ho ripartito la funzionalità di RP in funzione dei gruppi multicast. In particolare, lo switch Spine S1 ha la funzione di RP per i gruppi multicast 239.1.10.0/24, mentre lo switch Spine S2 ha la funzione di RP per i gruppi multicast 239.1.20.0/24.
Ora,
tramite il protocollo IGP (nell’esempio, come detto, OSPF in area 0), S1 annuncia i due
prefissi IP 192.168.10.0/30 e 192.168.20.0/29. Viceversa, S2 annuncia i due
prefissi IP 192.168.10.0/29 e 192.168.20.0/30. Gli switch Leaf
utilizzano come RP un indirizzo (qualsiasi, fantasma)
appartenente a questi due prefissi IP. In particolare ho utilizzato:
- 192.168.10.1 per i gruppi multicast 239.1.10.0/24
- 192.168.20.1 per i gruppi multicast 239.1.20.0/24
Per
l’algoritmo LPM, quindi ciascun Leaf
utilizza come RP S1 per i gruppi multicast
239.1.10.0/24 e S2 per i gruppi multicast
239.1.20.0/24. I dettagli sono lasciati al lettore come utile esercizio di networking. L'idea è riassunta nella figura seguente.
Le configurazioni da eseguire sullo switch Spine S1 sono le seguenti:
ip pim rp-address 192.168.20.1 group-list 239.1.20.0/24 bidir
!
interface loopback 10
description *** INTERFACCIA DI LOOPBACK PER RIDONDANZA RP ***
ip address 192.168.10.2/30
ip pim sparse-mode
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
interface loopback 20
description *** INTERFACCIA DI LOOPBACK PER RIDONDANZA RP ***
ip address 192.168.20.2/29
ip pim sparse-mode
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
NOTA:
il comando "ip ospf
network point-to-point" nella configurazione delle interfacce di Loopback è
necessario poiché altrimenti l’implementazione Cisco OSPF annuncerebbe i due
indirizzi come host route
(maschera /32), e non con le rispettive maschere /30 e /29.
Le configurazioni da eseguire sullo switch Spine S2 sono analoghe e non vengono riportate.
Per completare questa parte relativa alla configurazione della rete Underlay, dovrei riportare anche le configurazioni di OSPF. Ma essendo queste molto semplici, le lascio al lettore.
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;
- 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.
Sugli switch Spine è sufficiente abilitare le prime due, 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).
Veniamo ora alla parte più interessante. La realizzazione dei segmenti VXLAN prevede due passi fondamentali, entrambi da eseguire negli switch Leaf:
- Definizione delle associazioni VLAN tag → VNI. È necessario istruire lo switch a quale segmento VXLAN appartiene ciascun server. Ricordiamo che il valore di VLAN tag è locale allo switch e può essere diverso da switch a switch, quello che lega eventuali valori diversi di VLAN tag è il comune valore di VNI.
- Configurazione dell’interfaccia VTEP (chiamata "nve", che ricordo sta per "network virtualizaztion endpoint"). 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.
Le configurazioni da eseguire per le associazioni VLAN tag → VNI sono le seguenti:
Sugli switch Leaf L1 e L2
vlan 10
vn-segment 5010
vlan 20
vn-segment 5020
Sullo switch Leaf L3
vlan 30
vn-segment 5010
La configurazione dell'interfaccia VTEP è la seguente:
Sugli switch Leaf L1 e L2
interface nve1
source-interface loopback54
member vni 5010 mcast-group 239.1.10.1
member vni 5020 mcast-group 239.1.20.1
Sullo switch Leaf L3
interface nve1
source-interface loopback54
member vni 5010 mcast-group 239.1.10.1
Nel momento in cui l’interfaccia "nve1" va nello stato up, lo switch Leaf dove l’interfaccia è configurata, genera dei messaggi PIM Join per effettuare il join ai gruppi multicast associati ai segmenti VXLAN. Questi messaggi vengono inviati al rispettivo Rendezvous-Point.
Ad esempio, nella nostra rete test, lo switch Leaf L1 genera due messaggi PIM Join, per il join ai gruppi multicast 239.1.10.1 e 239.1.20.1, associati rispettivamente ai segmenti VXLAN 5010 e 5020 (vedi configurazione dell’interfaccia "nve1" sopra). Secondo le regole del protocollo PIM, questi messaggi vengono ripetuti periodicamente, con un periodo di default che negli switch Cisco Nexus è di 60 s.
La figura seguente riporta la cattura del messaggio PIM Join inviato dallo switch Leaf L1, per il join del gruppo multicast 239.1.10.1, associato al segmento VXLAN 5010.
Il messaggio viene inviato con indirizzo IP sorgente 10.1.11.2, che è l’indirizzo IP dell’interfaccia di Leaf L1 verso il Rendezvous-Point S1. L’indirizzo destinazione è invece l’indirizzo multicast well-known 224.0.0.13, che identifica tutti i router di un segmento broadcast dove è abilitato il protocollo PIM (indirizzo AllPimRouters). Si noti che l’upstream neighbor (= 10.1.11.1) è l’indirizzo IP next-hop verso l’indirizzo IP (phantom !) del Rendezvous-Point S1 (=192.168.10.1).
Per completezza, riportiamo di seguito anche l’analisi dell’altro messaggio PIM Join generato dallo switch Leaf L1:
AVRO' FATTO UN BUON LAVORO ?
Per verificare se tutto quanto fatto funziona, ho eseguito inizialmente i due comandi seguenti:
L1# show nve interface nve1
Interface: nve1, State: Up, encapsulation: VXLAN
VPC Capability: VPC-VIP-Only [not-notified]
Local Router MAC: 5007.0001.0007
Host Learning Mode: Data-Plane
Source-Interface: loopback54 (primary: 192.168.54.1, secondary: 0.0.0.0)
L1# show nve vni
Codes: CP - Control Plane DP - Data Plane
UC - Unconfigured SA - Suppress ARP
SU - Suppress Unknown Unicast
Interface VNI Multicast-group State Mode Type [BD/VRF] Flags
--------- -------- ----------------- ----- ---- ------------------ -----
nve1 5010 239.1.10.1 Up DP L2 [10]
nve1 5020 239.1.20.1 Up DP L2 [20]
Il primo comando consente di verificare lo stato dell’interfaccia VTEP (interfaccia "nve"), il tipo di incapsulamento utilizzato e l’indirizzo IP dell’interfaccia VTEP (=192.168.54.1, coincidente con l’indirizzo IP dell’interfaccia Loopback54 di L1).
Il secondo comando mostra i VNI dei segmenti VXLAN associati all’interfaccia VTEP, e il corrispondente gruppo multicast associato.
Infine, un altro comando interessante è il seguente:
L1# show nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- -------------- ---------- -----------------
nve1 192.168.0.2 Up DP 01:41:47 n/a
nve1 192.168.0.3 Up DP 01:42:17 n/a
che mostra i VXLAN peer, ossia l’indirizzo IP delle interfacce VTEP e delle VNI presenti nel peer. Si noti che per apprendere i VXLAN peer, ci deve essere prima del traffico tra due Host dello stesso segmento VXLAN, appartenenti ai due VXLAN peer.
Mostrerò ora qualche dettaglio del piano dati. A tale scopo ho eseguito un semplice ping dall’Host H1-1 all’Host H1-3, entrambi appartenenti al medesimo segmento VXLAN identificato da VNI = 5010, corrispondente al segmento VLAN 10 per H1-1, e al segmento VLAN 30 per H1-3.
Il primo passo, classico, è l’emissione da parte dell’Host H1-1 di un messaggio ARP Request, per ottenere l’indirizzo MAC corrispondente all’indirizzo IP di H1-3 (= 10.0.10.3). Il messaggio ARP Request, arriva allo switch Leaf L1 sulla porta Ethernet1/3, configurata come porta access della VLAN 10:
interface Ethernet1/3
switchport access vlan 10
Come noto, il messaggio ARP Request ha indirizzo MAC destinazione broadcast (= ff:ff:ff:ff:ff:ff). Quindi a causa delle associazioni <VLAN 10 <--> VNI 5010> e <VNI 5010 <--> Gruppo multicast 239.1.10.1>, il messaggio ARP Request viene incapsulato in un pacchetto VXLAN con VNI = 5010, indirizzo IP sorgente = 192.168.54.1 (indirizzo VTEP sullo switch Leaf L1) e indirizzo IP destinazione = 239.1.10.1. Il pacchetto VXLAN viene quindi inviato al Next-Hop verso il (phantom) Rendezvous-Point (= 192.168.10.1), utilizzando le informazioni della tabella di routing multicast riportate nella diapositiva successiva.
La figura seguente riporta una analisi del pacchetto VXLAN risultante, ottenuta tramite wireshark, dove ho evidenziato alcuni campi importanti.
Il pacchetto VXLAN viene instradato dallo switch Leaf L1 seguendo le informazioni della tabella di routing multicast:
L1# show ip mroute 239.1.10.1
IP Multicast Routing Table for VRF "default"
(*, 239.1.10.1/32), bidir, uptime: 01:23:36, nve ip pim
Incoming interface: Ethernet1/1, RPF nbr: 10.1.11.1
Outgoing interface list: (count: 2)
Ethernet1/1, uptime: 01:23:36, pim, (RPF)
nve1, uptime: 01:23:36, nve
Come si evince dall’entry della tabella di routing multicast sullo switch L1, un pacchetto con indirizzo IP destinazione multicast 239.1.10.1, viene inviato sull’interfaccia Ethernet1/1, che è l’interfaccia del collegamento punto-punto verso lo switch S1 (che in questo esempio è il Rendezvous-Point per i gruppi multicast 239.1.10.0/24). Nella "Outgoing interface list" compare anche l’interfaccia "nve1", per indicare che il pacchetto viene incapsulato in un pacchetto VXLAN attraverso l’interfaccia "nve1", utilizzando come indirizzo IP sorgente l’indirizzo dell'interfaccia VTEP su L1.
Una volta arrivato allo switch Spine S1, il pacchetto VXLAN viene replicato su tutte le interfacce appartenenti alla "Outgoing interface list":
S1# show ip mroute 239.1.10.1
IP Multicast Routing Table for VRF "default"
(*, 239.1.10.1/32), bidir, uptime: 03:46:22, pim ip
Incoming interface: loopback10, RPF nbr: 192.168.10.1
Outgoing interface list: (count: 4)
Ethernet1/3, uptime: 00:35:02, pim
Ethernet1/2, uptime: 01:22:55, pim
Ethernet1/1, uptime: 01:25:51, pim
loopback10, uptime: 03:46:22, pim, (RPF)
ossia le interfacce Ethernet1/1, Ethernet1/2 e Ethernet1/3, che sono le interfacce verso gli switch Leaf. A questo punto il pacchetto VXLAN raggiunge le interfacce VTEP degli switch Leaf, che eseguono il decapsulamento e inviano il messaggio ARP Request agli Host del segmento VXLAN con VNI = 5010.
Poiché H1-3 è il target del messaggio ARP Request, questo risponde con un messaggio ARP Reply all’indirizzo MAC unicast dell’Host H1-1 (= 00:50:79:66:68:06). Il messaggio ARP Reply viene quindi incapsulato in una pacchetto VXLAN con indirizzo IP sorgente quello della propria VTEP (= 192.168.54.3) e indirizzo destinazione quello della VTEP su L1 (= 192.168.54.1). Si noti che quest’ultimo indirizzo è il risultato dell’associazione MAC-to-VTEP che L3 ha "appreso" sul piano dati, grazie al messaggio ARP Request precedente.
La figura seguente riporta una analisi del pacchetto VXLAN risultante, ottenuta tramite wireshark, dove ho evidenziato alcuni campi importanti.
Alla fine di questo scambio di messaggi ARP Request/Reply, gli switch L1 e L3 hanno appreso le seguenti associazioni MAC-to-VTEP (oltre ovviamente al MAC learning locale):
- Su L1: MAC H1-3 <--> VTEP = 192.168.54.3.
- Su L3: MAC H1-1 <--> VTEP = 192.168.54.1.
A questo punto tutte le tabelle MAC sono pronte per lo scambio di traffico tra gli Host H1-1 e H1-3. Il routing dei pacchetti VXLAN unicast sulla IP Fabric, avviene grazie al protocollo OSPF configurato nella rete Underlay. Come verifica abbiamo eseguito (con successo) un ping tra i due Host:
H1-1> ping 10.0.10.3
84 bytes from 10.0.10.3 icmp_seq=1 ttl=64 time=65.381 ms
84 bytes from 10.0.10.3 icmp_seq=2 ttl=64 time=32.417 ms
84 bytes from 10.0.10.3 icmp_seq=3 ttl=64 time=22.216 ms
84 bytes from 10.0.10.3 icmp_seq=4 ttl=64 time=28.583 ms
84 bytes from 10.0.10.3 icmp_seq=5 ttl=64 time=56.553 ms
. . .
Per concludere, la figura seguente riporta la cattura di un pacchetto VXLAN, analizzato con wireshark. Il pacchetto trasporta un ICMP Echo Reply inviato da H1-3 a H1-1.
Sembra funzionare tutto !!! Se volete replicare questo test di laboratorio e magari "smanettarci" un po' su, a questo link potete scaricare un file testo con le configurazioni che ho utilizzato.
CONCLUSIONI
La versione più semplice per realizzare segmenti VXLAN è quella di non utilizzare un vero e proprio piano di controllo, ma utilizzare un protocollo di routing multicast nella IP Fabric, in modo da apprendere le mappe MAC-to-VTEP direttamente sul piano dati. Si potrebbe anche fare a meno del protocollo di routing multicast utilizzando il meno efficiente (ma nettamente più semplice) Head End Replication, purtroppo non supportato dalla versione di VIRL che ho utilizzato. In reti di piccole dimensioni questo approccio potrebbe anche andare bene, ma manca delle molte funzionalità aggiuntive che l'utilizzo di un vero piano di controllo può offrire. Per questo nei prossimi post illustrerò dei Lab Test più complessi, basati sull'utilizzo di EVPN come piano di controllo per la realizzazione di segmenti VXLAN. E quindi, stay tuned ...
CONCLUSIONI
La versione più semplice per realizzare segmenti VXLAN è quella di non utilizzare un vero e proprio piano di controllo, ma utilizzare un protocollo di routing multicast nella IP Fabric, in modo da apprendere le mappe MAC-to-VTEP direttamente sul piano dati. Si potrebbe anche fare a meno del protocollo di routing multicast utilizzando il meno efficiente (ma nettamente più semplice) Head End Replication, purtroppo non supportato dalla versione di VIRL che ho utilizzato. In reti di piccole dimensioni questo approccio potrebbe anche andare bene, ma manca delle molte funzionalità aggiuntive che l'utilizzo di un vero piano di controllo può offrire. Per questo nei prossimi post illustrerò dei Lab Test più complessi, basati sull'utilizzo di EVPN come piano di controllo per la realizzazione di segmenti VXLAN. E quindi, stay tuned ...
Excellent - Veramente molto chiaro, semplice e dettagliato al tempo stesso. Grazie Ammiraglio.
RispondiEliminaPerché non il mp-bgp? Configurazione più semplice e meno traffico bum
RispondiElimina