Resumen

  • La consulta planteó una red IS-IS L2 plana de unos 300 routers y equipos de agregación con aproximadamente 100 adyacencias hacia abajo.
  • Saku Ytti relató una operación de varios miles de nodos sobre planos de control antiguos, y Mark Tinka recordó un despliegue cercano a 300 nodos que ya funcionaba en 2009.
  • Tom Beecher consideró viable el tamaño, pero condicionó la respuesta a la geografía, el volumen de la LSDB y los temporizadores SPF. Dan Snyder añadió hardware, tamaño del dominio de fallo y objetivo de convergencia.
  • Matthew Petach convirtió el hilo en una señal de diseño: antes de ampliar un dominio plano hay que definir el alcance permitido de errores de automatización, fallos de equipos y cortes de fibra.
  • Las RFC de IETF explican que las áreas contienen la inundación de estado de enlace y el cálculo SPF, aunque la abstracción también puede perder información útil para elegir rutas óptimas.
  • La aprobación de una arquitectura debería exigir pruebas con tráfico degradado y fallos compartidos, no solo una estimación del número máximo de nodos.

El mensaje original pedía experiencias reales. Su autor quería saber si un dominio IS-IS de nivel 2 completamente plano podía alojar alrededor de 300 routers y si mantener unas 100 adyacencias en equipos de agregación sería problemático.

La comunidad respondió primero con historia operativa. Saku Ytti dijo haber trabajado con algunos miles de nodos IS-IS cuando los procesadores de control eran mucho más lentos. Mark Tinka señaló que en 2009 su red ya alcanzaba aproximadamente 300 nodos con plataformas Cisco y Juniper de aquella época. Tom Beecher coincidió en que, en términos generales, el tamaño era perfectamente abordable.

Esas experiencias no certifican la red del solicitante. Faltan el diagrama, la mezcla de plataformas, el número de enlaces, el tamaño de la base de estado, las latencias y el tiempo de convergencia aceptable. Por eso, el hilo no produce una regla numérica. Lo que sí descarta es la idea de que 300 sea por sí mismo el dato que decide.

La pregunta útil empieza después del «sí»

Beecher explicó que una topología muy dispersa puede exigir ajustes en el retraso SPF y que el tamaño total de la LSDB también importa. Su observación más valiosa fue otra: cuando esa base se vuelve el motivo principal de preocupación, quizá el problema no sea cómo afinar el área plana, sino si conviene seguir tratándola como una sola área.

Dan Snyder separó las variables. El hardware determina parte de la capacidad de cálculo. El tamaño del dominio de fallo define cuántos elementos reaccionan al mismo incidente. El objetivo de convergencia determina cuánto tiempo puede tolerarse una vista inestable. Mejorar una variable no resuelve necesariamente las otras.

El mensaje de Matthew Petach, indexado después, dio al intercambio su dimensión noticiosa. Propuso empezar por los fallos que ocurren de verdad: errores en herramientas de automatización, entradas humanas equivocadas, averías de capa física o de red y cortes de fibra. Para cada uno, el diseñador debe decidir el radio de impacto aceptable y dónde necesita una puerta de aislamiento.

Petach no negó que IS-IS pueda manejar 300 nodos; afirmó que puede manejar bastante más. Su punto fue que la capacidad del protocolo no responde a la pregunta de cuánto negocio puede quedar dentro del mismo dominio de reacción.

Convergencia correcta no significa servicio suficiente

Un transceptor averiado en un centro con personal puede sustituirse rápidamente. Un enlace de gran distancia puede tardar mucho más en recuperar toda su capacidad. Durante ese intervalo, la topología puede estar estable y los prefijos ser alcanzables, pero los caminos restantes pueden no soportar la demanda.

El ejemplo transoceánico utilizado en el hilo hace visible ese riesgo. Las rutas de reserva cuestan, la diversidad contratada puede compartir conductos o puntos de amarre y una perturbación regional puede retirar varias capacidades a la vez. Si el dominio sigue siendo plano, el cálculo de camino más corto puede concentrar tráfico sobre los pocos enlaces vivos aunque el operador prefiera protegerlos o reservarlos para determinados servicios.

No hay en el hilo un incidente real ni mediciones de una red submarina concreta. La conclusión legítima es más estrecha: las pruebas deben evaluar el reparto de demanda después del fallo. Una red no supera el ensayo solo porque el IGP alcance un estado consistente.

Las áreas reducen alcance, pero sacrifican visibilidad

La RFC 5302 describe una jerarquía IS-IS con varias áreas de nivel 1 conectadas por una topología de nivel 2. Al contener los LSP, las áreas reducen el tamaño de la base que cada router debe mantener y acotan la complejidad del cálculo de caminos.

Sin embargo, la misma norma explica el coste. Resumir o abstraer rutas elimina detalle y puede llevar a decisiones menos óptimas. Distribuir más información restaura precisión, pero aumenta memoria, transmisión y cálculo. Dividir un dominio no es una mejora automática; es una decisión sobre qué información compartir y qué fallos contener.

La RFC 9377 identifica el procesamiento y la inundación como límites inevitables de un único dominio IS-IS y presenta la división en dominios L1 con una columna vertebral L2 como el método habitual para escalar. La RFC 8405 añade que los parámetros de espera SPF deben ser coherentes dentro de una misma área o nivel y que los valores apropiados pueden cambiar conforme crece la red.

Por eso no existe una frontera seria expresada únicamente en routers. También cuentan los enlaces, la tasa de cambios, la generación más lenta de hardware, la inundación, la recomputación y la capacidad posterior a cada fallo.

El diseño necesita una matriz de fallos

Un primer bloque de pruebas debe observar margen de control: CPU y memoria, crecimiento de la LSDB, establecimiento de adyacencias, tiempo de propagación de LSP y comportamiento de SPF completo e incremental. El equipo más antiguo que siga prestando servicio debe participar.

El segundo bloque debe fijar el aislamiento. La lista mínima incluye una configuración automatizada errónea, una política de rutas mal aplicada, pérdida de un router, pérdida de una instalación y dos enlaces de larga distancia con destino compartido. Para cada caso hacen falta un perímetro afectado y un responsable de respuesta.

El tercer bloque aplica tráfico a la topología dañada. Debe mostrar qué enlaces se saturan, qué clases de servicio se degradan y dónde puede intervenir la ingeniería de tráfico. Si no existe ese punto de control, el diseño acepta que la congestión decida.

El cuarto bloque prueba el futuro. Petach propuso mirar a tres, cinco y diez años. El crecimiento incluye nodos, pero también más geografías, hardware desigual, nuevos equipos humanos y cambios que deben ejecutarse sin que un error local se convierta en un evento global.

La siguiente cifra debe ser el presupuesto de fallo

Una red compacta, con rutas verdaderamente diversas y abundante capacidad, puede mantener razonablemente un área plana. Otra extendida entre regiones, con reparaciones lentas o compromisos estrictos, puede necesitar límites mucho antes de que el control plane muestre fatiga.

La discusión de NANOG obliga a firmar dos decisiones distintas. Una afirma que IS-IS y los routers pueden mantener el estado de 300 nodos. La otra acepta el alcance de un fallo y demuestra que el tráfico puede controlarse mientras parte de la infraestructura no está disponible.

El documento que falta no es otra anécdota sobre miles de routers. Es un presupuesto de fallo que indique qué eventos se absorben, cuántos servicios pueden verse afectados, durante cuánto tiempo, con qué capacidad residual y mediante qué control operativo.

Fuentes