Hola hab. Actualmente soy el líder del curso de "Ingeniero de redes" en OTUS.
En previsión del inicio de una nueva matrícula para el curso , he preparado una serie de artículos sobre la tecnología VxLAN EVPN.
Hay una gran cantidad de material sobre el funcionamiento de VxLAN EVPN, por lo que quiero recopilar varias tareas y prácticas para resolver problemas en un centro de datos moderno.
En la primera parte del ciclo de tecnología VxLAN EVPN, quiero considerar una forma de organizar la conectividad L2 entre hosts sobre una fábrica de red.
Todos los ejemplos se realizarán en Cisco Nexus 9000v, ensamblados en la topología Spine-Leaf. No nos detendremos en la configuración de la red Underlay en este artículo.
- red subyacente
- Emparejamiento BGP para la familia de direcciones l2vpn evpn
- configuración NVE
- suprimir-arp
red subyacente
La topología utilizada es la siguiente:
Configuremos el direccionamiento 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.20Comprobemos que hay conectividad IP entre todos los dispositivos:
Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 доступен чеерз два 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 доступен чеерз два 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 se haya creado el dominio de VPC y que ambos conmutadores hayan superado la verificación de coherencia y que la configuración en ambos nodos sea idéntica:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1Emparejamiento BGP
Finalmente, podemos pasar a configurar la red Overlay.
Como parte del artículo, es necesario organizar una red entre hosts, como se muestra en el siguiente diagrama:
Para configurar una red superpuesta, debe habilitar BGP en los conmutadores Spine y Leaf compatibles con la familia l2vpn evpn:
feature bgp
nv overlay evpnA continuación, debe configurar el emparejamiento BGP entre Leaf y Spine. Para simplificar la configuración y optimizar la distribución de la información de enrutamiento, configuramos Spine como un servidor Route-Reflector. Escribiremos todo Leaf en la configuración a través de plantillas para optimizar la configuración.
Entonces, 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 del interruptor Leaf es 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, verifique 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 puede ver, no hubo problemas con BGP. Pasemos a configurar VxLAN. La configuración adicional se realizará solo en el lado de los interruptores Leaf. Spine actúa solo como el núcleo de la red y solo está involucrado en la transmisión de tráfico. Todo el trabajo de encapsulación y definición de rutas solo se realiza en conmutadores Leaf.
configuración NVE
NVE - interfaz virtual de red
Antes de comenzar la instalación, introduzcamos algo de terminología:
VTEP: punto final del túnel virtual, el dispositivo en el que comienza o finaliza el túnel VxLAN. VTEP no es necesariamente cualquier dispositivo de red. También puede actuar 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 red dentro de VxLAN. Puede dibujar una analogía con VLAN. Sin embargo, hay algunas diferencias. Cuando se utiliza una estructura, las VLAN se vuelven únicas solo dentro de un conmutador Leaf y no se transmiten a través de la red. Pero cada VLAN se puede asociar con un número de VNI que ya se transmite a través de la red. Lo que parece y cómo se puede utilizar se discutirá a continuación.
Habilite la función para que funcione la tecnología VxLAN y la capacidad de asociar números de VLAN con un número de VNI:
feature nv overlay
feature vn-segment-vlan-basedConfiguremos la interfaz NVE, que es responsable del funcionamiento de VxLAN. Esta interfaz es responsable de encapsular tramas en encabezados VxLAN. Puede hacer una analogía con la interfaz Tunnel para GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0En el conmutador Leaf-21, todo se crea sin problemas. Sin embargo, si comprobamos la salida del comando show nve peers, entonces estará vacío. Aquí debe volver a la configuración de VPC. Vemos que Leaf-11 y Leaf-12 están emparejados y unidos por un dominio VPC. Esto da como resultado la siguiente situación:
Host-2 envía una trama a Leaf-21 para que se transmita a través de la red a Host-1. Sin embargo, Leaf-21 ve que la dirección MAC de Host-1 está disponible a través de dos VTEP a la vez. ¿Qué debería hacer Leaf-21 en este caso? Después de todo, esto significa que podría aparecer un bucle en la red.
Para resolver esta situación, necesitamos que Leaf-11 y Leaf-12 también actúen como un dispositivo dentro de la fábrica. Se resuelve de forma bastante sencilla. En la interfaz Loopback desde la que estamos construyendo el túnel, agregue la dirección secundaria. La dirección secundaria debe ser la misma en ambos VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryAsí, desde el punto de vista de otros VTEP, obtenemos la siguiente topología:
Es decir, ahora se construirá el túnel entre la dirección IP de Leaf-21 y la IP virtual entre dos Leaf-11 y Leaf-12. Ahora no habrá problemas para aprender la dirección MAC de dos dispositivos y el tráfico se puede transferir de un VTEP a otro. Cuál de los dos VTEP procesará el tráfico se decide utilizando 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 puede ver arriba, la dirección 10.255.1.10 está disponible inmediatamente a través de dos Next-hops.
En esta etapa, descubrimos la conectividad básica. Pasemos a configurar la interfaz NVE:
Inmediatamente habilitaremos Vlan 10 y lo asociaremos con VNI 10000 en cada Leaf para hosts. Configurar un túnel L2 entre hosts
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPAhora revisemos nve peers 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 ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об 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 rutas solo EVPN tipo de ruta 3. Este tipo de rutas habla de pares (Hoja), pero ¿dónde están nuestros hosts?
Y es que la información sobre los hosts MAC se transmite a través de la ruta EVPN tipo 2
Para ver nuestros hosts, debe configurar la ruta EVPN tipo 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoHagamos ping del Host-2 al Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msY debajo podemos ver que el tipo de ruta 2 apareció en la tabla BGP con la dirección MAC de los hosts: 5001.0007.0007 y 5001.0008.0007
Leaf11# 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 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 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
Route Distinguisher: 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, puede ver información detallada sobre la actualización, en la que recibió información sobre el MAC Host. A continuación no se muestra la salida completa del comando.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
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 labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>Veamos cómo quedan los marcos cuando pasan por la fábrica:
Suprimir-ARP
Genial, tenemos una conexión L2 entre los hosts y esto podría ser el final. Sin embargo, no todo es tan simple. Mientras tengamos pocos hosts, no habrá problemas. Pero imaginemos situaciones en las que tenemos cientos y miles de hosts. ¿Qué problema podemos enfrentar?
Este problema es el tráfico BUM (Broadcast, Unknown Unicast, Multicast). En el marco de este artículo, consideraremos la opción de combatir el tráfico de transmisión.
El principal generador de Broadcast en las redes Ethernet son los propios hosts a través del protocolo ARP.
Nexus implementa el siguiente mecanismo para gestionar las solicitudes ARP: suprimir-arp.
Esta característica funciona así:
- Host-1 envía una solicitud de APR a la dirección de difusión de su red.
- La solicitud llega al conmutador Leaf y, en lugar de pasar esta solicitud a la fábrica hacia el Host-2, Leaf responde por sí mismo e indica la IP y la MAC deseadas.
Por lo tanto, la solicitud de transmisión no fue a la fábrica. Pero, ¿cómo puede funcionar esto si Leaf solo conoce la dirección MAC?
Todo es bastante simple, la ruta EVPN tipo 2, además de la dirección MAC, puede transmitir un paquete MAC / IP. Para ello, el Leaf debe estar configurado con una dirección IP en la VLAN. Surge la pregunta, ¿qué IP pedir? En nexus, es posible crear una dirección distribuida (la misma) en todos los conmutadores:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macPor lo tanto, desde el punto de vista de los hosts, la red se verá así:
Compruebe BGP l2route evpn
Leaf11# 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.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
<......>
Route Distinguisher: 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 i
<......>A partir de la salida del comando, se puede ver que en la ruta EVPN tipo 2, además de la MAC, ahora también vemos la dirección IP del host.
Volvamos a la configuración de supresión de arp. Esta configuración está habilitada para cada VNI por separado:
interface nve1
member vni 10000
suppress-arpEntonces hay alguna dificultad:
- Esta función requiere espacio en la memoria de la TCAM. Daré un ejemplo de configuración para suprimir-arp:
hardware access-list tcam region arp-ether 256Esta configuración requerirá doble ancho. Es decir, si establece 256, entonces se debe liberar en TCAM 512. La configuración de TCAM está más allá del alcance de este artículo, ya que la configuración de TCAM depende solo de la tarea que se le asignó y puede diferir de una red a otra.
- La implementación de suprimir-arp debe realizarse en todos los conmutadores Leaf. Sin embargo, puede surgir una complejidad al configurar pares de hojas ubicados en un dominio de VPC. Al cambiar TCAM, la consistencia entre los pares se romperá y un nodo puede quedar fuera de servicio. Además, es posible que sea necesario reiniciar el dispositivo para aplicar la configuración de cambio de TCAM.
Como resultado, debe considerar cuidadosamente si vale la pena implementar esta configuración en una fábrica en funcionamiento en su situación.
Esto concluye la primera parte del ciclo. En la siguiente parte, consideraremos el enrutamiento a través de una fábrica de VxLAN con separación de red entre diferentes VRF.
Y ahora invito a todos a , en el que hablaré en detalle sobre el curso. Los primeros 20 participantes que se registren para este seminario web recibirán un Certificado de descuento por correo electrónico dentro de 1 a 2 días después de la transmisión.
Fuente: habr.com