Hola, Habr. Continuo la sèrie d'articles sobre la tecnologia VxLAN EVPN, que van ser escrits específicament per a la posada en marxa del curs d'OTUS. I avui veurem una part interessant de la tasca: l'encaminament. Per molt trivial que sembli, però, en el marc del treball d'una fàbrica de xarxa, pot ser que no tot sigui tan senzill.
A l'última part, vam aconseguir un domini de difusió construït a la part superior del teixit de xarxa al Nexus 9000v. Tanmateix, aquesta no és tota la gamma de tasques que s'han de resoldre dins de la xarxa del centre de dades. I avui veurem la següent tasca: encaminament entre xarxes o entre VNI.
Us recordo que s'utilitza la topologia Spine-Leaf:
Primer, mirem com es produeix l'encaminament i quines característiques té.
Per entendre-ho, simplifiquem el diagrama lògic i afegim un altre VNI 20000 per a Host-2. El resultat és:
Com, en aquest cas, podeu transferir trànsit d'un host a un altre?
Hi ha dues opcions:
- Manteniu la informació sobre tots els VNI a tots els commutadors Leaf, tot l'encaminament es produirà al primer Leaf de la xarxa;
- Utilitzeu un VNI L3 dedicat
El primer mètode és senzill i còmode. Com que només cal instal·lar tots els VNI a tots els interruptors Leaf. Tanmateix, configurar diversos centenars o milers de VNI per a totes les fulles ja no sembla una tasca senzilla. Per tant, s'utilitza molt poques vegades a la feina.
Vegem el mètode 2, que és més interessant i una mica més complex, però que dóna més flexibilitat a l'hora de configurar la fàbrica.
Afegim "PROD" a la topologia VRF. Hi afegirem la interfície vlan 10 al parell Leaf-11/12 i la interfície VLAN 20 al Leaf-21. La VLAN 20 està associada amb 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 utilitzar L3VNI, heu de crear una nova VLAN i associar-la amb la nova VNI. El nou VNI ha de ser el mateix a tots els fulls interessats en la informació de VLAN 10 i 20
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFCom a resultat, el diagrama tindrà aquest aspecte:
Queda per fer una mica - afegir una interfície més - interfície vlan 99 a VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafCom a resultat, la lògica per passar una trama de l'amfitrió-1 a l'amfitrió-2 és la següent:
- La trama enviada per Host-1 arriba a Leaf a la VLAN 10, que està associada amb VNI 10000;
- Leaf comprova on és l'adreça de destinació i la troba a través de L3 VNI al segon commutador Leaf;
- Tan bon punt es troba una ruta a l'adreça de destinació, Leaf empaqueta el marc en una capçalera amb el L3VNI 99000 necessari i l'envia cap al segon Leaf;
- El segon commutador Leaf rep dades de L3VNI 99000. Pren el fotograma original i el transfereix al L2VNI 20000 requerit i després a la VLAN 20.
Com a resultat d'aquest treball, L3VNI elimina la necessitat de mantenir la informació sobre tots els VNI que es troben a la xarxa en tots els commutadors Leaf.
Com a resultat, quan enviem trànsit de l'amfitrió-1 a l'amfitrió-2, el paquet s'empaqueta dins de VxLAN amb un nou VNI - 99000:
Caldrà veure com exactament el Leaf-1 aprèn sobre l'adreça MAC d'un altre VNI. Això també passa amb el tipus de ruta EVPN 2 (MAC/IP).
A continuació es mostra el procés de propagació d'una ruta sobre un prefix situat en un altre VNI:
És a dir, les adreces rebudes de VNI 20000 tenen dues RT.
Us recordo que les rutes rebudes d'Actualització acaben a la taula BGP amb l'objectiu de ruta especificat a la configuració de VRF (el procés és una mica més complicat, però no aprofundirem en aquest article).
El propi RT es forma segons la fórmula: AS:VNI (si s'utilitza el mode automàtic).
Exemple de formació de RT en mode automàtic i manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTEl resultat anterior mostra que els prefixos d'un altre VNI tenen dos valors RT.
Un d'ells és 65001:99000: un VNI L3 addicional. Com que aquest VNI és el mateix a totes les fulles i es troba sota les nostres regles d'importació a la configuració de VRF, el prefix acaba a la taula BGP, que es pot veure a la sortida:
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 iSi mirem més de prop l'actualització rebuda, podem veure que aquest prefix té dos 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
<......>A la taula d'encaminament de Leaf-1 també podeu veure el prefix 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 99000Heu notat l'absència del prefix principal 192.168.20.0/24 a la taula d'encaminament?
És cert, ell no hi és. És a dir, els fulls remots només reben informació sobre els amfitrions que es troben a la vostra xarxa. I aquest és el comportament correcte. A dalt de totes les actualitzacions podeu veure que la informació inclou contingut MAC/IP. No es parla de cap prefix.
Així funciona el protocol Host Mobility Manager (HMM), que omple la taula ARP des de la qual s'omple la taula BGP (ometrem aquest procés als efectes d'aquest article). A partir de la informació rebuda de l'HMM, es forma la ruta tipus 2 EVPN (transmesa per MAC/IP).
Tanmateix, què passa si cal transmetre informació sobre un prefix?
Per a aquest tipus d'informació, hi ha EVPN ruta tipus 5: permet transmetre prefixos mitjançant l'adreça-família l2vpn evpn (aquest tipus de rutes en el moment d'escriure només es troba a la versió esborrany). , per això, el comportament d'aquest tipus de ruta pot diferir entre els diferents fabricants)
Per transmetre prefixos, cal afegir prefixos que s'anunciaran en el procés BGP per a VRF:
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 5Com a resultat, Update tindrà:
Mirem la taula BGP. A més de la ruta de tipus EVPN 2,3, han aparegut rutes de tipus 5, que contenen informació sobre el número de xarxa:
<......>
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
<.......> El prefix també apareixia a la taula d'encaminament:
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, hmmAixò conclou la segona part de la sèrie d'articles sobre VxLAN EVPN. A la següent part veurem diverses opcions d'encaminament entre VRF.
Font: www.habr.com