Cisco vs Juniper para un ISP: cómo decidir

En una red de operador, el coste dominante a lo largo de la vida del equipo no es el precio de compra: es el tiempo de las personas que la operan y el coste de los errores que cometen. Un equipo entrenado en IOS que recibe un chasis Junos va a tardar meses en alcanzar la misma velocidad de diagnóstico, y durante ese periodo cada incidente dura más. Ese sobrecoste rara vez aparece en la comparativa técnica y casi siempre es mayor que la diferencia de precio entre las dos plataformas.

En el mercado laboral latinoamericano hay una asimetría real que conviene mirar de frente: la base de ingenieros con certificación Cisco es mucho más amplia que la de ingenieros con formación formal en Junos. Para un ISP regional con rotación de personal, poder contratar un reemplazo en semanas en lugar de meses es un criterio de diseño legítimo. Para un operador con un equipo pequeño y estable, que va a mantener a las mismas tres personas durante años, ese argumento pesa mucho menos.

El razonamiento inverso también es válido. Si el equipo ya opera Junos en el data center o viene de un proveedor mayorista que lo usa, introducir IOS XR en el borde agrega un segundo sistema operativo que hay que documentar, versionar y certificar. Homogeneizar tiene un valor operativo concreto: menos plantillas, menos scripts, menos modos de fallo que aprender. La pregunta correcta no es cuál plataforma es mejor, sino cuál de las dos convierte a su equipo actual en un equipo más rápido.

La tabla global de Internet supera hoy el millón de prefijos IPv4 y ronda los doscientos mil en IPv6, y crece todos los años. Eso convierte dos números en el criterio técnico duro de cualquier router de borde: cuántas rutas caben en la FIB del hardware de reenvío y cuánta memoria tiene el plano de control. Son cosas distintas y se agotan por separado. La FIB contiene las mejores rutas programadas en el silicio; la memoria del procesador de rutas tiene que sostener una copia de todo lo que le anuncia cada vecino antes de elegir.

De ahí sale la regla de dimensionado que más se ignora: recibir tres tránsitos completos no triplica la FIB, pero sí triplica la memoria necesaria en el plano de control, porque el router guarda las tres tablas recibidas para poder recalcular. Sumar IPv6 encima añade otra tabla. Si el equipo se compra con la opción mínima de memoria disponible, funciona el primer día y falla dos años después con un consumo creciente que nadie relaciona con la compra original. Ese es el fallo clásico y es especialmente frecuente en equipo de segunda mano, donde la configuración de memoria viene fijada por el que lo vendió.

El otro fallo es comprar un switch de capa tres como si fuera un router de borde. Muchas plataformas de conmutación con precio atractivo tienen tablas de reenvío de dieciséis mil o treinta y dos mil rutas: sirven perfectamente para un core interno con IGP, y no sirven en absoluto para terminar un tránsito completo. Si el presupuesto no da para un borde con FIB suficiente, la solución de diseño correcta no es forzarlo: es pedir ruta por defecto o rutas parciales al tránsito y reservar la tabla completa para las sesiones de peering, que es donde aporta valor.

Las dos marcas licencian, pero lo hacen de forma distinta y eso cambia cómo hay que leer una cotización. La familia ASR1000 de Cisco licencia capacidad de reenvío: un ASR1001-X arranca con una capacidad base y se escala por licencia hasta su tope, además de los paquetes de funcionalidades. Traducido a la práctica: dos unidades del mismo modelo pueden tener rendimiento muy diferente según qué licencia traigan, y en el mercado de segunda mano ese detalle es exactamente lo que separa una ganga de un problema.

Juniper mantuvo históricamente más funcionalidad incluida en la imagen base, lo que simplificaba la compra, pero las generaciones recientes de la línea MX se movieron hacia modelos de suscripción por niveles de funcionalidad. La conclusión honesta es que ya no existe una regla del tipo una marca licencia y la otra no: existe la obligación de leer qué incluye exactamente la unidad concreta que le están cotizando, en qué versión de sistema operativo, y qué necesita habilitar para su diseño.

Hay un tercer coste que afecta por igual a las dos y que decide muchos proyectos con equipo refurbished: el acceso a imágenes de software y a actualizaciones de seguridad depende de contratos de soporte vigentes. Un router funcionando sin contrato sigue enrutando perfectamente, pero actualizarlo cuando aparece una vulnerabilidad relevante deja de ser trivial. Es una decisión que hay que tomar de forma consciente al diseñar la compra, no descubrirla el día que hace falta parchear.

Junos tiene una ventaja operativa concreta y difícil de discutir: configuración por candidato con confirmación explícita y reversión. Se editan los cambios sin aplicarlos, se revisan como diferencia, se confirman, y existe la posibilidad de confirmar con temporizador de modo que si el ingeniero pierde la sesión el equipo revierte solo. Para un operador que hace cambios remotos en puntos de presencia sin personal en sitio, eso no es una comodidad: es la diferencia entre un cambio fallido y un desplazamiento de cuatro horas por carretera.

Del lado de Cisco hay que distinguir dos mundos. IOS XR, que es el sistema de la línea de operador, también trabaja con configuración por candidato y confirmación, con un modelo de reversión equivalente y con separación de procesos que aísla fallos. IOS XE, que corre en ASR1000 e ISR, aplica los comandos de inmediato y su red de seguridad es el archivo de configuración con reemplazo programado, que resuelve el mismo problema por otro camino pero exige más disciplina de procedimiento. Comparar Junos con IOS XE y concluir que Cisco no tiene reversión es una comparación mal planteada.

El resto de las diferencias son de estilo y pesan menos de lo que parece: jerarquía de configuración frente a comandos planos, forma de expresar políticas de enrutamiento, comportamiento por omisión de las sesiones BGP, sintaxis de las listas de prefijos. Todas se aprenden en unas semanas con documentación y un laboratorio. Lo que no se aprende rápido es la intuición de diagnóstico —saber qué mirar primero cuando una sesión no levanta o cuando el reenvío cae sin que el protocolo se caiga—, y esa intuición tarda meses en reconstruirse sobre una plataforma nueva. Por eso el criterio del primer apartado, en qué sistema ya piensa su equipo, sigue mandando sobre todas estas diferencias de estilo.

Cisco tiene el mercado secundario más grande del mundo en equipamiento de red, y eso se nota en la región de forma muy práctica: modelos como ASR1001-X, ASR1002-X e ISR4431 aparecen con regularidad, las fuentes y los módulos son fáciles de conseguir, y encontrar una unidad de reemplazo para una falla urgente suele ser cuestión de días. Para un operador cuya estrategia de repuestos es tener un equipo idéntico en el almacén, esa profundidad de mercado tiene un valor económico directo.

Juniper tiene un mercado secundario sólido pero de menor volumen. El MX204 se consigue con regularidad porque se desplegó masivamente en bordes de ISP, y el QFX5100 es una de las mejores relaciones capacidad-precio disponibles para construir hojas de una topología spine-leaf. Donde aparece la fricción es en tarjetas específicas de chasis modulares: una MPC o una MIC concreta para un MX480 puede requerir una búsqueda más larga que su equivalente Cisco. Eso no descalifica la plataforma, pero sí obliga a planificar los repuestos críticos con más anticipación.

Un punto que afecta a las dos y que conviene resolver en la cotización, no después, son las ópticas. Ambos fabricantes codifican sus transceivers y ambos ecosistemas tienen alternativas de terceros programadas para la plataforma. Junos las acepta con una advertencia en el registro; en el mundo Cisco existe la habilitación explícita de transceivers no soportados. Lo importante es decidirlo antes: pedir las ópticas junto con el router, indicando tipo de conector, velocidad y distancia del enlace, evita el escenario clásico de tener el equipo en sitio y no poder encenderlo.

Si el objetivo es empezar a automatizar desde cero con un equipo que sabe Python, Junos ofrece el camino más corto. NETCONF está en la plataforma desde hace mucho, los modelos de datos son consistentes en toda la línea, PyEZ da acceso programático directo a configuración y estado operativo, y existen herramientas de validación que capturan el estado antes y después de un cambio para comparar automáticamente. Combinado con la confirmación temporizada, la automatización deja de ser un riesgo y pasa a ser una red de seguridad.

Cisco juega en otra escala cuando el problema es orquestar una red grande y heterogénea. NSO es la herramienta de orquestación multivendor más capaz del mercado y gestiona equipos de otros fabricantes, incluido Juniper, mediante modelos de servicio. Tiene coste y una curva de aprendizaje real, así que rara vez es la primera herramienta de un ISP de cinco mil suscriptores; es la respuesta correcta cuando ya hay decenas de puntos de presencia, varias marcas conviviendo y servicios que hay que activar de forma repetible. En el nivel más básico, IOS XE e IOS XR soportan NETCONF y RESTCONF, y IOS XR tiene además muy buena telemetría por streaming.

El criterio de decisión práctico es este: si va a automatizar usted mismo, con scripts y con Ansible, mire qué plataforma le da modelos de datos estables y reversión segura, y ahí Junos parte con ventaja. Si va a comprar una capa de orquestación porque tiene que activar servicios sobre una red mixta y grande, el ecosistema Cisco ofrece la herramienta más madura. Y si todavía no automatiza nada, ninguna de las dos cosas debería decidir la compra del router: primero inventario, versionado de configuraciones y telemetría básica.

Cisco gana cuando la red ya es Cisco y el equipo también. Cuando hay base instalada de ASR e ISR, plantillas escritas, repuestos estandarizados y personal certificado, sumar una plataforma más de la misma familia elimina de golpe una cantidad de trabajo que ninguna ventaja técnica marginal compensa. También gana cuando el requisito incluye servicios integrados en la misma caja —concentración de VPN, seguridad, voz— porque la línea ISR4431 e ISR4451 está pensada exactamente para eso, y cuando el proyecto es de gobierno o corporativo y el pliego ya nombra la marca.

Juniper gana cuando el problema es puro enrutamiento de operador y la métrica es densidad y escala. Un MX204 pone cuatrocientos gigabits y cuatro puertos de cien gigabits en una unidad de rack, y para un operador que va a hacer peering serio en un punto de intercambio local esa densidad por unidad de espacio y por vatio es difícil de igualar. También gana cuando hay mucho cambio remoto y la confirmación temporizada evita perder un punto de presencia, cuando la automatización propia va a ser en Python, y cuando el proyecto es una fabric de data center con EVPN y VXLAN.

Hay un tercer escenario que conviene decir en voz alta porque es el más común en la región: para muchos operadores medianos la respuesta correcta no es elegir entre las dos, sino no comprar ninguna de las dos en toda la red. MikroTik en acceso y agregación, con una plataforma Cisco o Juniper únicamente en el borde donde hace falta tabla completa y memoria de plano de control, resuelve el mismo diseño con una fracción del capital. La decisión Cisco contra Juniper solo importa en las cajas donde importa.

Los criterios anteriores se pueden reducir a una serie de decisiones binarias. Ninguna es absoluta y todas admiten excepciones, pero si tres o cuatro apuntan en la misma dirección, esa suele ser la respuesta correcta para su operación concreta. Conviene revisarlas con el equipo de operación presente, no solo con el área de compras, porque la mitad de los criterios tienen que ver con quién va a atender el incidente de la madrugada.

Antes de aplicarlas, fije tres datos que condicionan todo lo demás: cuántas sesiones de tránsito completo va a recibir en los próximos tres años, si va a vender servicios a empresas sobre MPLS, y cuántas personas van a operar la plataforma de forma habitual. Con esos tres números, la mitad de las opciones se descarta sola y la comparación se vuelve mucho más corta de lo que parecía al principio. Una advertencia final: no compare precios de chasis sino coste a tres años con licencias, ópticas, repuestos y horas de operación incluidas, porque es ahí donde las dos plataformas se separan de verdad.