Ciao, habr. Attualmente sono il responsabile del corso Network Engineer presso OTUS.
In attesa dell'inizio di una nuova iscrizione al corso , ho preparato una serie di articoli sulla tecnologia VxLAN EVPN.
Esiste un'enorme quantità di materiale su come funziona VxLAN EVPN, quindi voglio raccogliere varie attività e pratiche per risolvere i problemi in un data center moderno.
Nella prima parte della serie sulla tecnologia VxLAN EVPN, desidero esaminare un modo per organizzare la connettività L2 tra host su una struttura di rete.
Tutti gli esempi verranno eseguiti su un Cisco Nexus 9000v, assemblato nella topologia Spine-Leaf. Non ci soffermeremo sulla configurazione di una rete Underlay in questo articolo.
- Rete sottostante
- Peering BGP per la famiglia di indirizzi l2vpn evpn
- Configurazione NVE
- Sopprimi-arp
Rete sottostante
La topologia utilizzata è la seguente:
Impostiamo 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 доступен чеерз два 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 доступен чеерз два 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, intraVerifichiamo che il dominio VPC sia stato creato e che entrambi gli switch abbiano superato il controllo di coerenza e che le impostazioni su entrambi i nodi siano identiche:
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 1Peering BGP
Infine, puoi passare alla configurazione della rete Overlay.
Nell'ambito dell'articolo è necessario organizzare una rete tra host, come mostrato nello schema seguente:
Per configurare una rete Overlay, è necessario abilitare BGP sugli switch Spine e Leaf con supporto per la famiglia l2vpn evpn:
feature bgp
nv overlay evpnSuccessivamente, è necessario configurare il peering BGP tra Leaf e Spine. Per semplificare la configurazione e ottimizzare la distribuzione delle informazioni di routing, configuriamo Spine come server Route-Reflector. Scriveremo tutti i Leaf nella configurazione utilizzando modelli per ottimizzare la configurazione.
Quindi le impostazioni su Spine assomigliano a queste:
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 sull'interruttore Leaf è 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 puoi vedere, non ci sono stati problemi con BGP. Passiamo alla configurazione di VxLAN. L'ulteriore configurazione verrà eseguita solo sul lato foglia degli interruttori. Spine funge solo da nucleo della rete ed è coinvolta solo nella trasmissione 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 - Vitual Tunnel End Point, il dispositivo su cui inizia o termina il tunnel VxLAN. VTEP non è necessariamente un dispositivo di rete. Anche un server che supporta la tecnologia VxLAN può fungere da server. Nella nostra topologia, tutti gli switch Leaf sono VTEP.
VNI - Virtual Network Index: identificatore di rete all'interno di VxLAN. Si può tracciare un'analogia con la VLAN. Tuttavia, ci sono alcune differenze. Quando si utilizza una struttura, le VLAN diventano univoche solo all'interno di uno switch Leaf e non vengono trasmesse attraverso la rete. Ma a ciascuna VLAN può essere associato un numero VNI, che è già trasmesso sulla rete. Come appare e come può essere utilizzato verrà discusso ulteriormente.
Abilitiamo la funzionalità per il funzionamento della tecnologia VxLAN e la possibilità di associare numeri VLAN a un numero VNI:
feature nv overlay
feature vn-segment-vlan-basedConfiguriamo l'interfaccia NVE, che è responsabile del funzionamento di VxLAN. Questa interfaccia è responsabile dell'incapsulamento dei frame nelle intestazioni VxLAN. Puoi tracciare un'analogia con l'interfaccia Tunnel per GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Sullo switch Leaf-21 tutto viene creato senza problemi. Tuttavia, se controlliamo l'output del comando show nve peers, allora sarà vuoto. Qui è necessario tornare alla configurazione VPC. Vediamo che Leaf-11 e Leaf-12 funzionano in coppia e sono uniti da un dominio VPC. Questo ci dà la seguente situazione:
Host-2 invia un frame verso Leaf-21 in modo che lo trasmetta sulla rete verso Host-1. Tuttavia, Leaf-21 vede che l'indirizzo MAC dell'Host-1 è accessibile tramite due VTEP contemporaneamente. Cosa dovrebbe fare Leaf-21 in questo caso? Dopotutto, ciò significa che potrebbe verificarsi un loop nella rete.
Per risolvere questa situazione, abbiamo bisogno che anche Leaf-11 e Leaf-12 agiscano come un unico dispositivo all'interno della fabbrica. La soluzione è abbastanza semplice. Nell'interfaccia Loopback da cui costruiamo il tunnel, aggiungi un indirizzo secondario. L'indirizzo secondario deve essere lo stesso su entrambi i VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryPertanto, dal punto di vista degli altri VTEP, otteniamo la seguente topologia:
Cioè, ora verrà costruito il tunnel tra l'indirizzo IP della Leaf-21 e l'IP virtuale tra due Leaf-11 e Leaf-12. Ora non ci saranno problemi nell'apprendere l'indirizzo MAC da due dispositivi e il traffico potrà spostarsi da un VTEP all'altro. Quale dei due VTEP elaborerà il traffico viene deciso utilizzando la 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 puoi vedere sopra, l'indirizzo 10.255.1.10 è immediatamente disponibile attraverso due Next-hop.
In questa fase ci siamo occupati della connettività di base. Passiamo alla configurazione dell'interfaccia NVE:
Abilitiamo subito la Vlan 10 e associamola alla VNI 10000 su ogni Leaf per gli host. Impostiamo un tunnel L2 tra gli host
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPOra controlliamo 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 ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об 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 iSopra vediamo solo i percorsi EVPN di tipo 3. Questo tipo di percorso parla di peer(Leaf), ma dove sono i nostri host?
Il fatto è che le informazioni sugli host MAC vengono trasmesse tramite EVPN di tipo 2
Per vedere i nostri host, devi configurare il percorso EVPN di tipo 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoEseguiamo il ping da Host-2 a Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msE sotto possiamo vedere che il tipo di percorso 2 con l'indirizzo MAC host è apparso nella tabella BGP: 5001.0007.0007 e 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
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 и mac адрес хоста 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 и mac адрес хоста 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 iSuccessivamente, puoi visualizzare informazioni dettagliate su Aggiornamento, in cui hai ricevuto informazioni sull'host MAC. Di seguito non è riportato tutto l'output del comando.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>Vediamo come appaiono i frame quando passano attraverso la fabbrica:
Sopprimi ARP
Ottimo, ora abbiamo la comunicazione L2 tra gli host e potremmo finire lì. Tuttavia, non tutto è così semplice. Finché avremo pochi host non ci saranno problemi. Ma immaginiamo una situazione in cui abbiamo centinaia e migliaia di host. Quale problema potremmo dover affrontare?
Questo problema è il traffico BUM (Broadcast, Unknown Unicast, Multicast). In questo articolo considereremo l'opzione di gestire il traffico broadcast.
Il principale generatore di broadcast nelle reti Ethernet sono gli host stessi tramite il protocollo ARP.
Nexus implementa il seguente meccanismo per combattere le richieste ARP: sopprime-arp.
Questa funzione funziona come segue:
- Host-1 invia una richiesta APR all'indirizzo Broadcast della sua rete.
- La richiesta raggiunge lo switch Leaf e invece di inoltrarla ulteriormente al fabric verso Host-2, Leaf risponde da sola e indica l'IP e il MAC richiesti.
Pertanto, la richiesta Broadcast non è arrivata alla fabbrica. Ma come può funzionare se Leaf conosce solo l'indirizzo MAC?
Tutto è abbastanza semplice, l'EVPN route-type 2, oltre all'indirizzo MAC, può trasmettere una combinazione MAC/IP. Per fare ciò, è necessario configurare un indirizzo IP nella VLAN su Leaf. La domanda sorge spontanea: quale IP devo impostare? Su nexus è possibile creare un indirizzo distribuito (stesso) su tutti gli switch:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macPertanto, dal punto di vista degli host, la rete sarà simile a questa:
Controlliamo BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
<......>
Network Next Hop Metric LocPrf Weight Path
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 i
<......>Dall'output del comando puoi vedere che nella route EVPN di tipo 2, oltre al MAC, ora vediamo anche l'indirizzo IP dell'host.
Torniamo all'impostazione del soppressore-arp. Questa impostazione è abilitata per ogni VNI separatamente:
interface nve1
member vni 10000
suppress-arpQuindi sorge una certa complessità:
- Perché questa funzione funzioni, è necessario spazio nella memoria TCAM. Ecco un esempio di impostazioni per sopprimere-arp:
hardware access-list tcam region arp-ether 256Questa impostazione richiederà la doppia larghezza. Cioè, se imposti 256, in TCAM dovrai liberare 512. La configurazione di TCAM va oltre lo scopo di questo articolo, poiché la configurazione di TCAM dipende solo dall'attività assegnata e può differire da una rete all'altra.
- L'implementazione della soppressione dell'arp deve essere eseguita su tutti gli interruttori Leaf. Tuttavia, può verificarsi complessità durante la configurazione su coppie Leaf che risiedono in un dominio VPC. Se il TCAM viene modificato, la coerenza tra le coppie verrà interrotta e un nodo potrebbe essere messo fuori servizio. Inoltre, potrebbe essere necessario riavviare il dispositivo per applicare l'impostazione di modifica TCAM.
Di conseguenza, è necessario valutare attentamente se, nella propria situazione, valga la pena implementare questa impostazione in una fabbrica funzionante.
Questo conclude la prima parte della serie. Nella parte successiva esamineremo il routing attraverso una struttura VxLAN con la separazione delle reti in diversi VRF.
E ora invito tutti a farlo , all'interno del quale ti racconterò dettagliatamente il corso. I primi 20 partecipanti che si registreranno a questo webinar riceveranno un certificato di sconto via e-mail entro 1-2 giorni dalla trasmissione.
Fonte: habr.com