Dos circuitos, un router: DMVPN de doble nube que usa ambos enlaces

La mayoría de las sedes con dos circuitos WAN usan uno. El segundo se queda de respaldo, pagado cada mes y ejercitado solo cuando el primero falla, que es también la primera vez que alguien descubre si el failover funciona de verdad. Con DMVPN y BGP puede usar ambos circuitos todo el tiempo, conmutar entre ellos sin pensarlo y demostrar que los dos llevan tráfico. Este es el método.

Un repaso rápido a DMVPN

Nosotros ejecutamos BGP sobre DMVPN (mGRE, NHRP, IPsec), de modo que añadir o perder una sede es un evento de enrutamiento y no una reconfiguración.

El diseño habitual para la redundancia son dos hubs en una nube. Eso protege frente al fallo de un hub. No hace nada por un spoke con dos circuitos, porque la única interfaz de túnel del spoke tiene su origen en uno de ellos.

El diseño de doble nube

La solución es una segunda nube DMVPN independiente, con origen en el segundo circuito. La objeción habitual es que implica nuevas direcciones públicas, nuevas reglas de firewall y nueva configuración de hub. No tiene por qué, si separa las nubes con una tunnel key. GRE lleva la clave en su cabecera, así que el hub puede terminar dos túneles multipunto en la misma interfaz física y la misma dirección pública y seguir distinguiéndolos.

En el hub, la segunda nube es una copia de la primera con su propia subred de túnel, su network ID de NHRP y su clave:

interface Tunnel1
 ip address 10.10.1.1 255.255.255.0
 ip nhrp network-id 1
 ip nhrp authentication 
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile DMVPN-PROF shared
!
interface Tunnel2
 ip address 10.10.2.1 255.255.255.0
 ip nhrp network-id 2
 ip nhrp authentication 
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 2
 tunnel protection ipsec profile DMVPN-PROF shared

La palabra clave shared en el perfil de protección importa cuando dos túneles comparten origen: sin ella, las asociaciones de seguridad IPsec de los dos túneles colisionan.

En el spoke, Tunnel1 tiene su origen en el primer circuito y Tunnel2 en el segundo, cada uno apuntando a la misma dirección de hub con su propia clave. Nada cambia para ningún otro spoke.

Haga que el enrutamiento use los dos

Dos túneles le dan dos sesiones BGP con el hub, y por tanto dos caminos hacia cada destino. Por defecto BGP sigue eligiendo uno. Dos ajustes lo cambian:

router bgp 65010
 address-family ipv4
  maximum-paths 2
  maximum-paths ibgp 2

Ambas sesiones deberían caer en la misma tabla de enrutamiento para que los caminos sean genuinamente iguales. Después asegúrese de que el hash de reenvío reparte flujos en lugar de pares completos de origen y destino. Un hash que incluye los puertos de capa 4 pone los flujos paralelos entre los mismos dos hosts en circuitos distintos, que es lo que quiere para backups y replicación:

ip cef load-sharing algorithm include-ports source destination

Demuéstrelo, no lo suponga

Un show ip route que lista dos next hops demuestra que el multipath está configurado. No demuestra que el tráfico esté usando ambos circuitos. La única prueba aceptable es un test de caudal con varios flujos paralelos que consiga en cada sentido más de lo que cualquiera de los dos circuitos podría llevar por sí solo, mientras observa los contadores de ambas interfaces físicas subir a la vez:

iperf3 -c  -P 8 -t 60
iperf3 -c  -P 8 -t 60 -R
show interfaces GigabitEthernet0/0/1 | include rate
show interfaces GigabitEthernet0/0/2 | include rate

Si una interfaz hace todo el trabajo, mire el hash y si ambos caminos BGP están realmente instalados.

Dimensione por el motor criptográfico, no por la licencia

Todo router tiene una cifra de caudal licenciado y un techo real de cifrado, y no son lo mismo. El techo depende del hardware criptográfico, del tamaño de los paquetes y de cuánto más esté haciendo el router. Mídalo con tráfico realista, no con el tamaño de paquete óptimo de una hoja de datos, y dimensione contra lo que midió.

En nuestra troncal esa cifra medida es de unos 11 Gbit/s de tráfico cifrado por hub. Cuando un cliente necesita más entre sedes, no esperamos a una caja más grande: repartimos el tráfico entre varios hubs con multipath de igual coste, lo que lleva la capacidad cifrada a 30 a 40 Gbit/s. El mismo principio que hace que una sede use sus dos circuitos hace que una troncal use todos sus hubs.

Usamos routers virtuales para las sedes tranquilas y routers hardware para las de mucho tráfico.

Hubs redundantes que no estorban

Un hub de reserva debería estar callado hasta que se le necesite. Dele su propio AS de BGP o una despreferencia de salida deliberada para que los spokes prefieran el primario, y use BFD en los túneles para que un primario muerto se detecte en segundos y no al vencer el hold timer de BGP. Los spokes conmutan entonces solo por enrutamiento. Nadie toca un router de sede porque un hub haya cambiado.

Una lista de comprobación para su propia WAN

• ¿Usa cada sede con dos circuitos los dos, y puede demostrarlo con un test de caudal?
• ¿Están las dos nubes separadas por tunnel key, con protección IPsec shared?
• ¿Está habilitado el multipath de BGP y el hash de reenvío incluye los puertos?
• ¿Está BFD en marcha en cada túnel?
• ¿Conoce su techo de cifrado medido por hub, no el licenciado?
• ¿Le obligaría un fallo de hub a tocar un solo spoke?

Operamos este diseño entre nuestros datacenters de Atenas, Ámsterdam y Toronto, con hubs redundantes en cada uno, y construimos lo mismo para los clientes que quieren unir sus propias oficinas a su plataforma. Si quiere ayuda para diseñar la suya, estaremos encantados de hablar.

Hable con un ingeniero

Related

Relacionado: Troncal cifrada multisede: la malla DMVPN · Conectividad privada: pasarelas VPN y líneas dedicadas · Monitorización de red y evidencias