🥇Fábrica VxLAN. Parte 3

Ola, Habr. Estou rematando unha serie de artigos, dedicado á posta en marcha do curso "Enxeñeiro de redes" por OTUS, usando a tecnoloxía VxLAN EVPN para o enrutamento dentro do tecido e usando Firewall para restrinxir o acceso entre servizos internos

As partes anteriores da serie pódense consultar nas seguintes ligazóns:

Hoxe continuaremos estudando a lóxica de enrutamento dentro do tecido VxLAN. Na parte anterior, analizamos o enrutamento intra-tecido dentro dun único VRF. Non obstante, pode haber un gran número de servizos de clientes na rede, e todos eles deben estar distribuídos en diferentes VRF para diferenciar o acceso entre eles. Ademais da separación da rede, é posible que unha empresa teña que conectar un Firewall para restrinxir o acceso entre estes servizos. Si, esta non se pode chamar a mellor solución, pero as realidades modernas requiren "solucións modernas".

Consideremos dúas opcións para o enrutamento entre VRF:

Enrutamento sen saír do tecido VxLAN;
Enrutamento en equipos externos.

Comecemos coa lóxica de enrutamento entre VRF. Hai un certo número de VRF. Para enrutar entre VRF, cómpre seleccionar un dispositivo da rede que coñeza todos os VRF (ou partes entre as que é necesario o enrutamento). Este dispositivo pode ser, por exemplo, un dos interruptores Leaf (ou todos á vez) . Esta topoloxía terá o seguinte aspecto:

Cales son as desvantaxes desta topoloxía?

É certo, cada Leaf necesita saber sobre todos os VRF (e toda a información que hai neles) na rede, o que leva á perda de memoria e ao aumento da carga da rede. Despois de todo, moitas veces cada interruptor Leaf non necesita saber todo o que hai na rede.

Non obstante, consideremos este método con máis detalle, xa que para redes pequenas esta opción é bastante adecuada (se non hai requisitos empresariais específicos)

Neste punto, pode ter unha pregunta sobre como transferir información de VRF a VRF, porque o punto desta tecnoloxía é precisamente que a difusión da información debe ser limitada.

E a resposta está en funcións como a exportación e importación de información de enrutamento (considerouse configurar esta tecnoloxía en segundo partes do ciclo). Permítanme repetir brevemente:

Ao configurar VRF en AF, debes especificalo route-target para importar e exportar información de rutas. Podes especificalo automaticamente. A continuación, o valor incluirá o ASN BGP e L3 VNI asociados ao VRF. Isto é conveniente cando só tes un ASN na túa fábrica:

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

Non obstante, se tes máis dunha ASN e necesitas transferir rutas entre elas, a configuración manual será unha opción máis cómoda e escalable. route-target. A recomendación para a configuración manual é o primeiro número, use un que sexa conveniente para vostede, por exemplo, 9999.
O segundo debe establecerse para igualar o VNI para ese VRF.

Configuramos o seguinte:

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 se ve na táboa de enrutamento:

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 opción para o enrutamento entre VRF: a través de equipos externos, por exemplo, Firewall.

Hai varias opcións para traballar a través dun dispositivo externo:

O dispositivo sabe o que é VxLAN e podemos engadilo a parte do tecido;
O dispositivo non sabe nada sobre VxLAN.

Non nos deteremos na primeira opción, xa que a lóxica será case a mesma que a mostrada arriba: levamos todos os VRF ao Firewall e configuramos o enrutamento entre os VRF nel.

Consideremos a segunda opción, cando o noso Firewall non sabe nada de VxLAN (agora, por suposto, aparecen equipos con soporte VxLAN. Por exemplo, Checkpoint anunciou o seu soporte na versión R81. Podes ler sobre iso). aquí, non obstante, todo isto está na fase de proba e non hai confianza na estabilidade do funcionamento).

Ao conectar un dispositivo externo, obtemos o seguinte diagrama:

Como podes ver no diagrama, aparece un pescozo de botella na interface co Firewall. Isto debe terse en conta no futuro á hora de planificar a rede e optimizar o tráfico da rede.

Non obstante, volvamos ao problema orixinal do enrutamento entre VRF. Como resultado de engadir o Firewall, chegamos á conclusión de que o Firewall debe coñecer todos os VRF. Para iso, todos os VRF tamén deben estar configurados no borde Leafs, e o Firewall debe estar conectado a cada VRF cunha ligazón separada.

Como resultado, o esquema con Firewall:

É dicir, no Firewall cómpre configurar unha interface para cada VRF situado na rede. En xeral, a lóxica non parece complicada e o único que non me gusta aquí é a gran cantidade de interfaces do Firewall, pero aquí é hora de pensar na automatización.

Ben. Conectamos o Firewall e engadímolo a todos os VRF. Pero como podemos agora forzar o tráfico de cada folla a pasar por este Firewall?

En Leaf conectado ao Firewall, non haberá problemas, xa que todas as rutas son locais:

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

Non obstante, que pasa cos Leafs remotos? Como pasarlles a ruta externa predeterminada?

Así é, a través do tipo de ruta EVPN 5, como calquera outro prefixo sobre o tecido VxLAN. Non obstante, isto non é tan sinxelo (se falamos de Cisco, xa que non comprobei con outros provedores)

A ruta predeterminada debe anunciarse desde a folla á que está conectado o Firewall. Porén, para transmitir a ruta, Leaf debe coñecela por si mesma. E aquí xorde un certo problema (quizais só para min), a ruta debe rexistrarse de forma estática no VRF onde quere anunciar tal ruta:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

A continuación, na configuración BGP, configure esta ruta en AF IPv4:

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

Non obstante, iso non é todo. Deste xeito a ruta predeterminada non se incluirá na familia l2vpn evpn. Ademais disto, cómpre configurar a redistribución:

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

Indicamos que prefixos entrarán en BGP mediante a redistribución

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 cae no tipo de ruta EVPN 5 e transmítese ao resto de Leaf:

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 táboa BGP tamén podemos observar a ruta-tipo 5 resultante coa ruta predeterminada a través de 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

Conclúe así a serie de artigos dedicados a EVPN. No futuro, intentarei considerar o funcionamento de VxLAN en conxunto con Multicast, xa que este método considérase máis escalable (de momento é unha declaración controvertida)

Se aínda tes preguntas/suxestións sobre o tema, considera calquera funcionalidade de EVPN: escribe, terémola en conta.

Fonte: www.habr.com

Fábrica VxLAN. Parte 3

Engadir un comentario Cancelar resposta