Hola, Habr. Actualmente soy el líder del curso "Ingeniero de Redes" en OTUS.
Con la próxima apertura del nuevo ciclo del curso , he preparado una serie de artículos sobre la tecnología VxLAN EVPN.
Hay una gran cantidad de materiales sobre cómo trabajar con VxLAN EVPN, por lo que quiero recopilar diversas tareas y prácticas para resolver problemas en un centro de datos moderno.
En la primera parte de la serie sobre la tecnología VxLAN EVPN, quiero examinar cómo organizar la conectividad L2 entre los hosts sobre la fábrica de red.
Todos los ejemplos se realizarán en Cisco Nexus 9000v, dispuestos en una topología Spine-Leaf. No abordaremos la configuración de la red Underlay en este artículo.
- Red Underlay
- Emparejamiento BGP para address-family l2vpn evpn
- Configuración de NVE
- Suprimir ARP
Red Underlay
La topología utilizada se muestra a continuación:
Asignemos las direcciones en todos los dispositivos:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Verifiquemos que hay conectividad IP entre todos los dispositivos:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 accesible a través de dos Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 accesible a través de dos Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraVerifiquemos que el dominio VPC se ha creado y que ambos conmutadores han pasado la verificación de consistencia y la configuración en ambos nodos es idéntica:
Leaf11# show vpc
vPC domain id : 1
Estado del par : la adyacencia del par se formó correctamente
Estado de keep-alive de vPC : el par está vivo
Estado de consistencia de configuración : éxito
Estado de consistencia por VLAN : éxito
Estado de consistencia tipo-2 : éxito
Rol de vPC : primario
Número de vPC configurados : 0
Puerta de enlace de par : Deshabilitada
VLANs excluidas para dual-active : -
Verificación de consistencia gradual : Habilitada
Estado de recuperación automática : Deshabilitada
Estado de restauración con retardo : El temporizador está apagado.(tiempo de espera = 30s)
Estado de SVI de restauración con retardo : El temporizador está apagado.(tiempo de espera = 10s)
Router capa 3 operativo del par : Deshabilitado
Estado de vPC
----------------------------------------------------------------------------
Id Puerto Estado Razón de Consistencia VLANs activas
-- ------------ ------ ----------- ------ ---------------
5 Po5 up éxito éxito 1Emparejamiento BGP
Finalmente, podemos proceder a la configuración de la red Overlay.
En el marco de este artículo, es necesario organizar una red entre los hosts, como se muestra en el esquema a continuación:
Para configurar la red Overlay, es necesario habilitar BGP con soporte para la familia l2vpn evpn en los conmutadores Spine y Leaf:
feature bgp
nv overlay evpnA continuación, debe configurarse el emparejamiento BGP entre Leaf y Spine. Para simplificar la configuración y optimizar la propagación de la información de rutas, configuramos Spine como Route-Reflector server. Registramos todos los Leaf en la configuración a través de plantillas para optimizar la configuración.
Así, la configuración en Spine se ve así:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFLa configuración en el conmutador Leaf se ve de manera similar:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINEEn Spine, verificamos el emparejamiento con todos los conmutadores Leaf:
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Como podemos ver, no ha habido problemas con BGP. Pasamos a la configuración de VxLAN. La configuración posterior solo se llevará a cabo en los conmutadores Leaf. Spine actúa únicamente como el núcleo de la red y solo se encarga de la transmisión del tráfico. Todo el trabajo de encapsulación y determinación de rutas ocurre únicamente en los conmutadores Leaf.
Configuración de NVE
NVE — interfaz virtual de red
Antes de comenzar la configuración, introduzcamos un poco de terminología:
VTEP — Punto de Terminación de Túnel Virtual, un dispositivo donde comienza o termina el túnel VxLAN. El VTEP no necesariamente tiene que ser un dispositivo de red. También puede ser un servidor que soporte la tecnología VxLAN. En nuestra topología, todos los conmutadores Leaf son VTEP.
VNI — Índice de Red Virtual — identificador de la red dentro de VxLAN. Se puede hacer una analogía con VLAN. Sin embargo, hay algunas diferencias. Al usar una fábrica, las VLAN se vuelven únicas solo dentro de un conmutador Leaf y no se transmiten por la red. Pero a cada VLAN se le puede asociar un número VNI, que ya se transmite por la red. Cómo se ve esto y cómo se puede utilizar se explicará más adelante.
Activemos la característica para el funcionamiento de la tecnología VxLAN y la posibilidad de asociar números VLAN con números VNI:
feature nv overlay
feature vn-segment-vlan-basedConfiguraremos la interfaz NVE, que se encarga del funcionamiento de VxLAN. Esta interfaz es la responsable de la encapsulación de tramas en los encabezados de VxLAN. Se puede hacer una analogía con la interfaz de túnel para trabajar con GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! usamos BGP para transmitir información de rutas
source-interface loopback0 ! interfaz desde la que enviamos paquetes loopback0En el conmutador Leaf-21, todo se crea sin problemas. Sin embargo, si comprobamos la salida del comando show nve peers, resultará vacío. Aquí es necesario volver a la configuración de VPC. Vemos que Leaf-11 y Leaf-12 están trabajando en pareja y están unidos por el dominio VPC. Desde aquí se genera la siguiente situación:
Host-2 envía un marco hacia Leaf-21 para que este lo transmita por la red hacia Host-1. Sin embargo, Leaf-21 observa que la dirección MAC de Host-1 es accesible a través de dos VTEP. ¿Cómo debería actuar Leaf-21 en este caso? Porque esto significa que podría haberse creado un bucle en la red.
Para resolver esta situación, necesitamos que Leaf-11 y Leaf-12 actúen como un solo dispositivo dentro de la fábrica. Esto se soluciona de manera bastante sencilla. En la interfaz Loopback desde la que construimos el túnel, agregamos una dirección secundaria. La dirección secundaria debe ser idéntica en ambos VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryDe este modo, desde la perspectiva de otros VTEP, obtenemos la siguiente topología:
Es decir, ahora el túnel se construirá entre la dirección IP de Leaf-21 y la IP virtual entre los dos Leaf-11 y Leaf-12. Ahora no habrá problemas para aprender la dirección MAC de los dos dispositivos y el tráfico podrá pasar de un VTEP a otro. Qué VTEP de los dos procesará el tráfico se decide mediante la tabla de enrutamiento en Spine:
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraComo se puede ver arriba, la dirección 10.255.1.10 está disponible a través de dos Next-hop.
En esta etapa hemos entendido la conectividad básica. Pasemos a la configuración de la interfaz NVE:
Activaremos inmediatamente el Vlan 10 y lo asociaremos con el VNI 10000 en cada Leaf para los hosts. Configuraremos un túnel L2 entre los hosts.
vlan 10 ! Activamos VLAN en todos los VTEP conectados a los hosts necesarios
vn-segment 10000 ! Asociamos VLAN con el número VNI
interface nve1
member vni 10000 ! Añadimos VNI 10000 para operar a través de la interfaz NVE. para encapsulación en VxLAN
ingress-replication protocol bgp ! indicamos que para la propagación de información sobre el host utilizamos BGPAhora revisaremos los pares nve y la tabla para BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Vemos que el peer está disponible desde la dirección secundaria
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! De quién vino exactamente este l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! Ruta EVPN tipo 3 - muestra a nuestro vecino, que también sabe sobre l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iArriba vemos que hay rutas solo de tipo EVPN 3. Este tipo de rutas habla de peer (Leaf), pero ¿dónde están nuestros hosts?
La cuestión es que la información sobre las direcciones MAC de los hosts se transmite a través de la ruta EVPN tipo 2.
Para ver nuestros hosts, es necesario configurar la ruta EVPN tipo 2:
evpn
vni 10000 l2
route-target import auto ! en este artículo utilizamos un número automático para el route-target
route-target export autoHaremos ping desde Host-2 a Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 bytes de datos
36 bytes desde 192.168.10.2: Host de destino inalcanzable
Request 0 timed out
64 bytes desde 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes desde 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes desde 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes desde 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msY abajo podemos ver que en la tabla BGP aparecieron rutas tipo 2 con direcciones MAC de los hosts — 5001.0007.0007 y 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Red Siguiente Salto Métrica LocPrf Peso Ruta
Identificador de Ruta: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216 ! tipo de ruta evpn 2 y dirección mac del host 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! tipo de ruta evpn 2 y dirección mac del host 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Identificador de Ruta: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iA continuación se puede ver información detallada sobre la actualización, en la que obtuvimos información sobre el Host MAC. A continuación se presenta no toda la salida del comando
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Información de la tabla de enrutamiento BGP para VRF por defecto, familia de direcciones L2VPN EVPN
Identificador de Ruta: 10.255.1.11:32777 ! envié una actualización con el Host MAC. No es una dirección virtual de VPC, sino la dirección Leaf
Entrada de la tabla de enrutamiento BGP para [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
versión 1507
Rutas: (2 disponibles, mejor #2)
Banderas: (0x000202) (high32 00000000) en la lista de transmisión, no está en l2rib/evpn, no está en HW
Tipo de ruta: interno, la ruta es válida, no mejor razón: Dirección de Vecino, sin nexthop etiquetado
AS-Path: NINGUNO, ruta fuente interna al AS
10.255.1.10 (métrica 81) de 10.255.1.102 (10.255.1.102) ! con quién estamos construyendo exactamente el túnel VxLAN
Origen IGP, MED no establecido, preferencia local 100, peso 0
Etiqueta recibida 10000 ! Número VNI, que está asociado con VLAN, en la que se encuentra el Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! aquí se puede ver que RT se formó automáticamente en función de los números AS y VNI
Originador: 10.255.1.11 Lista de clúster: 10.255.1.102Veamos cómo se ven los tramas cuando se transmiten a través de la fábrica:
Suprimir-ARP
Genial, ya tenemos conexión L2 entre los hosts y podríamos terminar aquí. Sin embargo, no todo es tan simple. Mientras tengamos pocos hosts no habrá problemas. Pero imaginemos situaciones en las que tengamos cientos o miles de hosts. ¿Con qué problema podríamos encontrarnos?
Este problema es el tráfico BUM (Broadcast, Unicast Desconocido, Multicast). En este artículo, abordaremos la lucha contra el tráfico broadcast.
El principal generador de Broadcast en redes Ethernet son los hosts mismos a través del protocolo ARP.
En el nexus se implementa el siguiente mecanismo para combatir las solicitudes ARP: suprimir-arp.
El funcionamiento de esta función es el siguiente:
- El Host-1 envía una solicitud APR a la dirección Broadcast de su red.
- La solicitud llega al conmutador Leaf y en lugar de transmitir esta solicitud más lejos a la fábrica en dirección al Host-2, el Leaf responde por sí mismo y proporciona la IP y MAC necesarias.
De esta manera, la consulta Broadcast no llegó a la fábrica. Pero, ¿cómo puede funcionar esto si Leaf solo conoce la dirección MAC?
Todo es bastante simple, el tipo de ruta EVPN 2, además de la dirección MAC, puede transmitir la combinación MAC/IP. Para esto, es necesario configurar una dirección IP en el VLAN en Leaf. Surge la pregunta, ¿qué IP asignar? En Nexus, hay la posibilidad de crear una dirección distribuida (igual) en todos los conmutadores:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! asignamos una MAC virtual para crear un gateway distribuido entre todos los conmutadores
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! asignamos la misma IP en todos los Leaf
fabric forwarding mode anycast-gateway ! indicamos usar la MAC virtualPor lo tanto, desde la perspectiva de los hosts, la red se verá de la siguiente manera:
Verifiquemos BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Red Siguiente salto Métrico LocPrf Peso Ruta
Descriptor de ruta: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.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.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Descriptor de ruta: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 iDe la salida del comando se puede ver que en el tipo de ruta EVPN 2, además de la MAC, ahora también vemos la dirección IP del host.
Regresamos a la configuración de suppress-arp. Esta configuración se activa para cada VNI individualmente:
interface nve1
member vni 10000
suppress-arpLuego surge cierta complejidad:
- Para que esta función funcione, es necesario contar con espacio en la memoria TCAM. A continuación, un ejemplo de configuración para suppress-arp:
hardware access-list tcam region arp-ether 256Para esta configuración, se necesitará doble ancho. Es decir, si asignas 256, en TCAM es necesario liberar 512. La configuración de TCAM excede el alcance de este artículo, ya que la configuración de TCAM depende únicamente de la tarea que se te asigne y puede diferir de una red a otra.
- La implementación de suppress-arp debe realizarse en todos los switches Leaf. Sin embargo, pueden surgir complicaciones al configurarlo en los pares Leaf dentro del dominio VPC. Al modificar el TCAM, la consistencia entre los pares se verá afectada y uno de los nodos puede quedar fuera de servicio. Además, para aplicar la configuración del cambio en el TCAM, es posible que se necesite reiniciar el dispositivo.
Como resultado, es necesario pensar bien si en su situación vale la pena implementar esta configuración en una fábrica en funcionamiento.
Con esto concluimos la primera parte del ciclo. En la siguiente parte, abordaremos el enrutamiento a través de la fábrica VxLAN con segregación de redes en diferentes VRF.
Ahora invito a todos a , en el cual explicaré detalladamente sobre el curso. Los primeros 20 participantes que se registren para este seminario web recibirán un Certificado de descuento en su correo electrónico dentro de 1-2 días después de la transmisión.
Fuente: habr.com
