PeeringDB borró el registro. Una copia conservó al fantasma.

Resumen

• Las notas de la versión 2.84.0, fechadas el 21 de octubre, registran una corrección para bajas de redes y conexiones a puntos de intercambio que los clientes de ?since= no recibían. El informe original documenta filas netixlan eliminadas sin dejar estado deleted y redes cuyo campo updated no avanzaba.
• El cambio elimina el borrado masivo en la ruta afectada y añade una prueba de que la API anuncia las bajas. Las copias que ya guardan registros obsoletos necesitan una sincronización completa, según el informe; PeeringDB no publicó cuántos clientes la hicieron.

Cuando el registro se fue y su sombra se quedó

La utilidad de un directorio de interconexión depende de que dos personas puedan consultar el mismo estado. Una mira PeeringDB en línea; otra usa un espejo local para evitar descargas constantes. En el caso descrito en octubre, la primera ya no encuentra una relación entre una red y un punto de intercambio, mientras la segunda la conserva. La ficha sirve para descubrir y planear contactos. El estado de una sesión BGP exige otra prueba. Aun así, trabajar con una ficha retirada como si siguiera vigente puede desviar una llamada, una comparación o una decisión de despliegue.

PeeringDB invita a mantener copias locales. Sus especificaciones de API permiten pedir objetos modificados después de una marca temporal con ?since=; también explican cómo recuperar objetos con status=deleted. La FAQ indica que peeringdb-py descarga todo al principio y, después, solamente las novedades. Ese arreglo ahorra carga a ambos extremos. Su precio es una obligación sencilla: cada modificación que cambie la vista pública debe poder aparecer en el siguiente delta. Si las altas viajan y las bajas se esfuman, el espejo envejecerá con impecable puntualidad.

Remco van Mook abrió el incidente #2057 en el repositorio oficial el 7 de octubre, tras enfrentar una copia alimentada mediante ?since= con las listas completas de la API. Identificó dos huecos. El primero estaba en la limpieza periódica de redes según su estado en los registros regionales de Internet. El programa borraba en bloque los objetos netixlan, que relacionan una red con el LAN de un intercambio, antes de borrar la red. El borrado masivo evitaba el método que convierte una fila en deleted y actualiza su hora. Para la base, la fila desaparecía; para el lector del delta, nunca había sucedido.

El segundo hueco afectaba a algunas redes: su estado pasaba a deleted, pero updated seguía mostrando el valor anterior. El informe incluye redes cuya baja estaba asociada a 2026 y cuya marca de actualización seguía en 2022. Una consulta desde un cursor reciente no puede recuperar una novedad que el servidor fechó en el pasado. El problema no es que el cliente pregunte poco: pregunta exactamente por la interfaz que PeeringDB documenta.

El tamaño observado y el tamaño desconocido

El autor del informe encontró 286 relaciones netixlan borradas de forma directa, vinculadas a 125 redes durante aproximadamente seis meses. Detectó además 46 redes eliminadas sin avance en updated. Son las cuentas de esa comparación; el número total de clientes afectados no aparece en el expediente. Una nota posterior del 9 de octubre describió el error contrario: 569 relaciones todavía activas en la fuente faltaban en la copia, repartidas entre 349 redes y 279 intercambios. El informe propuso dos explicaciones sin cerrar la investigación: una transacción que se hizo visible demasiado tarde para su hora declarada, o una restauración sin cambiar updated.

Esta distinción evita meter todos los fallos en la misma caja. Una baja que no emite un aviso deja un fantasma. Un alta o restauración que no llega deja un agujero. Los dos dañan una copia, pero el remedio que corrige el primero no prueba que el segundo desapareció. El expediente aporta ejemplos concretos y un camino de reproducción para las bajas. Para las 569 filas ausentes aún falta la secuencia de transacción y visibilidad que establezca la causa.

El 20 de octubre, PeeringDB integró el cambio 81ac767. Quitó la instrucción que eliminaba de golpe las relaciones activas y dejó actuar a la eliminación propia de la red. La prueba añadida crea red, intercambio, relaciones y contacto; ejecuta la limpieza por estado RIR; verifica que las filas quedan deleted con tiempos nuevos y que una petición ?since= devuelve esas bajas. El criterio de éxito está en la respuesta que consumirá un espejo. Un test que solo comprobara el estado interno de la base habría pasado por alto la mitad importante del problema.

Las notas de lanzamiento sitúan la versión 2.84.0 el 21 de octubre y mencionan el ticket #2057 entre sus correcciones de sincronización. La tabla de calendario señalaba el día 20 como fecha prevista de producción. El compromiso registrado por el lanzamiento es una ruta de borrado corregida. El expediente también deja claro el coste retrospectivo: un cliente que guardó los registros antiguos debe hacer una sincronización completa para desprenderse de ellos.

La deuda viaja hacia el consumidor

Un objeto ya eliminado de modo irreversible no puede emitir ahora el aviso que omitió meses atrás. Tampoco se verá una baja con updated anclado en 2022 mediante un cursor situado en 2026. La comparación íntegra con la fuente vuelve a ser la herramienta útil. PeeringDB no publicó una lista de espejos reconstruidos ni una métrica de desfase residual. Una cuenta verificable de esas reconstrucciones diría cuánto pasado quedó atrás tras el arreglo.

El borrador de API v3 propone una disciplina más explícita: los deltas deben mostrar bajas y retiradas, y las instantáneas diarias ofrecen punto de partida y recuperación. Sigue siendo un borrador. En el caso de 2.84.0, el principio ya se puede examinar sin esperar a v3: borrar una fila de una base no basta para retirar ese dato de las copias que la institución fomentó. Hace falta una noticia con identidad, fecha y forma legible para quien pregunta qué cambió.

Aquí reside el conflicto institucional. PeeringDB controla la fuente, el código que borra y la respuesta de la API. Cada operador controla su copia y su calendario de reconciliación. El cambio de octubre arregla una parte concreta del puente. Los registros viejos que cruzaron antes siguen del lado del lector hasta que éste vuelva a mirar el conjunto entero.