fábrica VxLAN. Parte 3

Olá, Habr. Estou terminando uma série de artigos, dedicado ao lançamento do curso "Engenheiro de rede" por OTUS, usando tecnologia VxLAN EVPN para roteamento dentro da malha e usando Firewall para restringir o acesso entre serviços internos

As partes anteriores da série podem ser encontradas nos seguintes links:

• 1 parte do ciclo - conectividade L2 entre servidores
• Parte 2 da série – Roteamento entre VNIs
• Parte 2.5 da série – Digressão teórica

Hoje continuaremos a estudar a lógica de roteamento dentro da malha VxLAN. Na parte anterior, examinamos o roteamento intra-fabric dentro de um único VRF. Porém, pode haver um grande número de serviços de clientes na rede, e todos eles devem ser distribuídos em diferentes VRFs para diferenciar o acesso entre eles. Além da separação da rede, uma empresa pode precisar conectar um Firewall para restringir o acesso entre esses serviços. Sim, esta não pode ser considerada a melhor solução, mas as realidades modernas exigem “soluções modernas”.

Vamos considerar duas opções de roteamento entre VRFs:

1. Roteamento sem sair da malha VxLAN;
2. Roteamento em equipamentos externos.

Vamos começar com a lógica de roteamento entre VRFs. Há um certo número de VRFs. Para rotear entre VRFs, você precisa selecionar um dispositivo na rede que conheça todos os VRFs (ou partes entre as quais o roteamento é necessário).Tal dispositivo pode ser, por exemplo, um dos switches Leaf (ou todos de uma vez). . Esta topologia ficará assim:

Quais são as desvantagens desta topologia?

É isso mesmo, todo Leaf precisa saber sobre todos os VRFs (e todas as informações neles contidas) da rede, o que leva à perda de memória e ao aumento da carga da rede. Afinal, muitas vezes cada switch Leaf não precisa saber tudo o que está na rede.

No entanto, vamos considerar este método com mais detalhes, pois esta opção é bastante adequada para redes pequenas (se não houver requisitos específicos de negócios)

Neste ponto, você pode ter uma dúvida sobre como transferir informações de VRF para VRF, pois o objetivo dessa tecnologia é justamente que a disseminação de informações seja limitada.

E a resposta está em funções como exportação e importação de informações de roteamento (a configuração desta tecnologia foi considerada em segundo partes do ciclo). Deixe-me repetir brevemente:

Ao definir VRF em AF, você deve especificar route-target para informações de roteamento de importação e exportação. Você pode especificá-lo automaticamente. Então o valor incluirá o ASN BGP e o L3 VNI associado ao VRF. Isto é conveniente quando você tem apenas um ASN em sua fábrica:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Porém, se você tiver mais de um ASN e precisar transferir rotas entre eles, a configuração manual será uma opção mais conveniente e escalável. route-target. A recomendação para configuração manual é o primeiro número, use um que seja conveniente para você, por exemplo, 9999.
O segundo deve ser definido para ser igual ao VNI desse VRF.

Vamos configurá-lo da seguinte forma:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Como fica na tabela de roteamento:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Consideremos a segunda opção de roteamento entre VRFs - através de equipamentos externos, por exemplo Firewall.

Existem várias opções para trabalhar através de um dispositivo externo:

1. O dispositivo sabe o que é VxLAN e podemos adicioná-lo a parte da malha;
2. O dispositivo não sabe nada sobre VxLAN.

Não vamos nos alongar na primeira opção, pois a lógica será quase a mesma mostrada acima - trazemos todos os VRFs para o Firewall e configuramos o roteamento entre os VRFs nele.

Vamos considerar a segunda opção, quando nosso Firewall não sabe nada sobre VxLAN (agora, é claro, estão aparecendo equipamentos com suporte a VxLAN. Por exemplo, Checkpoint anunciou seu suporte na versão R81. Você pode ler sobre isso aqui, no entanto, tudo isso está em fase de testes e não há confiança na estabilidade da operação).

Ao conectar um dispositivo externo, obtemos o seguinte diagrama:

Como você pode ver no diagrama, aparece um gargalo na interface com o Firewall. Isto deve ser levado em consideração no futuro ao planejar a rede e otimizar o tráfego da rede.

Entretanto, voltemos ao problema original de roteamento entre VRFs. Como resultado da adição do Firewall, chegamos à conclusão de que o Firewall deve conhecer todos os VRFs. Para isso, todos os VRFs também devem estar configurados nos Leafs de borda, e o Firewall deve estar conectado a cada VRF com um link separado.

Como resultado, o esquema com Firewall:

Ou seja, no Firewall é necessário configurar uma interface para cada VRF localizado na rede. Em geral, a lógica não parece complicada e a única coisa que não gosto aqui é a enorme quantidade de interfaces no Firewall, mas aqui é hora de pensar em automação.

Multar. Conectamos o Firewall e adicionamos em todos os VRFs. Mas como podemos agora forçar o tráfego de cada Folha a passar por este Firewall?

No Leaf conectado ao Firewall não surgirão problemas, pois todas as rotas são locais:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

No entanto, e quanto aos Leafs remotos? Como passar para eles a rota externa padrão?

Isso mesmo, por meio da rota EVPN tipo 5, como qualquer outro prefixo na malha VxLAN. Porém, isso não é tão simples (se estamos falando da Cisco, pois não verifiquei com outros fornecedores)

A rota padrão deve ser anunciada a partir da Folha à qual o Firewall está conectado. Porém, para transmitir a rota, o próprio Leaf deve conhecê-la. E aqui surge um certo problema (talvez só para mim), a rota deve estar cadastrada estaticamente no VRF onde você deseja anunciar tal rota:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

A seguir, na configuração do BGP, defina esta rota no AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

No entanto, isso não é tudo. Desta forma a rota padrão não será incluída na família l2vpn evpn. Além disso, você precisa configurar a redistribuição:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Indicamos quais prefixos entrarão no BGP por meio de redistribuição

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Agora o prefixo 0.0.0.0/0 cai na rota EVPN tipo 5 e é transmitida para o resto da Folha:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

Na tabela BGP também podemos observar a rota tipo 5 resultante com a rota padrão via 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Isto conclui a série de artigos dedicados ao EVPN. Futuramente tentarei considerar a operação de VxLAN em conjunto com Multicast, já que este método é considerado mais escalável (no momento uma afirmação controversa)

Se você ainda tiver dúvidas/sugestões sobre o assunto, considere qualquer funcionalidade do EVPN - escreva, consideraremos isso mais adiante.

Fonte: habr.com