Zayo Group, LLC y AS6461: qué puede demostrar realmente una red troncal de fibra sobre la continuidad de las rutas

Resumen

Las fuentes usan Zayo Group, LLC, Zayo Group, Zayo y Zayo Bandwidth en contextos distintos. Los documentos de la SEC y la FCC autentican a Zayo Group, LLC en expedientes concretos, y una declaración de 2013 describe Zayo Bandwidth como una unidad de negocio histórica. Eso no demuestra que los cuatro nombres sean hoy una misma persona jurídica.
PeeringDB publica Zayo, AS6461, bajo la organización Zayo Group. El servicio RDAP de ARIN, que permite consultar de forma estructurada los datos del registro, denomina al recurso ZAYO-6461, muestra Zayo Bandwidth como titular del registro y presenta contactos cuyo campo de organización dice Zayo Group. Son etiquetas atribuibles a cada base de datos, no una escritura de propiedad universal.
Entre el 22 de julio de 2026 a las 16:00 UTC y el 5 de agosto a la misma hora, Announced Prefixes de RIPEstat devolvió 234 registros de prefijo. Al cierre de esa ventana, Routing Status mostró 210 prefijos IPv4 y 13 IPv6, con visibilidad ante los 326 de 326 pares IPv4 y los 322 de 322 pares IPv6 del Routing Information Service (RIS), que constituyen la muestra de recogida del RIPE NCC y no todo Internet, además de 2.823 vecinos observados. La cobertura de esos colectores no equivale a alcance universal.
Una captura distinta de BGP State —una vista puntual de las rutas del Border Gateway Protocol (BGP), el sistema con el que las redes intercambian información sobre destinos alcanzables—, fechada el 5 de agosto de 2026 a las 23:59:52 UTC, contenía 76.627 observaciones de ruta. En esa respuesta se calcularon 227 prefijos objetivo distintos y 76.567 caminos que terminaban en AS6461. Las filas repetidas desde múltiples observadores no son clientes, circuitos ni redes únicas.
La prueba de la Resource Public Key Infrastructure (RPKI), el sistema criptográfico que comprueba qué red está autorizada a originar un bloque de direcciones, se limitó a AS6461 con 64.125.0.0/16. El resultado era Valid: una Route Origin Authorization (ROA), es decir, un documento firmado que indica qué red puede anunciar el bloque, identificaba el origen 6461 y fijaba una longitud máxima de 16. No se puede extender esa conclusión a todos los prefijos que aparecieron en las otras capturas.
Los materiales de Zayo explican IP Transit, acceso dedicado a Internet, opciones BGP, el mecanismo Bidirectional Forwarding Detection (BFD), que detecta con rapidez ciertas pérdidas de comunicación entre equipos vecinos, además de multihoming, protección, interconexión y comunidades BGP. Describen capacidades y políticas del emisor; no prueban la configuración de un cliente, la continuidad obtenida ni el cumplimiento de un acuerdo de nivel de servicio (SLA), que define objetivos y mediciones contractuales.

La imagen de apertura es una ilustración editorial original, fotorrealista y sin marcas. Una persona no identificable revisa un diagrama genérico de red troncal y una lista de continuidad. No representa ni insinúa a Zayo Group, LLC, Zayo Group, Zayo Bandwidth, Zayo, ARIN, RIPE NCC, PeeringDB, IETF, empleados, clientes, oficinas, instalaciones, rutas de fibra, mapas de red, bloques de direcciones, mediciones, incidentes, debilidades, resultados de servicio, SLA, avales o respaldos reales.

La tienda que sigue sin saber si podrá cobrar

Pensemos en una empresa pequeña con veinte tiendas. Cada local usa Internet para autorizar pagos, actualizar existencias y llamar por voz sobre IP. La empresa compra un acceso de fibra y recibe información sobre una red troncal extensa, BGP y distintas opciones de protección. Después encuentra AS6461 en PeeringDB y ARIN, y observa que numerosos colectores ven sus rutas. Parece una respuesta completa a la pregunta de continuidad.

Pero el lunes se corta el acceso de un local. AS6461 continúa visible en Internet porque la red troncal sigue anunciando rutas desde muchos otros puntos. Los colectores públicos no saben que un conducto cercano a la tienda fue dañado. Tampoco saben si el router local tiene electricidad o si la sesión de respaldo se configuró. La empresa no puede usar la visibilidad global como prueba de que ese acceso particular está disponible.

También puede ocurrir lo contrario. Una perspectiva pública pierde temporalmente una ruta, mientras el tráfico de un cliente circula por una interconexión privada o por otra vista que el colector no recibe. La ausencia en una muestra no es automáticamente una caída universal.

La lección es práctica: «continuidad» necesita apellido. Puede hablarse de continuidad física de la fibra, continuidad de los anuncios BGP, continuidad del circuito contratado, continuidad de la aplicación o continuidad del proceso de cobro. Cada nivel tiene una prueba y una persona responsable diferente.

AS6461 ofrece una ventana pública sobre una de esas capas. Sirve para estudiar identidad de enrutamiento, prefijos observados, políticas y una autorización de origen concreta. La pregunta del comercio solo se cierra cuando esa evidencia se combina con la entrega real, el contrato y una prueba desde sus establecimientos.

Antes de mirar las rutas, hay que ordenar los nombres

El objeto empresarial de este análisis es Zayo Group, LLC, el mismo texto que aparece en la ficha enlazada del directorio BTW. El directorio de miembros de RIPE NCC muestra también Zayo Group, LLC. Esa coincidencia establece una referencia administrativa, pero una afiliación no atribuye automáticamente todos los ASN, prefijos, productos o instalaciones que contienen una palabra parecida.

PeeringDB organiza la información de otra manera. En su página pública, el ASN 6461 corresponde a una red llamada Zayo, clasificada como NSP, bajo una organización denominada Zayo Group. Es información diseñada para facilitar la interconexión entre operadores. La propia comunidad operadora mantiene buena parte de esos campos; no son una auditoría independiente de disponibilidad.

ARIN aporta una tercera combinación. Su respuesta RDAP para AS6461 usa ZAYO-6461, identifica a Zayo Bandwidth como titular del registro y contiene contactos anidados cuya organización aparece como Zayo Group. Es correcto reproducir esos campos con su procedencia. No es correcto resolver con ellos, sin más documentación, si Zayo Bandwidth es una entidad legal actual, un nombre operativo o una denominación conservada.

La historia societaria ayuda, aunque no elimina la cautela. En un Formulario 10-Q de 2013, Zayo Group, LLC dijo que históricamente había operado una unidad llamada Zayo Bandwidth y que, con efecto desde el 1 de enero de 2013, había distribuido esa unidad heredada entre los segmentos Waves, Sonet, Ethernet, IP y MIG. El dato crea un puente histórico a nivel de empresa; no afirma que el texto actual del registro ARIN sea una persona jurídica separada ni un alias legal exacto.

El Formulario 10-K correspondiente al ejercicio terminado el 30 de junio de 2019 identifica a Zayo Group, LLC como una sociedad de responsabilidad limitada de Delaware y la describe entonces como matriz operativa de subsidiarias. También presenta actividades históricas de fibra, conectividad de ancho de banda, colocación e infraestructura de nube. Es una fotografía corporativa de 2019, no una declaración de estructura o rendimiento en 2026.

La FCC completa la identidad regulatoria. Su aviso público DA 26-637, fechado el 25 de junio de 2026, identifica a Zayo Group, LLC como LLC de Delaware y titular de la autorización internacional de sección 214 ITC-214-20091106-00475 para servicios globales basados en instalaciones y de reventa, dentro de una solicitud pendiente de transferencia de control. El aviso informa que la solicitud se acepta para tramitación y sigue sujeta a revisión; no es una aprobación final. No menciona AS6461 ni Zayo Bandwidth.

Por tanto, las cuatro etiquetas deben permanecer visibles. Zayo Group, LLC tiene apoyo jurídico y regulatorio en expedientes fechados. Zayo Group es un nombre de organización en PeeringDB y en contactos. Zayo es el nombre de red y la marca en materiales del operador. Zayo Bandwidth aparece en ARIN y como unidad histórica en 2013. Las fuentes no demuestran que sean legalmente idénticas hoy.

Qué es AS6461 sin recurrir a una clase de ingeniería

Internet funciona porque muchas redes independientes acuerdan cómo intercambiar tráfico. Cada dominio que presenta su propia política de rutas puede identificarse con un número de sistema autónomo, abreviado ASN. El 6461 de AS6461 es ese identificador público. Se parece más a un número de actor dentro del sistema de rutas que a una matrícula de cada cable o servidor.

Las direcciones se agrupan en prefijos. Un prefijo marca la parte común de una serie de direcciones y se escribe con una barra, como 64.125.0.0/16. El número 16 indica cuántos bits iniciales son fijos. Una red anuncia que puede originar o alcanzar esos bloques.

El BGP, Border Gateway Protocol, transporta esas noticias entre sistemas autónomos. La norma RFC 4271 lo define como el protocolo de enrutamiento entre AS que intercambia información de alcanzabilidad. Cada red aplica políticas para aceptar, rechazar o preferir caminos. La lista de ASN de un anuncio describe un camino lógico visto desde una fuente.

El camino BGP no es un plano de fibra. Un salto entre dos ASN puede apoyarse en enlaces diferentes y recorrer una geografía que el texto no revela. Tampoco mide ancho de banda libre, pérdida, tiempo de reparación o velocidad de una aplicación. BGP responde principalmente a «¿qué destino afirma poder alcanzar esta ruta y por qué secuencia de AS llegó la información?».

Los colectores públicos reciben anuncios desde redes que colaboran con ellos. Permiten observar el sistema en marcha sin entrar en cada router. Su ventaja es la trazabilidad; su límite es la cobertura. No ven todas las sesiones privadas ni garantizan que su perspectiva coincida con la de una tienda concreta.

Tener un ASN propio puede facilitar control de origen, multihoming y políticas. No demuestra que se usen todas esas posibilidades, que cada enlace sea diverso o que el número pertenezca jurídicamente a cada entidad con un nombre relacionado.

La primera fotografía: una ventana de 234 registros

RIPEstat ofrece varias interfaces que parecen responder a la misma pregunta, pero no cuentan exactamente lo mismo. Announced Prefixes devolvió 234 registros de prefijo en la ventana comprendida entre el 22 de julio de 2026 a las 16:00 UTC y el 5 de agosto de 2026 a las 16:00 UTC.

Ese valor describe el resultado del endpoint durante una ventana. No es un certificado de propiedad de 234 bloques, no atribuye cada registro a la misma persona jurídica y no asegura que todos estuvieran simultáneamente activos durante cada segundo. Las agregaciones y cambios dentro del periodo importan.

La página AS Overview de RIPEstat identificaba el titular de la vista con el texto ZAYO-6461 - Zayo Bandwidth y marcaba el ASN como anunciado en el momento consultado. Es otra etiqueta de un observador, coherente con el nombre de ARIN, pero no una determinación societaria.

Guardar la fecha es esencial. Una ruta puede agregarse, dividirse, retirarse o reaparecer. Si un informe repite el número 234 un mes después sin nueva consulta, convierte una observación temporal en una característica fija que la fuente nunca prometió.

La segunda fotografía: visibilidad a las 16:00 UTC

Routing Status, consultado para el 5 de agosto de 2026 a las 16:00 UTC, informó que AS6461 era visible ante 326 de 326 pares RIS IPv4 y 322 de 322 pares RIS IPv6 incluidos en ese cálculo. Dentro de su vista del espacio anunciado, enumeró 210 prefijos IPv4 y 13 prefijos IPv6. También devolvió 2.823 vecinos observados.

El primer error sería traducir 326/326 en «100% de Internet». El denominador son los pares RIS que contribuyeron a esa perspectiva, no todos los proveedores, usuarios o ubicaciones del planeta. Una ruta visible puede no ser utilizable desde una red por filtrado, fallo local o problemas posteriores al borde.

El segundo error sería llamar a los 2.823 vecinos «enlaces directos». La cifra procede de relaciones observadas dentro de los datos y la definición del servicio. No es una lista de circuitos físicos, puertos contratados o caminos de respaldo independientes.

El tercero sería sumar o comparar sin método. Los 210 prefijos IPv4 más los 13 IPv6 dan 223 en esa vista. No tienen por qué igualar los 234 registros de Announced Prefixes, porque una interfaz usa una ventana y la otra un estado, además de tener reglas de tratamiento distintas.

Lo que sí se puede decir es que, a esa hora y desde esos observadores, AS6461 mostraba una presencia de enrutamiento ampliamente visible. La frase termina ahí. No incluye latencia, capacidad, fibra, cliente o SLA.

La tercera fotografía: 76.627 observaciones no son 76.627 redes

La captura BGP State tiene una hora diferente: 5 de agosto de 2026 a las 23:59:52 UTC. Contenía 76.627 registros de ruta recibidos desde las fuentes de la interfaz. Al procesar los destinos de esa respuesta se obtuvieron 227 prefijos objetivo distintos, y 76.567 caminos terminaban en AS6461.

Un prefijo aparece muchas veces porque distintos pares y colectores pueden observarlo. De ahí surge la enorme diferencia entre 76.627 filas y 227 destinos únicos. El volumen de filas indica amplitud de la muestra, no tamaño de la empresa, número de clientes, capacidad o calidad.

Las 60 filas que no terminaban en AS6461 según ese cálculo también importan. Una investigación seria no las oculta para crear un número redondo. Puede haber estados, rutas o formatos que necesiten inspección específica. La conclusión pública se mantiene en lo comprobado: la gran mayoría de los caminos de esa captura terminaba en 6461.

La hora explica parte de la diferencia con Routing Status. Entre las 16:00 y las 23:59:52 pueden cambiar anuncios. Además, BGP State y Routing Status no construyen la misma unidad. El resultado de 227 prefijos no sustituye a los 223 de la otra interfaz ni a los 234 de la ventana.

La documentación de RIPEstat explica que BGP State se basa en las tablas observadas por colectores RIS. Eso hace posible relacionar una fila con su fuente. No convierte el conjunto en una visión omnisciente. Una interconexión privada o una red no representada puede tener una perspectiva diferente.

Una segunda mirada desde Cloudflare Radar

Cloudflare Radar publica una página de AS6461 que emplea ZAYO-6461 y Zayo Bandwidth. Su presentación de conectividad a nivel de sistema autónomo agrega información de los prefijos anunciados y se apoya, entre otras fuentes, en colectores RouteViews.

La utilidad de esta página está en su independencia editorial respecto a Zayo. Confirma que otro observador público reconoce el mismo número y una identidad de enrutamiento parecida. Ayuda a evitar que toda la descripción dependa de los textos comerciales del operador.

No es una autoridad legal sobre el nombre Zayo Bandwidth. Un servicio de análisis de rutas puede reutilizar etiquetas de registros sin investigar la forma societaria. Tampoco ve todas las conexiones privadas, rutas internas, capacidades o estados de cliente.

Cuando dos observadores muestran resultados parecidos, aumenta la confianza en la existencia pública de la actividad. Cuando difieren, deben alinearse fecha, cobertura y unidad antes de hablar de anomalía. Una diferencia metodológica no es automáticamente un incidente.

RPKI y ROA: una comprobación muy concreta

El RPKI es una infraestructura criptográfica para validar determinadas afirmaciones sobre recursos numéricos de Internet. Una ROA, Route Origin Authorization, es un objeto firmado que autoriza a un ASN a originar uno o varios prefijos cubiertos, con una longitud máxima. La RFC 9582 define este tipo de autorización.

La consulta examinada pregunta solamente por AS6461 y 64.125.0.0/16. RIPEstat devolvió Valid. La ROA que validaba el resultado nombraba el origen 6461 y establecía maxLength 16. Para el validador y los datos de ese momento, la combinación exacta estaba autorizada.

No se consultaron de la misma forma, dentro de esta prueba, todos los destinos de las capturas. Por tanto, el resultado no convierte los 234 registros, los 223 prefijos de Routing Status o los 227 de BGP State en un conjunto completamente validado.

RPKI tampoco firma toda la sucesión de AS. La validación de origen no demuestra que el camino sea óptimo, que no haya congestión, que la fibra esté intacta o que la aplicación funcione. Incluso una ruta Valid puede conducir a un servicio indisponible por causas ajenas al origen.

Para gestionar el riesgo, una empresa debe mantener una lista de prefijos esperados, orígenes autorizados, estados observados y responsables. Si aparece un Invalid inesperado, necesita una vía de escalado. Si aparece Valid, registra una comprobación precisa, no una puntuación general de seguridad.

Registros y directorios: libros de cuentas, no dueños del tráfico

ARIN, RIPE NCC y PeeringDB cumplen papeles diferentes. ARIN registra recursos numéricos y contactos para su región. RIPE NCC mantiene su propio registro regional y aquí también aporta el servicio de observación RIPEstat/RIS. PeeringDB facilita información de interconexión publicada por redes y organizaciones.

La comparación con un libro de cuentas resulta útil. Un buen registro conserva unicidad, contactos correctos, cambios, transferencias, metadatos de seguridad y continuidad administrativa. Permite preguntar quién puede corregir una entrada o explicar un anuncio. No controla cada paquete y no sustituye al router en funcionamiento.

El directorio de miembros de RIPE NCC que dice Zayo Group, LLC contiene un detalle histórico en su propia dirección web: el segmento del enlace usa latisys. Ese rastro ilustra por qué conviene leer el contenido actual y conservar contexto, en lugar de inferir identidades solo desde una URL. La página no enlaza por sí sola a AS6461.

El IRR, Internet Routing Registry, es otro libro: guarda objetos de política que los operadores pueden usar para construir filtros. Sus datos requieren mantenimiento. Un objeto IRR no es una ruta viva y no tiene la firma criptográfica de una ROA.

La continuidad administrativa forma parte de la continuidad técnica. Si nadie puede entrar en la cuenta, actualizar un contacto o reemplazar una autorización, la recuperación se complica. Pero la legitimidad operativa no nace de pedir permiso en una página: debe concordar con los anuncios que ejecuta la red y con controles verificables.

Lo que prometen los documentos de IP Transit y DIA

Zayo asocia AS6461 con sus materiales de IP Transit y Dedicated Internet Access, conocido como DIA. Las páginas y el documento técnico describen entrega mediante fibra o Ethernet, rutas estáticas, ruta por defecto o BGP, opciones de BFD, multihoming y distintas formas de protección.

Es información relevante para diseñar una compra. Un cliente puede preguntar si recibirá una sesión BGP, qué prefijos debe anunciar, cómo se detectará una pérdida y qué camino alternativo existe. La documentación ayuda a distinguir una conexión sencilla de una arquitectura con más control.

Los términos de escala, baja latencia, nivel de red y resiliencia proceden del propio proveedor. Deben atribuirse a Zayo. Las fuentes públicas de este artículo no han medido de forma independiente cada afirmación ni han revisado la orden de servicio de ningún cliente.

BFD, Bidirectional Forwarding Detection, puede detectar rápidamente la pérdida de comunicación entre equipos próximos. No detecta todos los fallos de una aplicación y no crea capacidad de respaldo. Multihoming significa conectarse por más de un camino o proveedor en alguna capa; no garantiza por sí solo que los conductos, entradas de edificio, equipos o fuentes de energía estén separados.

Dos sesiones BGP pueden cruzar el mismo punto físico. Dos circuitos pueden compartir una obra civil. Una ruta alternativa puede no soportar la carga normal. Por eso, una posibilidad del catálogo debe convertirse en configuración documentada y prueba de conmutación antes de tratarla como continuidad real.

La política de interconexión muestra disciplina, no ejecución perfecta

La política global de interconexión de Zayo de 2022 enumera condiciones para relacionarse con AS6461. Pide información precisa en PeeringDB y en el registro regional, contactos operativos disponibles las veinticuatro horas, registros IRR y/o ROA RPKI válidas, y dice que se rechazan anuncios RPKI inválidos. También especifica requisitos técnicos y de operación.

Estas condiciones revelan una lógica razonable. Los datos correctos reducen el tiempo para encontrar al responsable. Los filtros de origen disminuyen ciertas rutas inesperadas. Los contactos permanentes ayudan a coordinar un problema. La política permite a un posible par saber qué preparación se espera.

Sin embargo, el documento no es una grabación de todas las sesiones activas. No demuestra que cada contraparte conserve sus datos al día, que cada filtro esté aplicado sin excepción o que toda incidencia se resuelva dentro de un plazo. Sus directrices pueden cambiar y no constituyen automáticamente un contrato de cliente.

Un PNI, private network interconnection, es un enlace directo entre dos redes, en vez de intercambiar tráfico en una plataforma compartida. Puede aportar capacidad o control, pero la palabra «privado» no prueba diversidad física. Hay que conocer ubicación, puertos, rutas y respaldo.

Zayo también publica una referencia de comunidades BGP. Son etiquetas que acompañan rutas y permiten expresar tratamientos de política. Ofrecer esas etiquetas crea una interfaz para clientes y pares. La existencia de la documentación no prueba que una etiqueta concreta se haya usado ni que produjera el resultado esperado.

Cinco capas que suelen mezclarse bajo la palabra continuidad

La primera es la infraestructura física. Incluye fibra, conductos, amplificación, routers, edificios, energía y acceso de técnicos. Una red troncal puede ser extensa y aun así un cliente depender de un único tramo local.

La segunda es el control de rutas. Incluye BGP, filtros, RPKI, IRR, comunidades, contactos y convergencia. La mayor parte de la evidencia sobre AS6461 vive aquí. Una ruta alternativa solo ayuda si está autorizada, aceptada y preparada para cargar tráfico.

La tercera es el servicio de acceso contratado. Sus extremos, velocidad, equipo, demarcación, mantenimiento y remedios pertenecen a una orden y a un SLA determinados. Las páginas públicas no muestran esos datos para una empresa concreta.

La cuarta es la aplicación. DNS, cortafuegos, identidad, servidores y bases de datos pueden fallar aunque BGP siga estable. Una ruta disponible no garantiza que el usuario obtenga una respuesta válida.

La quinta es el proceso empresarial. Una tienda quizá mantenga ventas sin conexión durante veinte minutos; una centralita puede desviar llamadas; otro proceso puede detenerse de inmediato. La protección adecuada depende de ese efecto, no del prestigio del ASN.

Estas capas se deben conectar, pero no fusionar. Para cada una, el equipo pregunta qué estado espera, cómo lo observa, quién puede cambiarlo, qué ocurre si falla y cuándo fue la última prueba.

Por qué ninguna de las cifras públicas es el SLA del cliente

Un SLA define una obligación de servicio con métricas, periodo, ámbito, exclusiones y consecuencias. Puede medir disponibilidad de puerto, pérdida, demora o reparación. Su resultado se calcula según el texto contractual y los datos aceptados, no según la cantidad de rutas que ve un colector público.

Los 326/326 pares IPv4 y 322/322 IPv6 describen cobertura dentro de una muestra RIS. No incluyen el circuito de una tienda como unidad contractual. Los 2.823 vecinos observados no son enlaces físicos de respaldo. Los 76.627 registros BGP no son minutos disponibles. Los 234 registros de prefijo no son sedes protegidas.

La validación RPKI de un /16 tampoco es un control de rendimiento. Dice que el origen consultado concuerda con una autorización firmada; no dice que los paquetes lleguen, que la aplicación responda o que el soporte actúe a tiempo.

Las opciones técnicas son condicionales. BFD debe funcionar en ambos extremos. El multihoming debe disponer de separación y capacidad. Las comunidades deben aplicarse a los anuncios correctos. Un camino de respaldo debe superar una prueba realista.

Para demostrar continuidad o incumplimiento se necesitarían el contrato aplicable, la configuración entregada, mediciones del recorrido del cliente y eventos fechados. Este conjunto público no contiene esos elementos. No prueba que un cliente de Zayo alcanzó o incumplió un SLA, ni siquiera que experimentó un incidente.

Cómo convertir una compra de conectividad en una decisión verificable

Primero se define el resultado. «Necesitamos alta disponibilidad» se reemplaza por una frase medible: «si el acceso principal falla, los pagos deben reanudarse por el secundario en menos de cinco minutos». El número es un ejemplo; cada empresa fija el suyo según el coste de parada.

Después se dibuja el trayecto de extremo a extremo. Debe incluir el equipo local, el último tramo, los puntos de entrada, la aplicación remota, DNS, identidad y dependencias. No hace falta publicar el plano. Basta con que las personas responsables conozcan dónde puede existir un componente único.

La diversidad se pide por dimensión. ¿Los accesos entran por lados diferentes? ¿Usan conductos separados? ¿Terminan en equipos y energía distintos? ¿Los proveedores comparten mayorista? ¿El camino de respaldo soporta la carga crítica? Dos facturas no responden a esas preguntas.

La identidad se verifica con fecha. Se registran el cocontratante, los identificadores de circuito, los contactos de soporte, el ASN y los prefijos esperados. Los nombres de ARIN o PeeringDB se conservan como campos de sus respectivas fuentes, sin sustituir al contrato.

El enrutamiento se comprueba por partes. BGP muestra anuncios observados. RPKI compara origen y autorización. IRR expresa política declarada. Ninguno reemplaza la prueba del servicio.

Finalmente se acuerda cómo medir. El cliente observa la aplicación desde los sitios importantes, cuenta errores y pérdida, registra tiempos de detección y recuperación, y compara el resultado con la definición exacta del SLA. Cada evidencia lleva fecha de caducidad.

Un ensayo de conmutación que produzca conocimiento

Antes de tocar la red, el equipo anota el estado inicial, el cambio que simulará, los resultados esperados, las razones para detenerse y la forma de volver atrás. Se elige una ventana segura y se informa a las personas que pueden intervenir.

La prueba no termina cuando BGP elige otro camino. Se mide cuándo detecta el fallo el equipo, cuándo cambia la ruta, cuándo vuelve la aplicación, si las sesiones se recuperan y si los usuarios completan la operación. Esas marcas de tiempo revelan dónde se consume la recuperación.

También se comprueba capacidad. Un respaldo que funciona con una solicitud puede saturarse con el tráfico normal. Se observa pérdida, errores, latencia y colas dentro de límites que no provoquen daño.

Los datos públicos aportan contexto. Si cambia el origen, un colector puede verlo. Si una ROA se vuelve inválida, un validador puede advertirlo. Si un contacto está obsoleto, el registro revela el problema administrativo. Pero la verdad del cliente se observa desde su extremo.

Al cerrar el ensayo, el informe debe ser específico: fecha, sedes, servicios, carga, configuración, tiempo de restauración, fallos y acciones. «La red es resiliente» no puede repetirse sin límite. «El sitio A recuperó el proceso B en cuatro minutos bajo estas condiciones» sí puede revisarse y compararse.

Las tareas humanas que mantienen vivos los controles

Un sistema de enrutamiento puede automatizar miles de decisiones por segundo, pero depende de identidades y expectativas mantenidas por personas. Alguien conserva el acceso a ARIN o a los demás registros, revisa contactos, prepara ROA, entiende filtros y autoriza cambios.

La ausencia de propietario transforma una diferencia pequeña en una interrupción larga. Un contacto de guardia desactualizado retrasa la coordinación. Una cuenta ligada a un empleado que ya no está bloquea una corrección. Una ruta de respaldo no ensayada puede fallar precisamente cuando se necesita.

La continuidad tiene un coste total: circuitos, equipos, direcciones, observación, pruebas, soporte, documentación y tiempo experto. También tiene un coste de complejidad. Añadir mecanismos sin capacidad para operarlos puede aumentar errores.

La dirección debe comparar ese coste con la pérdida posible. Una oficina con trabajo fuera de línea tolera un diseño diferente al de una plataforma que pierde ingresos cada minuto. AS6461 y la red troncal ayudan a analizar el transporte; no deciden por la empresa cuánto vale su recuperación.

Límites que deben acompañar cualquier conclusión

Las fuentes no demuestran que Zayo Group, LLC sea propietaria legal de todo recurso, instalación u operación etiquetada como Zayo, Zayo Group, Zayo Bandwidth o AS6461. Tampoco establecen que los cuatro nombres sean hoy una persona jurídica única.

No prueban que todos los prefijos observados pertenezcan a la misma entidad ni que todo tráfico de Zayo pase por AS6461. Las vistas RIS y RouteViews tienen cobertura y fechas limitadas; no garantizan alcance desde toda red.

No muestran rutas físicas de fibra, separación de conductos, capacidad reservada, configuración de cliente o resultado de basculación. Las afirmaciones de fibra, escala, BFD, multihoming y protección en los materiales de Zayo son descripciones del emisor.

No extienden el estado RPKI Valid de 64.125.0.0/16 a todas las rutas. Una ROA de origen no valida el camino completo ni elimina todos los riesgos de enrutamiento.

No miden rendimiento de aplicación, pérdida de extremo a extremo, tiempo de reparación, calidad de soporte o cumplimiento contractual. No prueban continuidad ni incumplimiento para un cliente concreto.

El aviso de la FCC es un aviso de solicitud pendiente, no una aprobación final ni una evaluación de AS6461. Los expedientes SEC de 2013 y 2019 son históricos y no fijan la estructura actual.

Ningún documento de este conjunto establece un incidente, una debilidad, una conducta incorrecta, un cliente afectado o una recomendación oficial. Los ejemplos son educativos y la imagen no representa operaciones reales.

Conclusión

AS6461 ofrece una superficie pública rica. PeeringDB lo presenta como la red Zayo bajo Zayo Group. ARIN y observadores de rutas usan ZAYO-6461 y Zayo Bandwidth. Las declaraciones de la SEC y la FCC confirman a Zayo Group, LLC en contextos históricos, legales y regulatorios concretos, mientras que el documento de 2013 relaciona históricamente a la empresa con una unidad llamada Zayo Bandwidth.

Las capturas muestran enrutamiento ampliamente observable el 5 de agosto de 2026. También muestran por qué toda cifra necesita método: 234 registros en una ventana, 210 prefijos IPv4 y 13 IPv6 en un estado, 227 destinos en una captura posterior y 76.627 observaciones repetidas entre fuentes. Ningún número representa por sí mismo propiedad, fibra o disponibilidad.

La consulta RPKI confirma una autorización muy específica. Los documentos de Zayo describen herramientas y opciones reales del mundo operativo. Ninguna pieza establece la configuración o el resultado de un cliente.

La forma sencilla de recordarlo es separar cuatro verbos. El registro anota identidades y contactos. RPKI autoriza un origen concreto. BGP muestra lo observado por ciertas redes en un momento. Solo el contrato y una prueba de extremo a extremo demuestran la continuidad que compró el cliente.