Resumen

  • El registro de cambios de AFRINIC del 18 de agosto de 2026 describe cuatro estados BGP: anuncio del prefijo original, solo rutas más específicas, sin enrutamiento y sin datos.
  • Al aplicar el código público al archivo completo de Sudáfrica consultado el 3 de septiembre, 239 anuncios exactos y 42 casos con rutas más específicas suman 281 de 522 bloques. El resultado redondeado es 54%.
  • El archivo se generó el 20 de agosto, pero no identifica la fecha de la instantánea BGP. La comprobación reproduce el cálculo publicado; no constituye una nueva medición de rutas ni una prueba de disponibilidad.

Hay una diferencia importante entre no encontrar una ruta y no disponer de datos para buscarla. También la hay entre ver anunciado un prefijo completo y ver rutas hacia prefijos más pequeños dentro de él. Un panel que conserva ambas distinciones ahorra trabajo al lector, siempre que después no las borre al resumirlas.

AFRINIC ha dado ese paso en Africa IPv6 & DNSSEC Deployment Monitor. Su historial del 18 de agosto documenta el cambio de dos a cuatro estados BGP. Separar la falta de información de una clasificación negativa es una mejora práctica. Separar anuncios exactos y rutas más específicas permite preguntar cómo aparece una red, además de si aparece.

La suma general, sin embargo, sigue reuniendo las dos formas de anuncio. Eso no invalida el cálculo. Delimita su significado.

Las piezas del porcentaje

El archivo público sudafricano, obtenido íntegramente el 3 de septiembre, contiene 522 registros de prefijos distintos. De ellos, 451 tienen el estado allocated y 71 el estado assigned. Conviene hablar de bloques incluidos en el archivo, no de 522 asignaciones del mismo tipo.

El código de la página ofrece la regla necesaria para reproducir la clasificación. Primero aparta los registros declarados fuera del conjunto BGP; después identifica los anuncios exactos, luego los casos con anuncio pero sin prefijo exacto y, finalmente, los que considera no enrutados.

Clasificación según el monitor Bloques
Prefijo original anunciado 239
Solo rutas más específicas 42
Clasificados sin enrutamiento 241
Clasificados sin datos 0

El numerador combina las dos primeras filas. Son 281 bloques y, sobre 522, el código obtiene 54% al redondear. La frase explicativa que construye también desglosa cuántos corresponden al prefijo original y cuántos a rutas más específicas. La distinción no ha desaparecido del diseño.

Si se contaran únicamente los 239 anuncios exactos, el porcentaje sería aproximadamente 46%. No sería una disponibilidad «corregida», sino otra medida. Cada registro pesa lo mismo, sin ponderar la cantidad de direcciones que abarca. Tampoco se están contando operadores únicos, clientes o conexiones que funcionaron.

La etiqueta no decide si la arquitectura es buena

En lenguaje corriente, ver algo por partes puede sonar a cobertura incompleta. En BGP, una ruta más específica tiene un sentido preciso: según RFC 4271, describe un conjunto menor de destinos mediante un prefijo más largo. Esa relación no determina por sí sola si el diseño cumple las necesidades del servicio.

Como ejemplo puramente aritmético, las dos mitades /33 correctamente alineadas de un /32 pueden describir todo ese /32 sin anunciar el prefijo /32. No se ha comprobado que ninguno de los 42 casos utilice esa configuración. El ejemplo basta para mostrar que la ausencia del agregado no demuestra necesariamente un hueco entre las rutas observadas.

La presencia del agregado tampoco prueba lo contrario: no garantiza que cada dirección tenga un equipo activo, que todos los observadores acepten la ruta o que una aplicación responda. El número de rutas más específicas no revela su unión ni sus solapamientos. Para evaluar un servicio hacen falta observaciones del servicio, no solo información de rutas.

Por eso no cabe describir los 42 casos como averiados, ociosos o inseguros. Los 241 clasificados sin enrutamiento siguen siendo un resultado limitado al conjunto de datos del monitor. No equivalen a demostrar que ninguna vista posible de BGP contiene una ruta. El cero de la última fila tampoco certifica una observación completa de África: corresponde al archivo sudafricano examinado.

Una fecha de generación no es una fecha de observación

El historial del sitio sostiene que la metodología anterior contaba un bloque si aparecía cualquier parte de él y atribuye los porcentajes más bajos a una medición más estricta. Esa es su explicación del cambio histórico. Esta revisión no reconstruyó la versión anterior ni comparó sus entradas BGP con las nuevas. No permite calcular una caída entre versiones y mucho menos atribuirla a un deterioro de las redes.

El archivo consultado indica que se generó el 20 de agosto de 2026. El campo de fecha BGP está vacío. El código distingue expresamente ambos casos: utiliza la fecha de la instantánea cuando existe y, en su ausencia, informa de cuándo se generaron los datos. El 3 de septiembre es la fecha de nuestra consulta, no una sustitución válida de la observación que falta.

La página de Sudáfrica separa además servicios de dominios, adopción por usuarios, espacio de direcciones y BGP en pestañas diferentes. Conviene mantener esa separación al interpretar los resultados. Un anuncio no ha probado por nosotros el correo, una web ni la conexión de un abonado.

La mejora ofrece, en definitiva, más preguntas útiles bajo un número conocido. Conservar las dos clases de anuncios permite investigar una configuración concreta. Reducirlas a una nota de calidad haría que la lectura volviera a ser más pobre que el instrumento.