🥇Fábrica VxLAN. Parte 3

Olá, Habr. Estou finalizando um ciclo de artigos, dedicados ao lançamento do curso "Engenheiro de Redes" da OTUS, sobre a tecnologia VxLAN EVPN para roteamento dentro da fábrica e o uso de Firewall para limitar o acesso entre os serviços internos

As partes anteriores do ciclo podem ser encontradas nos links:

Hoje vamos continuar a explorar a lógica de roteamento dentro da fábrica VxLAN. Na parte anterior, examinamos o roteamento dentro da fábrica no âmbito de um único VRF. No entanto, na rede pode haver um grande número de serviços-clientes e todos precisam ser alocados em diferentes VRFs, para limitar o acesso entre eles. Além da segmentação de rede, as empresas podem precisar conectar um Firewall para restringir o acesso entre esses serviços. Sim, isso não pode ser considerado a melhor solução, mas as realidades modernas exigem "soluções modernas".

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

Roteamento, sem sair da fábrica VxLAN;
Roteamento em equipamentos externos.

Começaremos com a lógica de roteamento entre VRFs. Há um número definido de VRFs. Para rotear entre VRFs, é necessário alocar um dispositivo na rede que saiba sobre todos os VRFs (ou parte deles, entre os quais a roteação é necessária). Este dispositivo pode ser, por exemplo, um dos switches Leaf (ou todos de uma vez). Esta topologia será da seguinte forma:

Quais são as desvantagens dessa topologia?

Correto, cada Leaf deve saber sobre todos os VRFs (e todas as informações contidas neles) na rede, o que leva à perda de memória e ao aumento da carga na rede. Afinal, é bastante comum que cada switch Leaf não precise saber sobre tudo que existe na rede.

No entanto, vamos analisar esse método mais a fundo, pois para redes pequenas essa alternativa pode ser bastante adequada (caso não haja requisitos específicos do negócio)

Neste ponto, você pode se perguntar como transmitir informações de VRF para VRF, já que o sentido dessa tecnologia é exatamente que a disseminação das informações deve ser limitada.

E a resposta está em funções como export e import de informações de roteamento (a configuração dessa tecnologia foi discutida na o segundo parte do ciclo). Vou resumir rapidamente:

Ao definir um VRF em AF, é necessário indicar route-target para importação e exportação de informações de rota. Isso pode ser configurado automaticamente. Então, o valor conterá ASN BGP e L3 VNI, vinculado ao VRF. Isso é conveniente quando você tem apenas um ASN em sua fábrica:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! O RT-65001:99000 será exportado automaticamente
    route-target import auto

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

Vamos configurar 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         ! Exemplo 1 de importação de outro VRF
    route-target import 9999:88000         ! Exemplo 2 de importação de outro VRF

Como aparece na tabela de roteamento:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefix disponível através do L3VNI 99000

Vamos considerar a segunda opção de roteamento entre VRF — através de um dispositivo externo, por exemplo, um Firewall.

Podemos supor várias opções de operação através de um dispositivo externo:

O dispositivo sabe o que é VxLAN e podemos adicioná-lo à parte da fábrica;
O dispositivo nada sabe sobre VxLAN.

Não vamos parar na primeira opção, pois a lógica será praticamente a mesma que a mostrada acima — levamos todos os VRF ao Firewall e configuramos o roteamento entre VRF nele.

Vamos considerar a segunda opção, quando nosso Firewall não sabe nada sobre VxLAN (atualmente, é claro, estão surgindo dispositivos com suporte a VxLAN. Por exemplo, o Checkpoint anunciou seu suporte na versão R81. Você pode ler sobre isso aqui, no entanto, tudo isso está em fase de teste e não há certeza sobre a estabilidade do funcionamento).

Ao conectar um dispositivo externo, temos o seguinte esquema:

Como pode ser visto no esquema — há um ponto crítico na junção com o Firewall. É necessário levar isso em conta ao planejar a rede e otimizar o tráfego da rede.

No entanto, voltemos à tarefa inicial de roteamento entre VRF. Como resultado da adição do Firewall, chegamos ao ponto de que o Firewall deve estar ciente de todos os VRF. Para isso, todos os VRF também devem estar configurados nas Leaf de borda, e o Firewall deve ser conectado a cada VRF por meio de um link separado.

Como resultado, o esquema com o Firewall:

Ou seja, é necessário configurar a interface no Firewall em cada VRF presente na rede. No geral, a lógica não parece complicada e a única coisa que pode ser desagradável é a enorme quantidade de interfaces no Firewall, mas é hora de pensar na automação.

Certo. Conectamos o Firewall e o adicionamos a todos os VRFs. Mas como agora forçar o tráfego de cada Leaf a passar por esse Firewall?

No Leaf conectado ao Firewall, não haverá 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, estático       ! rota padrão através do Firewall

Mas como ficarão os Leaf remotos? Como passar a eles a rota externa padrão?

Correto, através do EVPN route-type 5, assim como qualquer outro prefixo na fábrica VxLAN. No entanto, isso não é tão simples (se falarmos sobre cisco, não verifiquei com outros vendedores)

A rota padrão deve ser anunciada pelo Leaf ao qual o Firewall está conectado. No entanto, para passar a rota, o Leaf deve conhecê-la. E aqui surge um certo problema (talvez só eu tenha), a rota precisa ser configurada estaticamente no VRF onde você deseja anunciar tal rota:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Em seguida, 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. Assim, a rota padrão não cairá na família l2vpn evpn. Além disso, é necessário 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

Especificamos quais prefixos irão para o BGP através da 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 é incluído no EVPN route-type 5 e é transmitido para os outros Leaf:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Endereço virtual Leaf (uma vez que os Leaves atuam como um par VPС), ao qual o Firewall está conectado

Na tabela BGP, também podemos observar o route-type 5 recebido com a rota padrão através do 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

Concluímos aqui o ciclo de artigos dedicados ao EVPN. No futuro, tentarei abordar o funcionamento do VxLAN em conjunto com o Multicast, uma vez que este método é considerado mais escalável (atualmente uma afirmação controversa).

Se você ainda tiver perguntas/sugestões sobre o tema ou quiser discutir alguma funcionalidade do EVPN — escreva, analisaremos com mais detalhes.

Fonte: habr.com