Cómo un fabric EVPN sabe dónde está su servidor

Una red conmutada clásica encuentra un servidor gritando: inunda la trama por todas partes, mira quién responde, recuerda el puerto. Un fabric BGP EVPN lo encuentra porque se lo dicen. Esa única diferencia explica por qué los fabrics EVPN escalan, conmutan deprisa y pueden auditarse, y merece la pena entenderla aunque nunca configure uno usted mismo.

El problema de inundar y aprender

La capa 2 tradicional aprende las direcciones MAC del tráfico. Cuando un switch no sabe dónde vive un destino, inunda la trama por todos los puertos de la VLAN. Spanning tree bloquea entonces suficientes enlaces para que la inundación no circule en bucle para siempre, lo que significa que una buena parte del cableado que pagó se queda ocioso. Estire esa VLAN por muchos racks y obtiene grandes dominios de fallo, convergencia lenta y una red que nadie puede describir del todo, porque su estado vive en tablas que se llenan y caducan por su cuenta.

VXLAN por sí solo arregla el problema del transporte: envuelve tramas Ethernet en UDP para que un segmento de capa 2 pueda cruzar un underlay enrutado con todos los enlaces activos. Pero VXLAN a secas sigue inundando para aprender. EVPN sustituye ese aprendizaje por un plano de control.

Qué anuncia EVPN realmente

EVPN es una familia de direcciones de BGP. Cada switch leaf que aloja servidores actúa como extremo de túnel VXLAN (VTEP) y cuenta a los demás leaves lo que sabe, usando un pequeño número de tipos de ruta. Tres de ellos hacen la mayor parte del trabajo:

• Tipo 2, anuncio de MAC e IP. Cuando un servidor envía su primera trama o ARP, el leaf local aprende su MAC (y normalmente su IP) y la anuncia a todos los demás leaves con su propia dirección VTEP como siguiente salto. Todos los leaves saben ahora dónde está ese servidor sin una sola inundación.
• Tipo 3, inclusive multicast. Cada leaf anuncia en qué segmentos participa. Esto construye la lista de VTEP que deben recibir el tráfico broadcast y de destino desconocido de cada segmento. Con ingress replication el leaf emisor hace una copia unicast para cada uno de ellos, de modo que el underlay no necesita multicast en absoluto.
• Tipo 5, prefijo IP. Las subredes enrutadas, por ejemplo un bloque de direcciones públicas detrás del firewall de un cliente, se anuncian como prefijos dentro de un VRF de tenant.

Los route targets deciden quién importa qué. Las rutas de un segmento llevan su route target, y solo los leaves configurados con ese target las importan. Aquí es donde se impone realmente el aislamiento entre tenants, y por eso la numeración de segmentos y route targets merece una disciplina real (más sobre esto abajo).

Anycast gateways: el mismo router en todas partes

En un fabric EVPN, cada leaf que lleva un segmento puede ser su gateway por defecto, usando la misma IP y la misma MAC virtual. El primer salto de un servidor es siempre el switch al que está conectado. Si ese leaf falla, el bond del servidor conmuta al otro leaf del par, que ya responde en la misma dirección y la misma MAC de gateway. Nada cambia en el servidor, ningún protocolo de gateway tiene que elegir a nadie, y las cargas de trabajo pueden moverse entre racks conservando su gateway.

Combinado con pares de leaves que ejecutan virtual port-channels, esto da a cada host dos switches físicos detrás de un único bond lógico. En NX-OS un anycast gateway mínimo tiene este aspecto:

fabric forwarding anycast-gateway-mac 0000.2222.3333
interface Vlan210
  vrf member TENANT-A
  ip address 192.0.2.1/26
  fabric forwarding mode anycast-gateway

Localizar un host: los comandos que importan

Cuando algo no llega adonde debería, estos son los comandos con los que empezamos en Cisco Nexus, más o menos en este orden:

show nve peers                         ! are the other VTEPs up?
show nve vni                           ! is the segment up, control plane learning?
show l2route evpn mac all              ! which MACs are local, which are remote, and from which peer
show bgp l2vpn evpn <mac-or-ip>        ! the actual route, its RD, RT and next hop
show ip arp suppression-cache detail   ! is ARP being answered locally?
show vpc consistency-parameters vlans  ! do both leaves of the pair agree?

La historia que cuentan suele ser corta. Una MAC que es local en un leaf pero nunca aparece en BGP en los demás apunta al aprendizaje local o a la configuración del segmento. Una ruta que está presente pero no se importa apunta a los route targets. Un VTEP que falta en show nve peers apunta al underlay. Leer así el estado del fabric solo es posible porque EVPN guarda ese estado en BGP, donde es visible y consistente, en lugar de en tablas aprendidas por inundación.

La numeración es un control de seguridad

Cada segmento necesita un identificador de red VXLAN (VNI) y route targets, y el fabric aceptará cualquier número que teclee. Dos segmentos que comparten un identificador por accidente quedan puenteados, en silencio, y un VNI mal tecleado que resulta pertenecer a otro segmento parece perfectamente legítimo en todas las pantallas.

La defensa es una regla y una máquina que la comprueba. Elija una derivación fija, por ejemplo VNI igual a un desplazamiento fijo más el número de VLAN local, con los route targets derivados del VNI, y después verifíquelo automáticamente:

• Lea el mapa de VLAN a VNI de cada leaf con una periodicidad.
• Confirme que cada entrada obedece la regla.
• Confirme que cada leaf que debería llevar los mismos segmentos lleva mapas idénticos.
• Compare una huella del mapa completo con una referencia firmada en control de versiones, de modo que un cambio intencionado necesite una nueva firma deliberada con un autor, y uno no intencionado avise a un ingeniero.

Nosotros ejecutamos exactamente esta comprobación contra nuestro fabric cada hora. Cuesta unos segundos de acceso de solo lectura y convierte una clase de errores invisibles en una alarma.

Qué preguntar sobre su propio fabric

• ¿Son sus gateways anycast en cada leaf, o los posee un solo par de switches?
• ¿Está cada host conectado a dos leaves de un par, o solo los caros?
• ¿Hacen los hosts con bond el hash sobre capa 3 y capa 4, con el lado del switch igualado, para que ambos enlaces lleven tráfico de verdad?
• ¿Hay una regla escrita para la numeración de VNI y route targets, y hay algo que la imponga?
• ¿Puede un ingeniero mostrarle, con comandos como los de arriba, exactamente dónde vive su servidor y cómo sale su tráfico del rack?

Si quiere sus servidores en un fabric construido y comprobado así, o quiere ayuda para leer el suyo, con gusto le ayudamos.

CTA

Hable con un ingeniero

Related

Relacionado: Fabric del datacenter: EVPN/VXLAN sobre Cisco Nexus · Cómo cambiamos las cosas: disciplina de cambios en la red · Múdese a nosotros sin renumerar: extensión de capa 2