Ciao, Habr. Attualmente sono il responsabile del corso "Ingegnere di rete" in OTUS.
In attesa dell'avvio di un nuovo ciclo di corsi , ho preparato un ciclo di articoli sulla tecnologia VxLAN EVPN.
Esistono una grande quantità di materiali sul funzionamento di VxLAN EVPN, quindi voglio raccogliere diverse sfide e pratiche per risolvere problemi nei moderni data center.
Nella prima parte del ciclo sulla tecnologia VxLAN EVPN voglio esaminare il modo di organizzare la connettività L2 tra gli host sopra la rete di fabric.
Eseguirò tutti gli esempi su Cisco Nexus 9000v, costruiti in una topologia Spine-Leaf. Non ci soffermeremo sull'impostazione della rete Underlay in questo articolo.
- Rete Underlay
- Peer BGP per address-family l2vpn evpn
- Configurazione NVE
- Supress-arp
Rete Underlay
La topologia utilizzata appare come segue:
Definiamo gli indirizzi su tutti i dispositivi:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Controlliamo se c'è connettività IP tra tutti i dispositivi:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 accessibile tramite due Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 accessibile tramite due Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraControlliamo se il dominio VPC è stato creato e se entrambi gli switch hanno superato il controllo di coerenza e la configurazione su entrambe le nodi è identica:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1Peer BGP
Infine possiamo passare alla configurazione della rete Overlay.
Nell'ambito di questo articolo è necessario organizzare una rete tra gli host, come mostrato nello schema qui sotto:
Per configurare Overlay della rete, è necessario abilitare BGP con supporto per la famiglia l2vpn evpn sui commutatori Spine e Leaf:
feature bgp
nv overlay evpnSuccessivamente, è necessario configurare il peer BGP tra Leaf e Spine. Per semplificare la configurazione e ottimizzare la diffusione delle informazioni di routing, configuriamo Spine come Route-Reflector server. Tutti i Leaf saranno configurati attraverso template, per ottimizzare la configurazione.
Pertanto, la configurazione su Spine appare così:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFLa configurazione sul commutatore Leaf appare in modo analogo:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINESu Spine verifichiamo il peer con tutti i commutatori Leaf:
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Come vediamo, non ci sono problemi con BGP. Passiamo alla configurazione di VxLAN. La successiva configurazione verrà effettuata solo sul lato dei commutatori Leaf. Spine funge solamente da nucleo della rete e si occupa solo del trasferimento del traffico. Tutto il lavoro di incapsulamento e definizione del percorso avviene esclusivamente sui commutatori Leaf.
Configurazione NVE
NVE — interfaccia virtuale di rete
Prima di iniziare la configurazione, introduciamo un po' di terminologia:
VTEP — Virtual Tunnel End Point, il dispositivo dove inizia o termina il tunnel VxLAN. Il VTEP non è necessariamente un dispositivo di rete. Può anche essere un server che supporta la tecnologia VxLAN. Nella nostra topologia, tutti i commutatori Leaf sono VTEP.
VNI — Virtual Network Index — identificatore della rete nel contesto di VxLAN. Si può fare un'analogia con VLAN. Tuttavia, ci sono alcune differenze. Quando si utilizza una fabbrica, le VLAN diventano uniche solo nel contesto di un singolo commutatore Leaf e non vengono trasmesse in rete. Tuttavia, a ciascuna VLAN può essere associato un numero VNI, che viene poi trasmesso in rete. Vedremo come questo appare e come può essere utilizzato in seguito.
Attiviamo la funzione per l'operatività della tecnologia VxLAN e la possibilità di associare numeri VLAN al numero VNI:
feature nv overlay
feature vn-segment-vlan-basedConfiguriamo l'interfaccia NVE, che si occupa del funzionamento di VxLAN. Questa interfaccia è responsabile dell'incapsulamento dei frame negli header VxLAN. Si può fare un'analogia con l'interfaccia Tunnel per il funzionamento di GRE:
interfaccia nve1
no shutdown
protocol di raggiungibilità host bgp ! utilizziamo BGP per trasmettere informazioni di routing
source-interface loopback0 ! interfaccia da cui inviamo pacchetti loopback0Sullo switch Leaf-21, tutto viene creato senza problemi. Tuttavia, se controlliamo l'output del comando show nve peers, si presenterà vuoto. Qui è necessario tornare alla configurazione VPC. Vediamo che Leaf-11 e Leaf-12 lavorano in coppia e sono collegati dal dominio VPC. Da qui otteniamo la seguente situazione:
Host-2 invia un frame verso Leaf-21, affinché lo trasmetta attraverso la rete verso Host-1. Tuttavia, Leaf-21 vede che l'indirizzo MAC di Host-1 è disponibile tramite due VTEP. Come deve comportarsi Leaf-21 in questo caso? Questo significa che potrebbe esserci un loop nella rete.
Per risolvere questa situazione, è necessario che Leaf-11 e Leaf-12 si comportino come un'unica entità all'interno della fabbrica. Questo è piuttosto semplice da risolvere. Sull'interfaccia Loopback, da cui costruiamo il tunnel, aggiungiamo un indirizzo secondario. L'indirizzo secondario deve essere identico su entrambi i VTEP.
interfaccia loopback0
ip add 10.255.1.10/32 secondarioIn questo modo, dal punto di vista degli altri VTEP, otteniamo la seguente topologia:
Quindi ora il tunnel sarà costruito tra l'indirizzo IP di Leaf-21 e l'indirizzo IP virtuale tra i due Leaf-11 e Leaf-12. Non ci saranno più problemi nell'apprendere l'indirizzo MAC da due dispositivi e il traffico può passare da un VTEP all'altro. Chi dei due VTEP gestirà il traffico è determinato dalla tabella di routing su Spine:
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraCome si può vedere sopra, l'indirizzo 10.255.1.10 è accessibile tramite due Next-hop.
A questo punto abbiamo chiarito la connettività di base. Passiamo alla configurazione dell'interfaccia NVE:
Attiviamo subito il Vlan 10 e lo associamo al VNI 10000 su ciascun Leaf per gli host. Configuriamo un tunnel L2 tra gli host
vlan 10 ! Attiviamo il VLAN su tutti i VTEP collegati agli host necessari
vn-segment 10000 ! Associamo il VLAN con il numero VNI
interface nve1
member vni 10000 ! Aggiungiamo VNI 10000 per funzionare attraverso l'interfaccia NVE. per l'incapsulamento in VxLAN
ingress-replication protocol bgp ! Indichiamo che per la distribuzione delle informazioni sull'host utilizziamo BGPOra verifichiamo i peer nve e la tabella per BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Vediamo che il peer è accessibile con l'indirizzo secondario
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Da chi è arrivato esattamente questo l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - mostra il nostro vicino, che conosce anche l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iIn alto vediamo solo rotte EVPN route-type 3. Questo tipo di rotte parla del peer (Leaf), ma dove sono i nostri host?
La questione è che le informazioni sui MAC degli host vengono trasmesse tramite EVPN route-type 2
Per vedere i nostri host è necessario configurare l'EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! Nel contesto di questo articolo utilizziamo un numero automatico per il route-target
route-target export autoFacciamo un ping da Host-2 a Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 byte di dati
36 byte da 192.168.10.2: Host di destinazione irraggiungibile
Richiesta 0 scaduta
64 byte da 192.168.10.1: icmp_seq=1 ttl=254 tempo=215.555 ms
64 byte da 192.168.10.1: icmp_seq=2 ttl=254 tempo=38.756 ms
64 byte da 192.168.10.1: icmp_seq=3 ttl=254 tempo=42.484 ms
64 byte da 192.168.10.1: icmp_seq=4 ttl=254 tempo=40.983 msE qui sotto possiamo vedere che nella tabella BGP sono apparse rotte di tipo 2 con indirizzi MAC degli host — 5001.0007.0007 e 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Rete Prossimo Hop Metri LocPrf Peso Percorso
Distintore di percorso: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! tipo di percorso evpn 2 e indirizzo mac dell'host 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! tipo di percorso evpn 2 e indirizzo mac dell'host 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Distintore di percorso: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iIn seguito, è possibile visualizzare informazioni dettagliate sull'aggiornamento in cui abbiamo ricevuto informazioni sull'host MAC. Di seguito è riportato solo un'uscita della comando
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informazioni sulla tabella di routing BGP per VRF predefinito, famiglia di indirizzi L2VPN EVPN
Distintore di percorso: 10.255.1.11:32777 ! inviato aggiornamento con host MAC. Non è un indirizzo VPC virtuale, ma l'indirizzo del Leaf
Voce della tabella di routing BGP per [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
versione 1507
Percorsi: (2 disponibili, migliore #2)
Finestra: (0x000202) (high32 00000000) su xmit-list, non è in l2rib\/evpn, non è in HW
Tipo di percorso: interno, percorso valido, non è il miglior motivo: Indirizzo del vicino, nessun next-hop etichettato
AS-Path: NESSUNO, percorso generato internamente all'AS
10.255.1.10 (metrico 81) da 10.255.1.102 (10.255.1.102) ! con chi stiamo costruendo il tunnel VxLAN
Origine IGP, MED non impostato, pref locale 100, peso 0
Etichetta ricevuta 10000 ! Numero VNI associato al VLAN in cui si trova l'host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Qui si vede che il RT si è formato automaticamente sulla base dei numeri AS e VNI
Origine: 10.255.1.11 Lista cluster: 10.255.1.102Vediamo come appaiono i pacchetti quando vengono trasmessi attraverso la fabbrica:
Suppress-ARP
Ottimo, abbiamo stabilito una connessione L2 tra gli host e questo potrebbe essere considerato concluso. Tuttavia, non è tutto così semplice. Finché abbiamo pochi host non ci saranno problemi. Ma immaginiamo situazioni in cui abbiamo centinaia o migliaia di host. Quale problema potremmo affrontare?
Questo problema è il traffico BUM (Broadcast, Unknown Unicast, Multicast). In questo articolo considereremo una strategia per combattere il traffico broadcast.
Il principale generatore di Broadcast nelle reti Ethernet sono gli stessi host tramite il protocollo ARP.
Su nexus è implementato il seguente meccanismo per combattere le richieste ARP: suppress-arp.
Il funzionamento di questa funzione è il seguente:
- Host-1 invia una richiesta ARP all'indirizzo Broadcast della propria rete.
- La richiesta arriva allo switch Leaf e, invece di inoltrare la richiesta ulteriormente nella fabbrica verso Host-2, il Leaf risponde da solo indicandogli l'IP e il MAC desiderati.
In questo modo la richiesta Broadcast non è stata inviata alla fabbrica. Ma come può funzionare se il Leaf conosce solo l'indirizzo MAC?
È abbastanza semplice, il route-type 2 di EVPN oltre all'indirizzo MAC può trasmettere una coppia MAC/IP. Per questo sul Leaf è necessario configurare un indirizzo IP nella VLAN. Si pone la domanda, quale IP impostare? Sui Nexus è possibile creare un indirizzo distribuito (uguale) su tutti gli switch:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! impostiamo il mac virtuale per la creazione di un gateway distribuito tra tutti gli switch
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! impostiamo lo stesso IP su tutti i Leaf
fabric forwarding mode anycast-gateway ! diciamo di usare il mac virtualeIn questo modo, dal punto di vista degli host, la rete apparirà nel seguente modo:
Verifichiamo BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Rete Next Hop Metri LocPrf Peso Percorso
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
* >l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
* >i[2]:[0]:[0]:[48]:[5001.0008.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.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
* >i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
* >i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
* >i 10.255.1.20 100 0 iDall'output del comando si vede che nel route-type 2 di EVPN, oltre al MAC, ora vediamo anche l'indirizzo IP dell'host.
Torniamo alla configurazione di suppress-arp. Questa impostazione viene attivata per ogni VNI separatamente:
interface nve1
member vni 10000
suppress-arpSuccessivamente si presenta una certa complessità:
- Per il funzionamento di questa funzione è necessario spazio nella memoria TCAM. Fornirò un esempio di configurazione per suppress-arp:
hardware access-list tcam region arp-ether 256Per questa configurazione sarà necessario un double-wide. Quindi, se imposti 256, dovrai liberare 512 in TCAM. La configurazione del TCAM va oltre l'ambito di questo articolo, poiché la configurazione del TCAM dipende solo dal compito che ti è stato assegnato e può variare da una rete all'altra.
- L'implementazione di suppress-arp deve essere effettuata su tutti gli switch Leaf. Tuttavia, potrebbero sorgere delle complessità nella configurazione delle coppie di Leaf, che si trovano nel dominio VPC. Quando si modifica il TCAM, la coerenza tra le coppie sarà compromessa e un nodo potrebbe andare offline. Inoltre, per applicare le modifiche al TCAM potrebbe essere necessario riavviare il dispositivo.
Di conseguenza, è consigliabile riflettere attentamente se in questa situazione valga la pena implementare questa configurazione su un impianto in funzione.
Concludiamo qui la prima parte del ciclo. Nella prossima parte esamineremo il routing attraverso l'impianto VxLAN con separazione delle reti in diversi VRF.
E ora invito tutti a , durante il quale parlerò in dettaglio del corso. I primi 20 partecipanti che si registreranno a questo webinar riceveranno un Certificato di sconto via email entro 1-2 giorni dopo la trasmissione.
Fonte: habr.com
