Ciao Habr. Continuo la serie di articoli sulla tecnologia VxLAN EVPN, che sono stati scritti appositamente per il lancio del corso di OTUS. E oggi considereremo una parte interessante dei compiti: il routing. Non importa quanto banale possa sembrare, tuttavia, come parte del lavoro di una fabbrica di rete, tutto può non essere così semplice.
Nell'ultima parte, abbiamo ottenuto un dominio di trasmissione costruito su un tessuto di rete su un Nexus 9000v. Tuttavia, questa non è l'intera gamma di attività che devono essere risolte nell'ambito della rete del data center. E oggi considereremo la seguente attività: instradamento tra reti o tra VNI.
Permettetemi di ricordarvi che viene utilizzata la topologia Spine-Leaf:
Per cominciare, analizzeremo come avviene il routing e quali caratteristiche ha.
Per capire, semplifichiamo il diagramma logico e aggiungiamo un altro VNI 20000 per Host-2. Il risultato è:
Come puoi, in questo caso, trasferire il traffico da un Host all'altro?
Ci sono due opzioni:
- Mantieni le informazioni su tutte le VNI su tutti gli switch Leaf, quindi tutto il routing avverrà sulla prima Leaf nella rete;
- Usa dedicato - L3 VNI
Il primo modo è semplice e conveniente. Dal momento che devi solo avviare tutti i VNI su tutti gli switch Leaf. Tuttavia, l'esecuzione di poche centinaia o migliaia di VNI sull'intero Leaf non sembra più un compito facile. Pertanto, nel lavoro è usato abbastanza raramente.
Analizzeremo il metodo 2, in quanto più interessante e leggermente più complicato, ma che offre maggiore flessibilità nell'allestimento della fabbrica.
Aggiungiamo "PROD" alla topologia VRF. Aggiungiamo l'interfaccia vlan 10 sulla coppia Leaf-11/12 e l'interfaccia VLAN 20 su Leaf-21. La VLAN 20 è associata alla VNI 20000
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayPer utilizzare L3VNI, è necessario creare una nuova VLAN, associarla alla nuova VNI. La nuova VNI deve essere la stessa su tutte le Leaf interessate alle informazioni VLAN 10 e 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFDi conseguenza, il diagramma sarà simile a questo:
Resta da finire un po ': aggiungi un'altra interfaccia - interfaccia vlan 99 in VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafDi conseguenza, la logica del passaggio del frame da Host-1 a Host-2 è la seguente:
- Un frame inviato da Host-1 arriva su una Leaf nella VLAN 10, che è associata alla VNI 10000;
- Leaf controlla dove si trova l'indirizzo di destinazione e lo trova tramite L3 VNI sul secondo switch Leaf;
- Non appena viene trovato il percorso verso l'indirizzo di destinazione, la Leaf impacchetta il frame in un'intestazione con il necessario L3VNI 99000 - e lo invia verso la seconda Leaf;
- Il secondo switch Leaf riceve i dati da L3VNI 99000. Ottiene il frame originale e lo trasferisce al L2VNI 20000 richiesto e quindi alla VLAN 20.
Come risultato di questo lavoro, L3VNI elimina la necessità di conservare le informazioni su tutti i VNI presenti sulla rete su tutti gli switch Leaf.
Di conseguenza, quando inviamo traffico da Host-1 a Host-2, il pacchetto viene impacchettato all'interno di VxLAN con il nuovo VNI - 99000:
Resta da vedere come esattamente Leaf-1 apprende l'indirizzo MAC da un altro VNI. Questo accade anche con l'aiuto di EVPN route-type 2 (MAC/IP).
Quanto segue mostra il processo di propagazione di un instradamento su un prefisso situato in un altro VNI:
Cioè, gli indirizzi ricevuti da VNI 20000 hanno due RT.
Permettetemi di ricordarvi che i percorsi ricevuti da Update rientrano nella tabella BGP con il Route-target specificato nelle impostazioni VRF (il processo è un po' più complicato, ma non entreremo in questo articolo).
L'RT stesso è formato dalla formula: AS:VNI (se si utilizza la modalità automatica).
Un esempio di formazione RT in modalità automatica e manuale:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTDi conseguenza, puoi vedere sopra che i prefissi di un'altra VNI hanno due valori RT.
Uno di questi 65001:99000 è un VNI L3 aggiuntivo. Poiché questo VNI è lo stesso su tutte le Leaf e rientra nelle nostre regole di importazione nelle impostazioni VRF, il prefisso entra nella tabella BGP, che può essere vista dall'output:
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.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iSe osserviamo più da vicino l'aggiornamento ricevuto, possiamo vedere che questo prefisso ha due RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
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 labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>Nella tabella di routing su Leaf-1, puoi anche vedere il prefisso 192.168.20.20/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000Notare il prefisso primario mancante 192.168.20.0/24 nella tabella di routing?
Esatto, lui non c'è. Cioè, i Leaf remoti ricevono informazioni solo sugli host che si trovano sulla tua rete. E questo è il comportamento corretto. Sopra, in tutti gli aggiornamenti, puoi vedere che le informazioni vengono fornite con il contenuto di MAC / IP. Non ci sono prefissi di cui parlare.
Questo è il protocollo Host Mobility Manager (HMM), che riempie la tabella ARP da cui viene ulteriormente riempita la tabella BGP (ometteremo questo processo nell'ambito di questo articolo). Sulla base delle informazioni ricevute dall'HMM, vengono formati EVPN di tipo route 2 (trasmessi da MAC/IP).
Tuttavia, cosa succede se è necessario trasmettere informazioni su un prefisso?
Per questo tipo di informazioni esiste EVPN route-type 5 - consente di inviare prefissi tramite address-family l2vpn evpn (questo tipo di route al momento in cui scriviamo è solo nella versione bozza , per questo motivo, diversi produttori possono avere un comportamento diverso di questo tipo di percorso)
Per trasferire i prefissi, è necessario aggiungere i prefissi nel processo BGP per VRF, che verrà pubblicizzato:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5Di conseguenza, Update sarà:
Diamo un'occhiata alla tabella BGP. Oltre al tipo di percorso EVPN 2,3, sono apparsi percorsi di tipo 5 che contengono informazioni sul numero di rete:
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> Il prefisso è apparso anche nella tabella di routing:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmQuesto conclude la seconda parte di una serie di articoli su VxLAN EVPN. Nella parte successiva, prenderemo in considerazione varie opzioni per l'instradamento tra VRF.
Fonte: habr.com
