Dimensionar una gran VPN en estrella: cuente antes de elegir BGP

Tres mil sucursales suenan a un problema de enrutamiento, pero se comportan como un problema de contabilidad. El total de prefijos se calcula en diez minutos y rara vez es el número que duele. Lo que duele es el trabajo por sesión, la ráfaga de actualizaciones cuando falla un componente compartido y el tiempo que pasa hasta que el reenvío vuelve a coincidir con la nueva topología.

Así que recorra la aritmética en el orden correcto. Cuente las relaciones, cuente los prefijos y las alternativas, luego cuente qué ocurre en una mala hora y solo después compare protocolos y plataformas. En el orden inverso, el ejercicio se convierte en una discusión sobre límites de rutas que nadie puede cerrar con la información sobre la mesa.

Cuatro presupuestos, no uno

Cada presupuesto responde a una pregunta distinta, y cada uno puede ser la restricción limitante en una plataforma diferente. Escribirlos por separado impide que un solo número grande de prefijos haga de sustituto de todo el diseño.

Los dos últimos son los que se saltan en una revisión de diseño. Una red que en estado estable cabe cómodamente en memoria puede comportarse mal cuando cuatrocientas sucursales se reconectan en dos minutos, porque el trabajo llega más rápido de lo que el plano de control lo drena. Anote el tamaño de la ráfaga como un número, junto con cuánto tiempo puede permanecer degradado el servicio. Eso convierte una preocupación vaga en una prueba que alguien puede ejecutar de verdad.

También hay una pregunta de plataforma escondida dentro de los cuatro: si el cifrado, el reenvío y el enrutamiento comparten una CPU o tienen rutas separadas. Dos dispositivos con idéntica capacidad de rutas pueden comportarse muy distinto bajo la ráfaga, y la hoja de datos rara vez dice cuál está comprando.

Haga la aritmética con sus propios números

Tome un diseño inventado: 3,000 sucursales, tres prefijos cada una antes de la agregación y dos concentradores por sucursal por redundancia. El par de concentradores debe sostener unos 9,000 prefijos de sucursal antes del resumen, y el diseño implica 6,000 sesiones de sucursal a concentrador si cada sucursal se empareja con ambos.

Ahora añada las partes que no son prefijos. Cada sesión lleva estado y mensajes periódicos incluso cuando nada cambia. Cada concentrador puede mantener más de un camino por prefijo si se espera que cambie rápido, así que el número de alternativas puede superar el número de seleccionadas. Y la vista de cada radio es una decisión de política aparte: dar a cada sucursal las rutas de todas las demás multiplica el trabajo de una forma que el conteo del lado del concentrador no revela.

Son cifras de planificación para una conversación de diseño, no una medición de ningún producto. El resultado útil del ejercicio es la forma de la curva, no una afirmación sobre dónde cede un enrutador concreto.

Qué le compra BGP y qué le compra un IGP

BGP separa lo que un enrutador recibió, lo que seleccionó y lo que anuncia, y cada una de esas cosas está controlada por política. Eso es justo lo que necesita una red de sucursales, porque un radio suele tener que ver una ruta por defecto, los servicios centrales y muy poco más. Contar solo la tabla final esconde las alternativas y los anuncios, que son precisamente las partes que crecen al añadir redundancia.

Un IGP no es automáticamente incorrecto. Cuando la topología, la estructura de áreas y el modelo de adyacencia encajan con el servicio, un protocolo de estado de enlace converge rápido y necesita menos andamiaje de política. La trampa es suponer que puede expresar el mismo control de exportación por vecino que BGP: un área OSPF es una frontera de inundación, no un filtro que se pueda colgar de una sucursal.

En cualquier caso, decida primero el modelo de visibilidad. Rutas por defecto, resúmenes para servicios centrales o detalles completos de sucursal son tres productos distintos, y un resumen que oculta un fallo más específico es una decisión de diseño que hay que escribir, no descubrir durante una interrupción.

Pruebe la ráfaga, no el estado estable

Construya la comparación en torno al fallo que realmente espera: un concentrador caído, un evento WAN regional o una ventana de mantenimiento que deja media red de sedes fuera de línea a la vez. Mida la recuperación desde la perspectiva de la sucursal, incluida la aplicación, porque un plano de control que converge en segundos significa poco si la sesión tarda minutos en restablecerse.

show bgp vpnv4 unicast summary
show ip route vrf BRANCH summary
show processes cpu sorted | include BGP|OSPF

Registre qué hace la plataforma en el pico de la ráfaga y no en reposo, y repítalo con las funciones de seguridad activadas. Una prueba de concepto que solo muestra una tabla tranquila es una prueba de memoria, y la memoria nunca fue el número interesante.