Ciao, Habr. Attualmente sono il responsabile del corso "Ingegnere di rete" su OTUS.
In vista dell'inizio di un nuovo ciclo del corso , ho preparato una serie di articoli sulla tecnologia VxLAN EVPN.
Esistono numerosi materiali riguardanti l'uso di VxLAN EVPN, quindi voglio raccogliere diversi compiti e pratiche per la loro risoluzione nei moderni data center.
Nella prima parte della serie dedicata alla tecnologia VxLAN EVPN, voglio esaminare un modo per organizzare la connettività L2 tra gli host sopra una rete di tipo fabric.
Eseguiremo tutti gli esempi su Cisco Nexus 9000v, assemblati in una topologia Spine-Leaf. Non ci soffermeremo sulla configurazione della rete Underlay in questo articolo.
- Rete Underlay
- Piring BGP per address-family l2vpn evpn
- Configurazione NVE
- Supress-arp
Rete Underlay
La topologia utilizzata appare come segue:
Imposteremo l'indirizzamento 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.20Verifichiamo che ci sia connettività IP tra tutti i dispositivi:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 disponibile 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 disponibile 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, locale
*via 10.255.1.22, Lo0, [0/0], 00:02:20, diretto
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, intraVerifichiamo che il dominio VPC sia stato creato e che entrambi gli switch abbiano superato il controllo di coerenza e che la configurazione su entrambi i nodi sia identica:
Leaf11# mostra vpc
id dominio vPC : 1
Stato peer : adiacenza peer formata correttamente
Stato keep-alive vPC : il peer è attivo
Stato di coerenza della configurazione : successo
Stato di coerenza per vlan : successo
Stato di coerenza Type-2 : successo
Ruolo vPC : primario
Numero di vPC configurati : 0
Gateway peer : Disattivato
VLAN escluse da dual-active : -
Controllo di coerenza delicato : Attivato
Stato auto-recupero : Disattivato
Stato di ripristino ritardato : Timer spento. (timeout = 30s)
Stato SVI di ripristino ritardato : Timer spento. (timeout = 10s)
Router Layer3 operativo peer : Disattivato
stato vPC
----------------------------------------------------------------------------
Id Porta Stato Coerenza Motivazione VLAN attive
-- ------------ ------ ----------- ------ ---------------
5 Po5 attiva successo successo 1Pirinaggio BGP
Infine, è possibile passare alla configurazione della rete Overlay.
Nell'articolo è necessario organizzare la rete tra gli host, come mostrato nello schema sottostante:
Per configurare la rete Overlay è necessario abilitare BGP sullo switch Spine e Leaf con il supporto per la famiglia l2vpn evpn:
feature bgp
nv overlay evpnSuccessivamente, è necessario configurare il pirinaggio BGP tra Leaf e Spine. Per semplificare la configurazione e ottimizzare la diffusione delle informazioni di routing, configuriamo Spine come server Route-Reflector. Tutti i Leaf saranno impostati nel config tramite modelli, per ottimizzare la configurazione.
Le impostazioni su Spine appaiono in questo modo:
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 sullo switch Leaf appare in modo simile:
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 controlliamo il peering con tutti gli switch 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 possiamo vedere, non ci sono stati problemi con BGP. Passiamo alla configurazione di VxLAN. Le ulteriori configurazioni verranno effettuate solo sugli switch Leaf. Spine funge solamente da core della rete e si occupa solo del trasferimento del traffico. Tutto il lavoro di incapsulamento e determinazione del percorso avviene solo sugli switch 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 da cui inizia o termina un tunnel VxLAN. Un VTEP non deve necessariamente essere un dispositivo di rete. Può anche essere un server che supporta la tecnologia VxLAN. Nella nostra topologia, tutti gli switch Leaf sono VTEP.
VNI — Virtual Network Index — è l'identificatore di rete all'interno di VxLAN. Si può fare un'analogia con VLAN. Tuttavia, ci sono alcune differenze. Quando si utilizza una fabric, le VLAN diventano uniche solo all'interno di uno switch Leaf e non vengono propagate in rete. Tuttavia, ogni VLAN può essere associata a un numero VNI, che viene invece trasmesso in rete. Come appare e come può essere utilizzato sarà trattato successivamente.
Attiviamo la feature per il funzionamento della tecnologia VxLAN e la possibilità di associare numeri VLAN con il numero VNI:
feature nv overlay
feature vn-segment-vlan-basedConfiguriamo l'interfaccia NVE, che gestisce il funzionamento di VxLAN. Questa interfaccia si occupa effettivamente dell'incapsulamento dei frame negli header VxLAN. Si può fare un'analogia con l'interfaccia Tunnel utilizzata per GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! utilizziamo BGP per la trasmissione delle informazioni di routing
source-interface loopback0 ! interfaccia da cui inviamo i pacchetti loopback0Sullo switch Leaf-21 tutto si crea senza problemi. Tuttavia, se verifichiamo l'output del comando show nve peers, esso risulterà vuoto. Qui è necessario tornare alla configurazione del VPC. Possiamo vedere che Leaf-11 e Leaf-12 funzionano in coppia e sono uniti dal dominio VPC. Di conseguenza, si presenta la seguente situazione:
Host-2 invia un frame verso Leaf-21, affinché questo lo trasmetta in rete verso Host-1. Tuttavia, Leaf-21 vede che l'indirizzo MAC di Host-1 è accessibile tramite due VTEP. Come dovrebbe comportarsi Leaf-21 in questo caso? Questo significa che potrebbe essere presente un loop nella rete.
Per risolvere questa situazione, è necessario che Leaf-11 e Leaf-12 agiscano come un unico dispositivo all’interno della fabbrica. Questo si risolve piuttosto semplicemente. Sull'interfaccia Loopback, da cui costruiamo il tunnel, aggiungiamo un indirizzo secondario. L'indirizzo secondario deve essere identico su entrambi i VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryIn questo modo, dal punto di vista degli altri VTEP, otteniamo la seguente topologia:
Ora il tunnel sarà costruito tra l'indirizzo IP Leaf-21 e l'IP virtuale tra Leaf-11 e Leaf-12. Non ci saranno più problemi nell'apprendere l'indirizzo MAC di due dispositivi e il traffico potrà passare da un VTEP all'altro. Chi dei due VTEP gestirà il traffico è determinato dalla tabella di routing sullo 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.
In questa fase abbiamo esaminato la connettività di base. Passiamo alla configurazione dell'interfaccia NVE:
Attiviamo immediatamente il Vlan 10 e lo associamo al VNI 10000 su ogni Leaf per gli host. Configureremo 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 il funzionamento tramite l'interfaccia NVE, per l'incapsulamento in VxLAN
ingress-replication protocol bgp ! Indichiamo che utilizziamo BGP per la diffusione delle informazioni sugli hostOra controlliamo i peer NVE e la tabella per BGP EVPN:
Leaf21# sh nve peers
Interfaccia Peer-IP Stato Tipo di Apprendimento Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Attivo CP 00:00:41 n/a ! Vediamo che il peer è accessibile dall'indirizzo secondario
Leaf11# sh bgp l2vpn evpn
Rete Prossimo Hop Metri LocPrf Peso Percorso
Distinguishere di Routes: 10.255.1.11:32777 (L2VNI 10000) ! Da chi è arrivato esattamente questo l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! Il tipo di rotta EVPN 3 - mostra il nostro vicino che conosce anche l'l2VNI 10000
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
Distinguishere di Routes: 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 iQui sopra vediamo solo rotte EVPN of tipo 3. Questo tipo di rotte parla del peer (Leaf), ma dove sono i nostri host?
Il motivo è che le informazioni sui MAC degli host vengono trasmesse attraverso il tipo di rotta EVPN 2.
Per vedere i nostri host è necessario configurare il tipo di rotta EVPN 2:
evpn
vni 10000 l2
route-target import auto ! In questo articolo utilizziamo un numero automatico per il route-target
route-target export autoEseguiamo 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 possiamo vedere che nella tabella BGP sono apparsi route-type 2 con gli indirizzi MAC degli host — 5001.0007.0007 e 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Rete Prossimo 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 ! evpn route-type 2 e indirizzo mac host 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 e indirizzo mac 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
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 iIn seguito, è possibile visualizzare maggiori dettagli sull'Update, in cui abbiamo ottenuto informazioni sul MAC Host. Di seguito è riportato l'output non completo del comando
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informazioni sulla tabella di routing BGP per VRF predefinito, famiglia di indirizzi L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! ha inviato un aggiornamento con MAC Host. Non è un indirizzo virtuale VPC, ma l'indirizzo 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)
Flags: (0x000202) (high32 00000000) su xmit-list, non è in l2rib/evpn, non è in HW
Tipo di percorso: interno, il percorso è valido, non migliore motivo: Indirizzo vicino, nessun nexthop etichettato
AS-Path: NESSUNO, percorso originato internamente all'AS
10.255.1.10 (metrica 81) da 10.255.1.102 (10.255.1.102) ! con chi costruiamo esattamente il tunnel VxLAN
Origine IGP, MED non impostato, localpref 100, weight 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 possiamo vedere che il RT è stato generato automaticamente sulla base dei numeri AS e VNI
Creatore: 10.255.1.11 Lista cluster: 10.255.1.102Diamo un'occhiata a come appaiono i frame quando vengono trasmessi attraverso la fabbrica:
Suppress-ARP
Ottimo, abbiamo stabilito una connessione L2 tra gli host e su questo potremmo concludere. 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 incontrare?
Questo problema riguarda il traffico BUM (Broadcast, Unknown Unicast, Multicast). In questo articolo esploreremo un modo per combattere il traffico broadcast.
Il principale generatore di broadcast nelle reti Ethernet sono gli host stessi tramite il protocollo ARP.
Su Nexus è implementato il seguente meccanismo per combattere le richieste ARP: suppress-arp.
Il funzionamento di questa funzionalità è il seguente:
- Host-1 invia una richiesta ARP all'indirizzo broadcast della propria rete.
- La richiesta arriva allo switch Leaf e, invece di inoltrare questa richiesta verso la fabbrica in direzione di Host-2, lo switch Leaf risponde da solo specificando l'IP e il MAC necessari.
In questo modo, la richiesta broadcast non è andata alla fabbrica. Ma come può funzionare, dato che lo switch Leaf conosce solo l'indirizzo MAC?
È piuttosto semplice: il route-type 2 EVPN può trasmettere oltre all'indirizzo MAC anche la coppia MAC/IP. Per questo motivo, è necessario configurare un indirizzo IP nella VLAN sullo switch Leaf. La domanda è: quale IP impostare? Su Nexus è possibile creare un indirizzo distribuito (identico) su tutti gli switch:
interfaccia feature-vlan
forwarding fabric anycast-gateway-mac 0001.0001.0001 ! assegniamo mac virtuale per creare un gateway distribuito tra tutti gli switch
interfaccia Vlan10
no shutdown
indirizzo IP 192.168.10.254/24 ! impostiamo lo stesso IP su tutti i Leaf
modalità di forwarding fabric anycast-gateway ! diciamo di utilizzare il mac virtualePertanto, dal punto di vista degli host, la rete apparirà nel seguente modo:
Verifichiamo BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Rete Prossimo salto 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 evince che nel tipo di route EVPN 2, 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-arpA questo punto sorge una certa complessità:
- Per far funzionare questa funzionalità è necessario spazio nella memoria TCAM. Ecco un esempio di configurazione per suppress-arp:
hardware access-list tcam region arp-ether 256Per questa configurazione sarà necessaria una doppia larghezza. Quindi, se imposti 256, dovrai liberare 512 nella TCAM. La configurazione della TCAM esula dall'ambito di questo articolo, poiché dipende esclusivamente 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 difficoltà nella configurazione delle coppie di Leaf che si trovano nel dominio VPC. Quando si modifica la TCAM, la coerenza tra le coppie sarà compromessa e un nodo potrebbe essere disattivato. Inoltre, per applicare la modifica della TCAM potrebbe essere necessario riavviare il dispositivo.
Di conseguenza, è opportuno riflettere attentamente se nella tua situazione valga la pena implementare questa impostazione su una fabbrica in funzione.
Concludiamo qui la prima parte del ciclo. Nella prossima parte esamineremo il routing attraverso una fabbrica VxLAN con separazione delle reti in diverse VRF.
E ora invito tutti a , in cui parlerò dettagliatamente del corso. I primi 20 partecipanti che si registreranno per questo webinar riceveranno un certificato con uno sconto via email entro 1-2 giorni dopo la trasmissione.
Fonte: habr.com
