In questo post precedente ho illustrato gli aspetti architetturali dell'interconnessione di un Data Center con una rete IP/MPLS esterna dove è realizzato un servizio L3VPN con siti dispersi geograficamente e appartenenti a un determinato tenant. In questo post, che è il seguito del precedente, illustrerò un Case Study su una rete di laboratorio.
Il Case Study è basato sull’interconnessione tra una IP Fabric e una rete IP/MPLS, utilizzando il modello "Inter-AS Option A". La topologia del Data Center è identica a quella utilizzata nel Case Study di questo post, con l’aggiunta del Border Leaf B-Leaf, per l’interconnessione con una rete IP/MPLS esterna.
L’obiettivo del test è mostrare come sia possibile interconnettere un tenant del Data Center con Host remoti, sempre dello stesso tenant, raggiungibili attraverso un classico servizio L3VPN realizzato su una rete IP+MPLS.
L’idea è quella di attivare, tra uno switch di bordo del Data Center (Border Leaf) e un PE della rete IP/MPLS, un collegamento associato a due VRF configurate rispettivamente sul Border Leaf e sul PE. Questo fa si che il Border leaf veda il router PE come fosse un CE e viceversa, permettendo lo scambio dei prefissi inter-sito utilizzando una semplice sessione eBGP.
Questa soluzione non è molto scalabile poiché richiede per ciascun tenant una VRF dedicata e un collegamento separato (da realizzare eventualmente utilizzando sub-interfacce). Il problema diventa poi molto più complesso al crescere del numero di siti da interconnettere.
Le configurazioni rilevanti dello switch B-Leaf sono simili a quelle viste nei post precedenti. Ovviamente qui non sono definite le EVI poiché non vi sono Host del tenant direttamente connessi. Le riportiamo per completezza (ad esclusione delle configurazioni del BGP, riportate a parte nella figura seguente):
feature ospf
feature bgp
feature pim
feature interface-vlan
feature vn-segment-vlan-based
feature nv overlay
fabric forwarding anycast-gateway-mac 0000.0003.1020
ip pim rp-address 192.168.10.1 group-list 239.1.10.0/24 bidir
ip pim rp-address 192.168.20.1 group-list 239.1.20.0/24 bidir
ip pim ssm range 232.0.0.0/8
vlan 1,1020
!
vlan 1020
vn-segment 31020
!
vrf context TENANT-TT
vni 31020
rd auto
address-family ipv4 unicast
route-target both auto
route-target both auto evpn
!
interface Vlan1020
description *** INTERFACCIA PER INTER-VXLAN ROUTING ***
mtu 1600
vrf member TENANT-TT
ip forward
interface nve1
host-reachability protocol bgp
source-interface loopback54
member vni 31020 associate-vrf
interface Ethernet1/2
description *** INTERFACCIA VERSO SP-2 ***
no switchport
mtu 1600
mac-address 0000.0014.0012
ip address 10.1.42.2/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
interface Ethernet1/3
description *** INTERFACCIA VERSO PE2 RETE IP/MPLS ***
no switchport
mtu 1600
mac-address 0000.0014.0013
vrf member TENANT-TT
ip address 10.1.50.2/30
!
interface loopback0
description *** INTERFACCIA PER BGP PEERING E VTEP ***
ip address 192.168.0.4/32
ip router ospf 1 area 0.0.0.0
!
interface loopback54
description ** VTEP/Overlay **
ip address 192.168.54.4/32
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
La figura seguente riporta le configurazioni rilevanti del processo BGP sullo switch B-Leaf. A parte le due sessioni MP-iBGP dell’address-family L2VPN EVPN verso gli due switch Spine che hanno funzionalità di Route Reflector, è presente anche una sessione eBGP, configurata all’interno della VRF TENANT-TT.
Quest’ultima è una normale sessione eBGP dell’address family (di default) IPv4 Unicast (AFI/SAFI = 1/1).
Un aspetto interessante della configurazione è l’aggregazione effettuata attraverso il comando "aggregate-address 10.0.0.0/16 summary-only". Senza questa aggregazione, lo switch B-Leaf annuncerebbe gli indirizzi dei singoli Host alla L3VPN (annunciati come Host Route /32), provocando possibili problemi di scalabilità. Con l’aggregazione il B-Leaf annuncia al PE della rete IP/MPLS (nel nostro esempio, PE2) il solo prefisso 10.0/16 (NOTA: questo prefisso contiene tutte le subnet IP che abbiamo utilizzato per la numerazione degli Host dei tre segmenti VXLAN realizzati, e molto di più. Non è ottimizzato ma non è un aspetto importante).
Le configurazioni lato PE2 della rete IP/MPLS sono classiche e non vengono riportate.
Gli annunci eBGP provenienti dalla rete IP/MPLS vengono ricevuti da B-Leaf sull’interfaccia e1/3 associata alla VRF TENANT-TT:
interface Ethernet1/3
description *** INTERFACCIA VERSO PE2 RETE IP/MPLS ***
vrf member TENANT-TT
ip address 10.1.50.2/30
Per questo motivo, B-Leaf associa a ciascun annuncio ricevuto il valore di RT Export configurato all’interno della VRF TENANT-TT, che essendo stato configurato con il comando per la definizione automatica, assume il valore AS:L3VNI = 65001:31020.
- Uno per l’address-family BGP EVPN (AFI/SAFI = 25/70).
- L’altro per l’address-family IPv4 Unicast (AFI/SAFI = 1/1).
La visualizzazione seguente riporta l’entry relativo all’address-family BGP EVPN:
B-Leaf# show bgp l2vpn evpn 192.0.2.0 vrf TENANT-TT
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.168.0.4:3 (L3VNI 31020)
BGP routing table entry for [5]:[0]:[0]:[24]:[192.0.2.0]/224, version 916
Paths: (1 available, best #1)
Flags: (0x000002) (high32 00000000) on xmit-list, is not in l2rib/evpn
Advertised path-id 1
Path type: local, path is valid, is best path, no labeled nexthop
Gateway IP: 0.0.0.0
AS-Path: 1234 , path sourced external to AS
192.168.54.4 (metric 0) from 0.0.0.0 (192.168.0.4)
Origin incomplete, MED not set, localpref 100, weight 0
Received label 31020
Extcommunity: RT:65001:31020 ENCAP:8 Router MAC:5012.0004.0007
Path-id 1 advertised to peers:
192.168.1.1 192.168.1.2
mentre di seguito viene riportato quello relativo all’address-family IPv4 Unicast. In entrambi i casi agli entry è associato il valore di RT = 65001:31020.
B-Leaf# show bgp ipv4 unicast 192.0.2.0 vrf TENANT-TT
BGP routing table information for VRF TENANT-TT, address family IPv4 Unicast
BGP routing table entry for 192.0.2.0/24, version 873
Paths: (1 available, best #1)
Flags: (0x880c001a) (high32 0x000020) on xmit-list, is in urib, is best urib route, is in HW, exported
vpn: version 910, (0x100002) on xmit-list
Advertised path-id 1, VPN AF advertised path-id 1
Path type: external, path is valid, is best path, no labeled nexthop, in rib
AS-Path: 1234 , path sourced external to AS
10.1.50.1 (metric 0) from 10.1.50.1 (192.168.0.112)
Origin incomplete, MED not set, localpref 100, weight 0
Extcommunity: RT:65001:31020
VRF advertise information:
Path-id 1 not advertised to any peer
VPN AF advertise information:
Path-id 1 not advertised to any peer
La figura seguente riporta una parte della cattura (ottenuta via wireshark) del messaggio BGP EVPN di tipo 5 che B-Leaf invia ai Route Reflector SP-1 e SP-2, per annunciare il prefisso IP 192.0.2.0/24 ricevuto dalla rete IP/MPLS.
Lo switch B-Leaf, una volta ricevuto un annuncio eBGP dall’esterno, come già detto, crea nella Tabella BGP un entry dell’address-family BGP EVPN, e quindi propaga l’annuncio verso i due Route Reflector, utilizzando le sessioni MP-iBGP, dove è attivo il trasporto degli annunci BGP EVPN. L’annuncio viene propagato come annuncio BGP EVPN di tipo 5, poiché ad essere annunciato è un prefisso IP.
Si noti che la propagazione verso i due Route Reflector non è automatica, ma dipende dalla presenza o meno del comando "advertise l2vpn evpn" all’interno della configurazione del processo BGP:
router bgp 65001
vrf TENANT-TT
address-family ipv4 unicast
advertise l2vpn evpn
Questa è una implementazione specifica dell’NX-OS poiché di solito la propagazione automatica avviene senza bisogno di alcun comando specifico.
I Route Reflector propagano quindi l’annuncio a tutti i propri RR-Client (ossia, gli switch Leaf), che quindi riceveranno due copie dell’annuncio BGP EVPN, una da ciascun Route Reflector.
Riportiamo di seguito, per motivi di spazio, una visualizzazione parziale degli annunci BGP EVPN (di tipo 5) ricevuti da Leaf-1. È mostrato infatti il dettaglio del solo annuncio ricevuto dal Route Reflector SP-1, annuncio che risulta essere best-path (NOTA: il perché l’annuncio visualizzato risulta il best path è un po’ sottile, dipende dal fatto che il BGP-RID di SP-1 (=192.168.1.1) è più basso del BGP-RID di SP-2 (=192.168.1.2). Ma attenzione, questo passo del processo di selezione viene a valle del confronto dell’Originator ID, che per entrambi gli annunci è però identico (= 192.168.0.4)).
Leaf-1# show bgp l2vpn evpn 192.0.2.0 vrf TENANT-TT
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 192.168.0.4:3
BGP routing table entry for [5]:[0]:[0]:[24]:[192.0.2.0]:[0.0.0.0]/224, version 9
Paths: (2 available, best #1)
Flags: (0x000002) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path
Imported to 2 destination(s)
AS-Path: 1234 , path sourced external to AS
192.168.54.4 (metric 81) from 192.168.1.1 (192.168.1.1)
Origin incomplete, MED not set, localpref 100, weight 0
Received label 31020
Extcommunity: RT:65001:31020 ENCAP:8 Router MAC:5012.0006.0007
Originator: 192.168.0.4 Cluster list: 192.168.1.1
. . . < resto dell’output omesso > . . .
L’annuncio contiene tre Extended Community:
- Una contiene il Route Target 65001:31020, che è determinato automaticamente dallo switch grazie alla configurazione "route-target both auto" all’interno della VRF TENANT-TT. Come già citato, il valore viene posto ad AS:L3VNI.
- La seconda contiene la BGP Encapsulation Extended Community definita nella RFC 5512. Il valore 8 indica l’incapsulamento VXLAN.
- La terza contiene il Router MAC Address di B-Leaf, pari a 5012.0006.0007.
Per concludere, riportiamo il risultato di un ping tra l’Host S-10-1 (IP = 10.0.10.1) e l’Host 192.0.2.1 parte della L3VPN estensione del tenant sulla rete IP/MPLS.
S-10-1> ping 192.0.2.1
84 bytes from 192.0.2.1 icmp_seq=1 ttl=251 time=40.280 ms
84 bytes from 192.0.2.1 icmp_seq=2 ttl=251 time=28.875 ms
84 bytes from 192.0.2.1 icmp_seq=3 ttl=251 time=24.921 ms
84 bytes from 192.0.2.1 icmp_seq=4 ttl=251 time=23.991 ms
84 bytes from 192.0.2.1 icmp_seq=5 ttl=251 time=24.133 ms
Di seguito è invece riportata la cattura, ottenuta via wireshark, del primo pacchetto ICMP Echo Request. La cattura è stata eseguita in uscita da Leaf-1.
Il pacchetto ICMP Echo request viene dapprima incapsulato in una trama Ethernet con MAC sorgente dell’interfaccia di uscita "e1/2" (=00:00:00:11:00:12) e MAC destinazione il Router MAC di B-Leaf (= 50:12:00:06:00;07). Quindi viene incapsulato in un pacchetto VXLAN con VNI 31020 (L3VNI), VTEP sorgente di Leaf-1 (= 192.168.0.1) e VTEP destinazione di B-Leaf (= 192.168.0.4).
Poiché sulla IP Fabric è abilitato di default l’Equal Cost Load Balancing (ECMP), l’algoritmo di Hash ha scelto come percorso il transito attraverso lo switch Spine SP-2, raggiungibile da Leaf-1 attraverso l’interfaccia "e1/2".
Per completezza riportiamo di seguito la cattura del pacchetto ICMP Echo Reply.
Lasciamo i dettagli di interpretazione al lettore. Vogliamo solo far notare che il pacchetto entra in Leaf-1 dall’interfaccia "e1/1" (MAC = 00:00:00:11:00:11). Questo significa che il traffico è asimmetrico, ma ciò non deve creare patemi d’animo, è un fatto normale nelle topologie Leaf-and-Spine.
FINE
S-10-1> ping 192.0.2.1
84 bytes from 192.0.2.1 icmp_seq=1 ttl=251 time=40.280 ms
84 bytes from 192.0.2.1 icmp_seq=2 ttl=251 time=28.875 ms
84 bytes from 192.0.2.1 icmp_seq=3 ttl=251 time=24.921 ms
84 bytes from 192.0.2.1 icmp_seq=4 ttl=251 time=23.991 ms
84 bytes from 192.0.2.1 icmp_seq=5 ttl=251 time=24.133 ms
Di seguito è invece riportata la cattura, ottenuta via wireshark, del primo pacchetto ICMP Echo Request. La cattura è stata eseguita in uscita da Leaf-1.
Poiché sulla IP Fabric è abilitato di default l’Equal Cost Load Balancing (ECMP), l’algoritmo di Hash ha scelto come percorso il transito attraverso lo switch Spine SP-2, raggiungibile da Leaf-1 attraverso l’interfaccia "e1/2".
Per completezza riportiamo di seguito la cattura del pacchetto ICMP Echo Reply.
Lasciamo i dettagli di interpretazione al lettore. Vogliamo solo far notare che il pacchetto entra in Leaf-1 dall’interfaccia "e1/1" (MAC = 00:00:00:11:00:11). Questo significa che il traffico è asimmetrico, ma ciò non deve creare patemi d’animo, è un fatto normale nelle topologie Leaf-and-Spine.
FINE
Nessun commento:
Posta un commento