Oi Habr. Continuo a série de artigos sobre a tecnologia VxLAN EVPN, que foram escritos especificamente para o lançamento do curso por OTUS. E hoje vamos considerar uma parte interessante das tarefas - roteamento. Por mais banal que pareça, porém, como parte do trabalho de uma fábrica em rede, nem tudo pode ser tão simples.
Na última parte, alcançamos um domínio de broadcast construído sobre uma malha de rede em um Nexus 9000v. No entanto, essa não é toda a gama de tarefas que precisam ser resolvidas na estrutura da rede do data center. E hoje vamos considerar a seguinte tarefa - roteamento entre redes ou entre VNIs.
Deixe-me lembrá-lo de que a topologia Spine-Leaf é usada:
Para começar, analisaremos como ocorre o roteamento e quais recursos ele possui.
Para entender, vamos simplificar o diagrama lógico e adicionar outro VNI 20000 para Host-2. O resultado é:
Como, neste caso, você pode transferir o tráfego de um Host para outro?
Existem duas opções:
- Mantenha as informações sobre todos os VNIs em todos os switches Leaf, então todo o roteamento ocorrerá no primeiro Leaf da rede;
- Use dedicado - L3 VNI
A primeira maneira é simples e conveniente. Já que você só precisa iniciar todos os VNIs em todos os switches Leaf. No entanto, executar algumas centenas ou milhares de VNIs em toda a Folha não parece mais uma tarefa fácil. Portanto, no trabalho, é usado muito raramente.
Analisaremos o método 2, por ser mais interessante e um pouco mais complicado, porém dando mais agilidade na montagem da fábrica.
Vamos adicionar "PROD" à topologia VRF. Vamos adicionar a interface vlan 10 a ela no par Leaf-11/12 e a interface VLAN 20 no Leaf-21. VLAN 20 está associada com 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 o L3VNI, você precisa criar uma nova VLAN, associá-la à nova VNI. O novo VNI deve ser o mesmo em todos os Leafs interessados nas informações 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 ficará assim:
Resta terminar um pouco - adicionar mais uma interface - interface vlan 99 no VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafComo resultado, a lógica de passar o quadro do Host-1 para o Host-2 é a seguinte:
- Um quadro enviado pelo Host-1 chega a um Leaf na VLAN 10, que está associado ao VNI 10000;
- Leaf verifica onde está o endereço de destino e o encontra via L3 VNI no segundo switch Leaf;
- Assim que a rota para o endereço de destino é encontrada, o Leaf empacota o quadro em um cabeçalho com o L3VNI 99000 necessário - e o envia para o segundo Leaf;
- O segundo switch Leaf recebe dados do L3VNI 99000. Obtém o quadro original e o transfere para o L2VNI 20000 necessário e depois para a VLAN 20.
Como resultado deste trabalho, o L3VNI elimina a necessidade de manter as informações sobre todos os VNIs que estão na rede em todos os switches Leaf.
Como resultado, quando enviamos tráfego do Host-1 para o Host-2, o pacote é compactado dentro da VxLAN com o novo VNI - 99000:
Resta saber como exatamente o Leaf-1 aprende sobre o endereço MAC de outro VNI. Isso também acontece com a ajuda do tipo de rota EVPN 2 (MAC / IP).
Veja a seguir o processo de propagação de uma rota sobre um prefixo localizado em outro VNI:
Ou seja, os endereços recebidos do VNI 20000 possuem dois RTs.
Deixe-me lembrá-lo de que as rotas recebidas do Update caem na tabela BGP com o Route-target especificado nas configurações do VRF (o processo é um pouco mais complicado, mas não entraremos neste artigo).
O próprio RT é formado pela fórmula: AS:VNI (se for utilizado o modo automático).
Um exemplo de formação de RT nos modos automático e manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTComo resultado, você pode ver acima que os prefixos de outro VNI possuem dois valores RT.
Um deles 65001:99000 é um VNI L3 adicional. Como esse VNI é o mesmo em todos os Leafs e se enquadra em nossas regras de importação nas configurações do VRF, o prefixo entra na tabela BGP, que pode ser vista 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 olharmos mais de perto a atualização recebida, podemos ver que esse prefixo possui dois RTs:
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 tabela de roteamento no Leaf-1, você também pode 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 99000Observe o prefixo primário ausente 192.168.20.0/24 na tabela de roteamento?
Isso mesmo, ele não está lá. Ou seja, os Leafs remotos recebem informações apenas dos hosts que estão na sua rede. E este é o comportamento correto. Acima, em todas as atualizações, você pode ver que as informações acompanham o conteúdo do MAC/IP. Não há prefixos para falar.
Este é o protocolo Host Mobility Manager (HMM), que preenche a tabela ARP a partir da qual a tabela BGP é posteriormente preenchida (omitiremos este processo na estrutura deste artigo). Com base nas informações recebidas do HMM, são formados os EVPNs do tipo 2 de rota (transmitidos por MAC/IP).
Porém, e se houver a necessidade de passar informações sobre um prefixo?
Para este tipo de informação, existe o tipo de rota EVPN 5 - permite enviar prefixos via família de endereços l2vpn evpn (esse tipo de rota no momento da redação deste artigo está apenas na versão de rascunho , por conta disso, fabricantes diferentes podem ter comportamento diferente desse tipo de rota)
Para transferir prefixos, é necessário adicionar prefixos no processo BGP para VRF, que serão anunciados:
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 atualização será:
Vejamos a tabela BGP. Além do tipo de rota EVPN 2,3, apareceram rotas do tipo 5 que contêm informações sobre o número da 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 também apareceu na tabela de roteamento:
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, hmmIsso conclui a segunda parte de uma série de artigos sobre VxLAN EVPN. Na próxima parte, consideraremos várias opções de roteamento entre VRFs.
Fonte: habr.com