Resumen

  • NovaCloud-Hosting (Tech Tide Portugal Unipessoal LDA, AS209874) declaró resuelta el 8 de agosto de 2026 su caída Major en el centro FFM2, iniciada el 20 de julio de 2026; seis semanas después, el registro público de enrutamiento y de registro no muestra corrección medible de las contradicciones documentadas en la cobertura previa.
  • Cuatro listas de upstreams mutuamente incompatibles siguen coexistiendo: la micrositio ASN del operador nombra PletX (AS62403), Tube-Hosting (AS49581) e IP-Projects (AS48314); bgp.tools muestra SMARTNET (AS203446), Tube-Hosting (AS49581) y TELE90 (AS215787); ipregistry repite el trío del operador; y la propia narrativa del incidente nombra AS203446, AS215787 y PletX.
  • El prefijo 5.83.150.0/24, registrado por el operador el 3 de febrero de 2026 bajo ORG-TTPU1-RIPE con geofeed y un route object, sigue sin ser visible en la tabla de enrutamiento global según bgp.tools.
  • Los espejos de registry discrepan sobre la propia fecha de creación del route object: 28 de abril de 2025 en bgp.tools frente a 11 de septiembre de 2026 en ipregistry, lo que hace inservible cualquier cronología fechada de la red basada solo en fuentes públicas.

Cuando NovaCloud-Hosting declaró resuelto el incidente FFM2 el 8 de agosto de 2026, la pregunta natural era si las semanas siguientes acercarían el registro público del operador a sí mismo. La respuesta, con una lectura fresca de las fuentes de enrutamiento y de registro del 1 de octubre de 2026, es que no. Las brechas documentadas en la cobertura de BTW del 29 y 30 de septiembre —entre lo que el operador anuncia y lo que terceros pueden observar— siguen en pie y, en algunos aspectos, se han agudizado.

Empecemos por las listas de upstreams. En su propio micrositio ASN, el operador sigue nombrando tres upstreams activos: AS62403 PletX GmbH, AS49581 Ferdinand Zink (Tube-Hosting) y AS48314 IP-Projects GmbH & Co. KG, todos marcados Active https://as209874.net/. La imagen observada por terceros es distinta. bgp.tools muestra el conjunto actual de upstreams de AS209874 como AS203446 SMARTNET LIMITED, AS49581 Tube-Hosting y AS215787 TELE90 Telecom GmbH https://bgp.tools/as/209874 —un conjunto que excluye por completo a PletX e IP-Projects. ipregistry, un espejo derivado del registro, repite el trío del operador (AS48314, AS49581, AS62403) en datos fechados el 26 de febrero de 2026 https://ipregistry.co/AS209874. Y la propia narrativa del incidente de julio nombró a AS203446, AS215787 y PletX como las rutas de tránsito operativas https://novacloud-hosting.instatus.com/cmrsxwgnz06wh1ao0b04o4obb. Son cuatro combinaciones a través de tres clases de fuentes, ninguna idéntica, y la comparación con la base del 30 de septiembre no muestra deriva hacia la convergencia.

El incidente sigue siendo el ancla de cualquier comparación temporal. El registro de estado del operador data la caída Major de FFM2 del 20 de julio de 2026 al 8 de agosto de 2026 —19 días— y atribuye los fallos de túnel y conexiones TCP a una "false filtering" de PletX que descartaba tráfico GRE/TCP https://novacloud-hosting.instatus.com/cmrsxwgnz06wh1ao0b04o4obb. Además, el mismo registro de incidente está duplicado en un segundo subdominio instatus con fechas idénticas https://novacloud.instatus.com/cmrsxwgnz06wh1ao0b04o4obb, fragmentando la propia historia de estado del operador. Y al 1 de octubre de 2026, la página principal de estado sigue mostrando un banner de "Potential Disruption Affecting FFM2" mientras el incidente de julio figura como Resolved —dos estados de incidente coexistiendo en las superficies del propio operador https://novacloud-hosting.instatus.com/.

La brecha más clara es un prefijo que existe en el registro pero no en la tabla de enrutamiento. bgp.tools marca 5.83.150.0/24 como no visible en la DFZ, aunque el prefijo lleva un inetnum de RIPE (netname NovaCloudHosting, org ORG-TTPU1-RIPE, creado el 3 de febrero de 2026) y un route object con origen AS209874 https://bgp.tools/prefix/5.83.150.0/24. El objeto organización detrás está bien formado: ORG-TTPU1-RIPE es Tech Tide Portugal Unipessoal LDA, registrada en Quarteira, Portugal, el 8 de noviembre de 2024, y el inetnum lleva country DE, el mantenedor GHOSTNET-MNT, una nota de que los datos IP son gestionados por noez.de y un geofeed en cdn.web.novacloud-hosting.com https://ipregistry.co/AS209874/5.83.150.0/24. Dicho de otro modo, todo el papeleo que debería preceder a la enrutabilidad está presente —y la ruta sigue sin anunciarse. Es la brecha anunciado-contra-operable en su forma más pura, y seis semanas después de la caída sigue sin cambios.

Incluso el fechado del papeleo está en disputa. bgp.tools presenta el route object de 5.83.150.0/24 como creado el 28 de abril de 2025; la reproducción del mismo objeto en ipregistry muestra una fecha de creación del 11 de septiembre de 2026 https://bgp.tools/prefix/5.83.150.0/24. Para una red cuyas afirmaciones comerciales descansan en la velocidad de construcción, un registro público que no puede ponerse de acuerdo sobre cuándo existió su propio route object es más que una nota al pie: significa que ninguna cronología independiente de esta red puede armarse a partir de espejos públicos sin declarar en qué espejo se confía y por qué.

Añádase el objeto aut-num. El registro RIPE de AS209874 lleva as-name TECHTIDE, org ORG-MWUL2-RIPE, sponsoring-org ORG-SL1164-RIPE, mantenedores RIPE-NCC-END-MNT, SBL-MNT y novacloud-mnt, creado el 24 de abril de 2025 y modificado por última vez el 26 de febrero de 2026 https://apps.db.ripe.net/db-web-ui/query?searchtext=AS209874&types=aut-num. La organización nombrada allí (ORG-MWUL2-RIPE) difiere de la organización del prefijo (ORG-TTPU1-RIPE), mientras que la entidad legal nombrada en la portada del operador —Tech Tide Portugal Unipessoal LDA, VAT PT517354420, fundada en 2023, con infraestructura reclamada en Frankfurt, Núremberg y Eygelshoven https://novacloud-hosting.com/ — coincide con la del lado del prefijo. La portada también afirma una ASN propia con tránsito IP de doble pila por Europa https://as209874.net/, exactamente el anuncio que el registro de terceros pone a prueba.

¿Y el peering? bgp.tools lista 9 pares y 6 downstreams para AS209874 https://bgp.tools/as/209874, mientras que ipregistry afirma sin matices que la ASN no tiene acuerdos directos de peering y alcanza internet solo a través de proveedores de tránsito https://ipregistry.co/AS209874. Las dos fuentes discrepan en una pregunta básica y binaria: si esta red hace peering o no. Espejos complementarios añaden textura sin resolución: ipinfo lleva cifras que divergen de bgp.tools en recuento de prefijos https://ipinfo.io/AS209874, y un espejo whois de terceros registra 5.231.96.0/24 entre las pertenencias del operador https://whois.ipip.net/AS209874/5.231.96.0/24. La cobertura previa de BTW documentó el mismo patrón de divergencia de espejos el 29 de septiembre https://btw.media/en/novacloud-as209874-routing-mirrors y la brecha de servicio anunciado en la re-verificación de primera mano del 29 de septiembre https://btw.media/en/novacloud-hosting-announced-versus-routed.

Una superficie adicional del operador añade inestabilidad en lugar de claridad: una segunda página de estado instatus duplica el registro del incidente y lleva sus propias cifras de prefijos y upstreams https://novacloud-hosting.instatus.com/cmrodnyxv06gz0kmrkcnlpw2v. Una única extracción de la infraestructura de estado del operador pierde, por tanto, parte del registro —una trampa metodológica para quien siga este objetivo.

La conclusión es negativa y está formulada con precisión: comparada con la base del 30 de septiembre de 2026, la imagen de upstreams y originación de bgp.tools es esencialmente inalterada, 5.83.150.0/24 sigue siendo solo registro, las listas de upstreams no concuerdan entre sí ni con el as-set del registro, y ninguna fuente pública ha corregido las contradicciones documentadas en la cobertura previa https://btw.media/en/novacloud-as209874-routing-mirrors. Seis semanas después de una caída de 19 días, el registro público de esta red no está convergiendo hacia la verdad: está quieto.