Cómo diseñar la red de un operador de Internet

Una red de operador se ordena en cuatro funciones, aunque no siempre en cuatro equipos distintos. El acceso lleva el servicio hasta el suscriptor: OLT con GPON o XGS-PON en fibra, radios en un operador inalámbrico. Es donde se va la mayor parte del capital y donde se define la experiencia del cliente. La agregación concentra los nodos de acceso y es donde vive el concentrador de suscriptores, que autentica, aplica el perfil de velocidad y reporta contabilidad. El borde termina los tránsitos y los peerings. El núcleo transporta entre puntos de presencia.

En el acceso, las decisiones son de aritmética óptica más que de enrutamiento. GPON reparte alrededor de dos coma cinco gigabits de bajada entre todos los suscriptores de un mismo puerto, y con relaciones de división de uno a sesenta y cuatro o de uno a ciento veintiocho eso funciona bien mientras el consumo simultáneo sea el de un servicio residencial típico. XGS-PON lleva ese puerto a diez gigabits simétricos. La decisión entre uno y otro no se toma por moda: se toma mirando qué velocidad va a vender en tres años y qué relación de división piensa usar.

El error de diseño más común en operadores pequeños es replicar la arquitectura de cuatro capas de un operador nacional cuando se tienen ochocientos suscriptores y un solo punto de presencia. Con ese tamaño, borde, núcleo y concentrador conviven perfectamente en un mismo equipo, y separarlos antes de tiempo multiplica el coste y los modos de fallo sin aportar nada. La arquitectura correcta es la que resuelve el tamaño actual y admite separar funciones cuando el tamaño lo exija, sin renumerar ni rediseñar el enrutamiento.

El número de sistema autónomo es el primer trámite del proyecto, no el último, porque todo lo demás cuelga de él: las sesiones de tránsito, el acceso a un punto de intercambio, los objetos en el registro de enrutamiento y los certificados de origen de ruta. Tramitarlo cuando ya se necesita es lo que obliga a arrancar con direccionamiento del proveedor y renumerar más adelante, que es un trabajo ingrato y perfectamente evitable. En la región, la asignación la gestiona LACNIC directamente o a través del registro nacional correspondiente.

La realidad del direccionamiento IPv4 hay que asumirla desde el diseño: LACNIC agotó su pool general el diecinueve de agosto de 2020. Lo que queda son asignaciones muy acotadas para nuevos entrantes y el mercado secundario, donde una dirección cotiza entre veinticinco y treinta dólares y un bloque de doscientas cincuenta y seis direcciones ronda entre seis mil cuatrocientos y siete mil setecientos dólares. Con esos precios, cualquier diseño que asuma una dirección pública por suscriptor está económicamente muerto antes de encender el primer cliente.

IPv6 no tiene ese problema y se solicita en el mismo trámite. Y hay dos tareas que se hacen el primer día y no después: publicar los certificados de origen de ruta para sus prefijos, porque cada vez más redes descartan anuncios inválidos y la consecuencia de no tenerlos es alcanzabilidad parcial imposible de diagnosticar desde dentro; y registrar los objetos de enrutamiento correspondientes, porque muchos proveedores de tránsito generan sus filtros de entrada automáticamente desde ahí y si no existen, sencillamente no le propagan los anuncios.

El tránsito internacional es el mayor gasto recurrente de un ISP mediano, y la palanca que más lo reduce no es negociar mejor el precio por megabit sino sacar tráfico del tránsito. Ahí es donde entran los puntos de intercambio locales, que en la región están lejos de ser marginales: LAC-IX coordina ciento diecisiete puntos de intercambio, IX.br alcanzó cincuenta terabits por segundo en treinta y nueve regiones metropolitanas en marzo de 2026, y PIT Chile reúne del orden de ciento cincuenta y un sistemas autónomos con cerca de doce terabits. Ese es tráfico que no está pagando tránsito.

La decisión de conectarse no se toma por intuición sino midiendo. Active NetFlow o sFlow en el borde durante dos semanas y ordene el tráfico por sistema autónomo de destino. Si una parte relevante del volumen va a redes presentes en el punto de intercambio más cercano, el cálculo es directo: compare el coste del puerto, el transporte hasta el punto y la cuota asociada contra lo que hoy paga por ese mismo tráfico en tránsito. En muchos operadores medianos, la conexión se paga sola en meses; en otros, con volumen bajo o transporte caro hasta la sede del punto, no cierra todavía, y es perfectamente legítimo esperar.

El diseño mínimo de un borde con criterio es dos tránsitos de proveedores distintos por rutas físicas distintas más presencia en el punto de intercambio local. Con un solo tránsito no tiene una red, tiene una dependencia. Y en cada sesión, sin excepción, configure límite máximo de prefijos, filtros de prefijos propios en salida, descarte de rangos no enrutables y validación de origen de ruta. La ausencia de un límite de prefijos es la causa habitual de que un operador pequeño se convierta accidentalmente en tránsito de tráfico ajeno y sature sus enlaces sin entender por qué.

El CGNAT se dimensiona por sesiones concurrentes, no por ancho de banda, y confundir las dos cosas es la causa habitual de plataformas que se saturan con la mitad del tráfico previsto. La referencia de trabajo es de cien a doscientas sesiones simultáneas por suscriptor residencial activo, así que cinco mil suscriptores producen del orden de setecientas cincuenta mil sesiones. Ese es el número contra el que hay que comparar la capacidad de la plataforma, junto con la tasa de creación de sesiones por segundo, que es lo que realmente sufre en las horas pico.

El cálculo de direcciones sale del reparto de puertos. Cada dirección pública ofrece unos sesenta y cuatro mil quinientos doce puertos utilizables por protocolo. Si asigna bloques de dos mil cuarenta y ocho puertos por suscriptor, una dirección pública sirve a treinta y un suscriptores, y cinco mil suscriptores caben en unas ciento sesenta y una direcciones, es decir dentro de un solo bloque de doscientas cincuenta y seis. Bloques de puertos más grandes mejoran la experiencia de aplicaciones que abren muchas conexiones y reducen la densidad; bloques más pequeños hacen lo contrario. Es un ajuste consciente, no un valor por omisión.

Elija asignación determinística de bloques de puertos siempre que la plataforma lo permita. Con reparto determinístico, la correspondencia entre dirección privada y rango de puertos públicos es una fórmula, de modo que responder a un requerimiento legal no exige almacenar un registro por sesión. El registro por sesión, con cientos de miles de sesiones concurrentes, genera un volumen de datos que en poco tiempo se vuelve inmanejable y caro. Es una de esas decisiones de diseño que cuestan cero al principio y muchísimo si se toman mal.

Y hay que saber qué se degrada. Detrás de CGNAT se complican el reenvío de puertos hacia cámaras y grabadores, algunos juegos y aplicaciones de igual a igual, ciertos escenarios de VPN entrante y, con frecuencia, aparecen verificaciones adicionales en sitios web por la reputación compartida de la dirección. Las mitigaciones habituales son ofrecer dirección pública como producto opcional de pago, habilitar mecanismos de control de puertos donde el equipamiento lo soporte, y sobre todo desplegar IPv6, que saca del CGNAT la mayor parte del tráfico moderno.

IPv6 superó el cincuenta por ciento del tráfico hacia Google en varios países de la región durante 2026, y los puntos de intercambio avanzan hacia redes de peering solo IPv6 con transporte de rutas IPv4 sobre sesiones IPv6. Eso convierte el despliegue en una decisión de ingeniería con retorno inmediato y medible: cada suscriptor con IPv6 nativo deja de pasar por la plataforma de CGNAT para todo lo que hable IPv6, que hoy incluye buena parte del video, las redes sociales y las actualizaciones de sistema operativo. La forma más barata de ampliar la capacidad de CGNAT es desplegar IPv6.

El plan de direccionamiento es simple si se hace bien desde el principio. Asigne un prefijo de cincuenta y seis bits por suscriptor residencial mediante delegación de prefijo, lo que le da al cliente doscientas cincuenta y seis subredes de sesenta y cuatro bits para su red doméstica; use prefijos de sesenta y cuatro bits en cada enlace. Entregar un solo prefijo de sesenta y cuatro bits al hogar parece más económico pero rompe la delegación en el router del cliente y produce problemas difíciles de explicar al soporte de primer nivel.

La operación dual-stack es el camino que funciona: IPv4 con CGNAT e IPv6 nativo en paralelo. Los mecanismos de traducción como 464XLAT o MAP-T son la etapa siguiente, cuando el objetivo sea eliminar IPv4 del acceso. Antes de anunciar el despliegue, verifique la cadena completa, porque el eslabón que falla casi nunca es el router de borde: son el equipo terminal del cliente, el sistema de aprovisionamiento, la plataforma de gestión de direcciones y las herramientas de monitoreo, que en muchas instalaciones asumen IPv4 en cada consulta.

MPLS resuelve tres problemas concretos: vender servicios de red privada de capa dos o capa tres a empresas con separación real de enrutamiento, dirigir tráfico por rutas que el protocolo interno no elegiría, y proteger enlaces con conmutación rápida ante fallos. Si su operación tiene alguno de esos tres requisitos, MPLS es la respuesta correcta. Si no tiene ninguno, es complejidad añadida sin contrapartida, y esa complejidad la paga el equipo que atiende los incidentes de madrugada.

Un ISP residencial con tres puntos de presencia y enlaces punto a punto no necesita MPLS: necesita un protocolo interno bien diseñado, detección rápida de fallos de reenvío y balanceo por múltiples rutas de igual coste. Ese conjunto resuelve convergencia y aprovechamiento de enlaces con una fracción de la complejidad operativa. La pregunta que ordena la decisión es directa: ¿tiene clientes que paguen por separación de enrutamiento? Si la respuesta es no, la respuesta a MPLS también es no, todavía.

Cuando sí llega el momento, evalúe enrutamiento por segmentos antes que la distribución clásica de etiquetas. Elimina un protocolo completo del plano de control porque las etiquetas se distribuyen en el propio protocolo interno, reduce el estado en los nodos intermedios y simplifica muchísimo el diagnóstico. Para servicios de capa dos multipunto, la implementación basada en EVPN es preferible a las alternativas clásicas por comportamiento en fallos y por integración con el resto del diseño. Y en cualquier caso, documente y entrene antes de habilitarlo en producción: los modos de fallo de MPLS son distintos de los de una red puramente IP.

Con quinientos suscriptores todo cabe en un punto de presencia y en muy pocos equipos. Un router de borde capaz de sostener BGP con ruta por defecto o rutas parciales —un CCR2004 o un CCR2116 cubren esta etapa sin discusión—, el CGNAT en el mismo equipo, y un servidor único para autenticación, gestión de direcciones y monitoreo, del tipo PowerEdge R330 o R430 o ProLiant DL120 Gen9. Lo que sí hay que hacer desde el día uno es el trámite del ASN y los prefijos, y desplegar IPv6. Lo que no hay que hacer es montar MPLS ni separar capas. El capital va a fibra y a acceso, que es donde está el negocio.

Con cinco mil suscriptores el diseño cambia de naturaleza. Aparecen el segundo punto de presencia y el segundo tránsito por ruta física distinta, y la conexión al punto de intercambio local empieza a pagarse sola. El borde ya necesita tabla completa y memoria de plano de control para varias sesiones: MX204, ASR1001-X, ASR1002-X o ASR9001 según con qué esté entrenado su equipo, con CCR2216 como alternativa cuando el presupuesto manda. El concentrador de suscriptores se separa del borde, el CGNAT se dimensiona para unas setecientas cincuenta mil sesiones con margen, IPv6 tiene que estar desplegado y no solo planificado, y los servicios se duplican en pares de servidores idénticos, típicamente R630 o DL160 Gen9.

Con cincuenta mil suscriptores el núcleo se separa físicamente y se duplica —MX480, MX960 o la familia ASR9000—, el protocolo interno se diseña con áreas o niveles, y MPLS entra si hay clientes empresariales. Hay varios tránsitos, peering en más de un punto de intercambio y probablemente presencia en un punto regional. El CGNAT pasa a plataforma dedicada con asignación determinística y capacidad de responder requerimientos legales sin almacenar un registro por sesión. El concentrador se redunda de forma que la caída de uno no tire decenas de miles de sesiones a la vez. Y la automatización deja de ser opcional: inventario real, configuraciones versionadas, telemetría y despliegue por plantilla.

El primero y más caro es diseñar el crecimiento asumiendo direcciones IPv4 públicas por suscriptor. Con el pool general de LACNIC agotado desde agosto de 2020 y precios de veinticinco a treinta dólares por dirección en el mercado secundario, ese plan tropieza en el momento exacto en que el operador empieza a crecer bien, que es el peor momento posible para descubrir que hay que rediseñar el direccionamiento y meter CGNAT con la red en producción.

El segundo es tratar el ASN y los prefijos como un trámite administrativo tardío. Arrancar con direccionamiento del proveedor de tránsito parece práctico y significa renumerar cada cliente y cada servicio más adelante, además de no poder hacer peering ni cambiar de tránsito sin cortar. El tercero es la falsa redundancia: dos tránsitos contratados que entran al mismo punto de presencia por la misma canalización física no protegen contra el escenario que más se repite, que es la fibra cortada en obra.

El cuarto es dimensionar el CGNAT por ancho de banda en lugar de por sesiones concurrentes y tasa de creación de sesiones. El quinto, mantener el concentrador de suscriptores dentro del router de borde cuando ya hay miles de sesiones, de modo que cualquier mantenimiento del borde se convierte en una caída masiva de servicio. Y el sexto, que aparece en casi todas las auditorías: sesiones BGP sin límite de prefijos, sin filtros de salida y sin validación de origen de ruta, que es exactamente la combinación con la que un operador pequeño termina propagando rutas que no le pertenecen.