Ola Habr. Continúo coa serie de artigos sobre tecnoloxía VxLAN EVPN, que foron escritos expresamente para o lanzamento do curso por OTUS. E hoxe consideraremos unha parte interesante das tarefas: o enrutamento. Non importa o trillado que pareza, non obstante, como parte do traballo dunha fábrica de rede, pode que non todo sexa tan sinxelo.
Na última parte, conseguimos un dominio de difusión construído sobre un tecido de rede nun Nexus 9000v. Non obstante, esta non é toda a gama de tarefas que se deben resolver no marco da rede do centro de datos. E hoxe consideraremos a seguinte tarefa: enrutamento entre redes ou entre VNI.
Permíteme recordarche que se usa a topoloxía Spine-Leaf:
Para comezar, analizaremos como se produce o enrutamento e que características ten.
Para entendelo, simplifiquemos o diagrama lóxico e engadamos outro VNI 20000 para Host-2. O resultado é:
Como, neste caso, podes transferir tráfico dun Host a outro?
Existen dúas opcións:
- Manteña a información sobre todos os VNI en todos os conmutadores Leaf, entón todo o enrutamento producirase no primeiro Leaf da rede;
- Uso dedicado - L3 VNI
O primeiro xeito é sinxelo e cómodo. Xa que só precisa iniciar todos os VNI en todos os interruptores Leaf. Non obstante, executar algúns centos ou miles de VNI en toda a folla xa non parece unha tarefa fácil. Polo tanto, na obra úsase moi poucas veces.
Analizaremos o método 2, como máis interesante e algo máis complicado, pero que dá máis flexibilidade na configuración da fábrica.
Engademos "PROD" á topoloxía VRF. Engadímoslle a interface vlan 10 no par Leaf-11/12 e a interface VLAN 20 no Leaf-21. VLAN 20 está asociado con 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-gatewayPara usar L3VNI, cómpre crear unha nova VLAN, asociala co novo VNI. O novo VNI debe ser o mesmo en todos os Leafs interesados na información de 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 к определенному VRFComo resultado, o diagrama terá o seguinte aspecto:
Queda por rematar un pouco - engadir unha interface máis - interface vlan 99 en VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafComo resultado, a lóxica de pasar o marco de Host-1 a Host-2 é a seguinte:
- Unha trama enviada polo Host-1 chega a unha folla na VLAN 10, que está asociada con VNI 10000;
- Leaf comproba onde está o enderezo de destino e atópao a través de L3 VNI no segundo interruptor Leaf;
- Tan pronto como se atopa a ruta ao enderezo de destino, o Leaf embala o marco nunha cabeceira co L3VNI 99000 necesario e envíao cara á segunda folla;
- O segundo interruptor Leaf recibe datos de L3VNI 99000. Obtén o marco orixinal e transfire ao L2VNI 20000 necesario e despois á VLAN 20.
Como resultado deste traballo, L3VNI elimina a necesidade de manter a información sobre todos os VNI que están na rede en todos os conmutadores Leaf.
Como resultado, cando enviamos tráfico de Host-1 a Host-2, o paquete está empaquetado dentro de VxLAN co novo VNI - 99000:
Queda por ver como Leaf-1 aprende exactamente sobre o enderezo MAC doutro VNI. Isto tamén ocorre coa axuda do tipo de ruta EVPN 2 (MAC / IP).
O seguinte mostra o proceso de propagación dunha ruta sobre un prefixo situado noutro VNI:
É dicir, os enderezos recibidos de VNI 20000 teñen dous RT.
Permíteme lembrar que as rutas recibidas de Update caen na táboa BGP coa Ruta-destino especificada na configuración de VRF (o proceso é algo máis complicado, pero non entraremos neste artigo).
O propio RT está formado pola fórmula: AS:VNI (se se usa o modo automático).
Un exemplo de formación de RT en modos automático e manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTComo resultado, podes ver arriba que os prefixos doutro VNI teñen dous valores RT.
Un deles 65001:99000 é un VNI L3 adicional. Dado que este VNI é o mesmo en todas as follas e cae baixo as nosas regras de importación na configuración de VRF, o prefixo entra na táboa BGP, que se pode ver na saída:
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 observamos máis detidamente a actualización recibida, podemos ver que este prefixo ten dous 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
<......>Na táboa de enrutamento de Leaf-1, tamén podes ver o prefixo 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 99000Observa que falta o prefixo principal 192.168.20.0/24 na táboa de enrutamento?
É certo, non está alí. É dicir, as follas remotas só reciben información sobre os hosts que están na súa rede. E este é o comportamento correcto. Arriba, en todas as actualizacións, podes ver que a información vén co contido de MAC/IP. Non hai prefixos dos que falar.
Trátase do protocolo Host Mobility Manager (HMM), que enche a táboa ARP desde a que se enche aínda máis a táboa BGP (omitiremos este proceso no marco deste artigo). En base á información recibida do HMM, fórmanse EVPN de tipo de ruta 2 (transmitidos por MAC/IP).
Non obstante, que pasa se hai que pasar información sobre un prefixo?
Para este tipo de información, hai EVPN tipo de ruta 5: permítelle enviar prefixos a través da familia de enderezos l2vpn evpn (este tipo de ruta no momento de escribir este documento só está na versión borrador). , por iso, diferentes fabricantes poden ter un comportamento diferente deste tipo de ruta)
Para transferir prefixos, é necesario engadir prefixos no proceso BGP para VRF, que se anunciarán:
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 5Como resultado, a actualización será:
Vexamos a táboa BGP. Ademais do tipo de ruta EVPN 2,3, apareceron rutas tipo 5 que conteñen información sobre o número de rede:
<......>
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
<.......> O prefixo tamén apareceu na táboa de enrutamento:
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, hmmConclúe así a segunda parte dunha serie de artigos sobre VxLAN EVPN. Na seguinte parte, consideraremos varias opcións de enrutamento entre VRF.
Fonte: www.habr.com