Resumen

  • WebJanssen tiene un negocio activo de hosting y comunicaciones, pero el nombre utilizado en este artículo ya no es el que muestra su propio aviso legal. El sitio de la empresa indica que la sede se trasladó a Miami Platja, España, el 1 de octubre de 2025 y que la denominación oficial pasó a ser WebJanssen U.Janssen. El registro RIPE y varias páginas comerciales antiguas aún utilizan WebJanssen ISP ltd & Co KG o WebJanssen ISP UG. Un comprador debe verificar la parte contratante en lugar de asumir que la continuidad de la marca implica continuidad legal.
  • AS29471 está activo. RIPEstat observó tres anuncios IPv4 el 11 de julio de 2026:195.140.208.0/22,195.225.208.0/22y195.158.54.0/24, cubriendo 2.304 direcciones. Todos eran visibles para cada par con alimentación completa IPv4 en RIPE RIS en el momento de la observación. La misma vista no mostró ningún anuncio IPv6.
  • La evidencia de ruteo actual muestra una red adyacente, Aixit AS29551, para los tres prefijos. El registro de políticas RIPE de WebJanssen's describe KleyReX y numerosos pares históricos, mientras que una entrada antigua de PeeringDB lista dos instalaciones en Frankfurt, pero ninguna establece un segundo upstream actual. Por lo tanto, la diversidad lógica y física de rutas debe considerarse no probada.
  • WebJanssen identifica la ubicación de su centro de datos como en atención de Aixit en Rebstoeckerstrasse 55, Frankfurt. Aixit describe entradas redundantes al edificio, 20 operadores, casi 1.000 Gbit/s de ancho de banda agregado, más de 300 interconexiones, UPS, generación de emergencia y diseño de red redundante en ese sitio. Esas son capacidades de la instalación anfitriona, no evidencia de que WebJanssen contrate dos rutas de operador independientes, dos alimentaciones eléctricas o capacidad reservada de todas ellas.
  • La oferta minorista convierte la recuperación en una decisión económica. WebJanssen anuncia servidores virtuales limitados a 10 o 100 Mbit/s, copia de seguridad de imagen opcional, una respuesta estándar en un día hábil y niveles de servicio de pago con respuesta en cuatro horas. Su aviso legal indica que el servicio de emergencia fuera de horario genera cargos por intervención. Los clientes afectados por una pérdida de upstream, fallo del host, incidente eléctrico o escasez de técnicos disponibles necesitan que el contrato especifique quién responde, desde dónde y en qué plazo.
  • Se puede demostrar que la red está operativa, pero la calificación de evidencia de resiliencia es Débil. Un solo upstream visible, sin IPv6 enrutado, protección de origen de ruta para solo uno de tres prefijos, registros de interconexión antiguos y sin registro de restauración publicado dejan demasiada incertidumbre para afirmar una red de acceso regional resiliente. En cambio, la evidencia respalda una pequeña red de hosting centrada en Frankfurt operada bajo una identidad comercial transfronteriza.

El nombre sobrevivió mientras la identidad contratante cambiaba

El primer problema no es la pérdida de paquetes. Es identificar quién promete restaurar el servicio. El nombre WebJanssen ISP ltd & Co KG permanece vinculado a AS29471 en elregistro RDAP de RIPE, y es el nombre existente bajo el cual se encuentra comúnmente a la empresa. Sin embargo, la propiapágina de noticiasde WebJanssen dice que su sede se trasladó a España el 1 de octubre de 2025 y que su denominación oficial pasó a ser WebJanssen U.Janssen. Elaviso legalactual da una dirección en Miami Platja, Tarragona, y un identificador fiscal español.

Esto no es una nota al pie cosmética. Un cliente puede usar la marca, el nombre del sistema autónomo y la empresa contratante de manera indistinta en una conversación, pero esas etiquetas responden a preguntas diferentes. La marca le dice al cliente dónde buscar ayuda. El registro AS le dice a otras redes qué identidad de enrutamiento origina las direcciones. El contrato determina quién debe el servicio, quién lo factura, qué ley se aplica y quién debe organizar una reparación. Cuando esas etiquetas divergen, el comprador necesita documentos actuales que las vinculen explícitamente.

Las páginas públicas no lo hacen de manera clara. Lostérminos y condicionesde WebJanssen's indican que la parte contratante es WebJanssen ISP UG (haftungsbeschraenkt), mientras que el aviso legal nombra a WebJanssen U.Janssen. Una página alemana de datos comerciales describe unaWebJanssen UG activa, registrada en Oldenburg en 2022 para proporcionar servicios de telecomunicaciones, hosting, housing, red y administración, y para actuar como socio general de una sociedad WebJanssen. Este registro secundario respalda la continuidad del negocio en Alemania, pero no resuelve qué persona o empresa firma un nuevo acuerdo de servicio con sede en España en 2026.

Hay otra ruptura histórica. El registro de Companies House del Reino Unido paraWEBJANSSEN ISP LIMITEDdice que esa empresa se constituyó en 2001 y se disolvió el 31 de marzo de 2020. Suhistorial de presentacionesincluye cuentas de empresa inactiva antes de la cancelación forzosa. El nombre exacto y los directivos compartidos hacen que el registro sea un contexto relevante, pero la evidencia pública aquí revisada no prueba el papel legal que la empresa del Reino Unido desempeñó en su momento en la sociedad alemana. Sería imprudente ignorar la disolución o inferir que eso puso fin a la red operativa.

La evidencia de red apunta en sentido contrario: el servicio continuó. El sitio web de la empresa está activo, las páginas de productos actuales aceptan negocio, los portales de soporte y clientes están vinculados, y AS29471 era visible en los datos de enrutamiento global el 11 de julio de 2026. La conclusión correcta es limitada. WebJanssen sigue siendo una marca y red operativa, mientras que la identidad legal detrás de los nuevos compromisos de servicio necesita confirmación.

Una orden de compra debe nombrar a la contraparte actual, el registro fiscal, la ley aplicable, la ubicación del servicio y la entidad responsable de los datos y equipos tras la finalización. Esa claridad administrativa es parte de la resiliencia, porque una interrupción es el peor momento para descubrir que el registro de red, la factura y el contacto de emergencia se refieren a formas legales diferentes.

La oferta es primero de hosting, no una red probada de acceso local

La categoría "ISP" puede sugerir postes, conductos, acometidas de fibra, torres inalámbricas y equipos de campo que se desplazan a las instalaciones del cliente. La oferta pública actual de WebJanssen respalda una imagen diferente. Supágina de iniciodestaca espacio web, servidores virtuales, Microsoft Exchange alojado, archivado de correo electrónico y VPN. Suárea de clienteenlaza a controles separados para servidores Windows y Exchange, servidores Linux, administración de servidores virtuales, webmail y soporte. Estas son las interfaces de un proveedor de hosting y servicios gestionados.

Losplanes de espacio webofrecen entornos Linux o Windows, capacidad de dominio, buzones, bases de datos, acceso FTP, certificados SSL y paneles de control. Losplanes de servidores raízson máquinas virtuales construidas sobre Xen, con direcciones fijas, funciones de consola remota y administración gestionada opcional. Lapágina de Exchange alojadocombina buzones, filtrado de spam y virus, funciones de calendario y libreta de direcciones, acceso web y archivado opcional. Ninguna de estas páginas ofrece un mapa de hogares pasados, armarios de calle, sectores de torres, rutas de fibra o equipos de instalación.

Esa ausencia es importante porque cambia la dependencia física que se analiza. Un servidor alojado puede ser "local" para un cliente alemán en el sentido de que su rack está en Frankfurt, su soporte telefónico es familiar y su operador es pequeño. No es un circuito de última milla hasta el edificio del cliente. El cliente sigue llegando a WebJanssen a través de un proveedor de acceso independiente, un enrutador local, la alimentación eléctrica de la oficina y la ruta pública de Internet.

WebJanssen controla la máquina alojada, la dirección asignada, la configuración del servicio y su propio enrutamiento de borde; no controla por ello la conexión de fibra o móvil desde cada cliente hasta Frankfurt.

La distinción también cambia quién sufre cuando falla el servicio. Una interrupción del servidor raíz puede tumbar el sitio web, el servidor de correo, el servicio de juegos, el servidor de nombres o la aplicación empresarial de un cliente. Un incidente de Exchange puede interrumpir las comunicaciones de una pequeña empresa incluso si el acceso a Internet común funciona. Un fallo de AS29471 puede hacer que muchos dominios alojados no relacionados sean inaccesibles a la vez.

Por el contrario, un cable de acceso local cortado en la oficina de un cliente puede dejar todos los sistemas de WebJanssen en buen estado, pero impedir que ese cliente llegue a ellos.

La escala pública de WebJanssen parece coherente con un host especializado.La vista de AS29471 de IPinfoclasifica la red como hosting, cuenta 2.304 direcciones IPv4 enrutadas e informa de cientos de dominios alojados. El número de dominios alojados es una observación, no un recuento de clientes: un cliente puede operar muchos dominios, muchos dominios pueden compartir una dirección y nombres inactivos pueden permanecer apuntando a un servidor antiguo. Aun así, la combinación de productos de hosting, paneles de control, sistemas de correo y uso de direcciones es una evidencia más sólida que la etiqueta de ISP regional para entender la carga operativa.

La "factura de conectividad local" del título del artículo debe interpretarse, por tanto, como la factura por una conexión alojada con soporte local, no como prueba de una planta de acceso propiedad de WebJanssen. Los activos consecuentes son racks, sistemas host, almacenamiento, energía, refrigeración, entregas de fibra, enrutamiento de borde, servicios de nombres y correo, repuestos y personal capaz de trabajar en ellos. Torres, postes e instalaciones en las dependencias del cliente solo serían relevantes si un contrato específico mostrara que WebJanssen los suministró. No se encontró tal evidencia pública.

Una sola dirección en Frankfurt ancla el servicio físico

La evidencia de ubicación más sólida proviene del propio operador. El aviso legal actual de WebJanssen identifica su centro de datos como WebJanssen U. Janssen, a la atención de Aixit GmbH, Rebstoeckerstrasse 55, 60326 Frankfurt am Main. Esa es la misma dirección que Aixit da paraAIX-FRA-1, su centro de datos y sede en Frankfurt. La dirección vincula las páginas comerciales de WebJanssen a una instalación específica en lugar de a una afirmación genérica de "hosting alemán".

Aixit afirma que el edificio tiene más de 4.000 metros cuadrados de espacio de centro de datos, entradas redundantes desde 20 operadores, casi 1.000 Gbit/s de ancho de banda y acceso a más de 300 pares nacionales e internacionales. Describe sistemas de UPS, refrigeración, energía de emergencia y conectividad, y dice que el diseño de la red es redundante desde la base. Lapágina de empresade Aixit dice que se expandió en el sitio de Rebstoeckerstrasse tras mudarse allí a finales de 2018. Estas afirmaciones hacen del sitio una base física plausible para una red pequeña que necesita racks y elección de operador.

Pero el menú de una instalación no es la configuración de un inquilino. Que veinte operadores entren en un edificio no significa que WebJanssen compre tránsito de veinte operadores. Dos entradas de edificio no prueban que su rack tenga dos conexiones cruzadas siguiendo rutas independientes. Los sistemas de UPS y generadores de toda la instalación no garantizan que un armario concreto tenga alimentaciones A y B, que ambas se usen correctamente o que un servidor con una sola fuente de alimentación pueda sobrevivir a la pérdida de una vía de distribución.

Casi 1.000 Gbit/s de ancho de banda agregado no dice nada sobre la capacidad comprometida con AS29471.

La misma precaución se aplica a la propiedad. Aixit opera el entorno del centro de datos y AS29551; WebJanssen anuncia servicios instalados allí y origina direcciones a través de AS29471. El material público no dice si WebJanssen es propietaria de los chasis de sus servidores, alquila sistemas completos, arrienda unidades de rack, compra una plataforma gestionada o combina esas modalidades. Tampoco dice quién es dueño de los transceptores ópticos y los enrutadores de borde en el punto de entrega. Esos límites determinan quién dispone de repuestos y quién puede tocar el equipo durante un incidente.

Elregistro de red de PeeringDB para AS29471enumera dos instalaciones en Frankfurt: "aixit Frankfurt" y "Digital Realty Frankfurt FRA28 (Cerrado)". Sin embargo, sus asociaciones de centro de datos se actualizaron por última vez en 2016, y el mismo registro no muestra ninguna conexión activa a un punto de intercambio público. La etiqueta de instalación cerrada y la antigua fecha de actualización hacen que la entrada sea útil como historia, no como una afirmación actual de redundancia en dos sitios. No puede respaldar la conclusión de que WebJanssen tenga dos ubicaciones operativas en Frankfurt.

No hay un segundo centro de datos de WebJanssen publicado en otra ciudad, ni diagrama de alimentación a nivel de rack ni sitio de recuperación declarado. La visión física más segura es un servicio centrado en Frankfurt en la dirección de Aixit, con opciones de instalación más amplias disponibles pero con la resiliencia específica del inquilino sin revelar. La sede española es una ubicación comercial y de soporte, no evidencia de que los servidores de producción se hayan trasladado a España. Las propias páginas de WebJanssen siguen situando el centro de datos en Frankfurt después de la mudanza de la sede.

AS29471 está activo, es visible globalmente y solo IPv4

Un sistema autónomo no es una empresa, un servidor o un edificio. Es una identidad de enrutamiento utilizada para aplicar políticas y originar espacio de direcciones alcanzable. AS29471, no obstante, proporciona la mejor evidencia independiente de que la red de WebJanssen está operativa.La vista general de AS de RIPEstatlo marcó como anunciado el 11 de julio de 2026 y nombró al titular como WebJanssen-DE, WebJanssen ISP ltd & Co KG.

Lavista de estado de enrutamientomostró tres prefijos IPv4 que cubren 2.304 direcciones. Los 325 pares RIS con alimentación completa IPv4 en la instantánea vieron las rutas. La ruta más reciente se observó esa mañana, y la primera ruta atribuida al AS en el historial de RIPEstat data de octubre de 2003. Esto es una fuerte evidencia de continuidad en el borde del plano de control: la red no es simplemente un listado comercial obsoleto o un número de AS sin usar.

Lavista de prefijos anunciadosidentificó195.140.208.0/22,195.225.208.0/22y195.158.54.0/24. Cada /22 contiene 1.024 direcciones IPv4 y el /24 contiene 256, dando el total de 2.304. Vistas de red separadas de RIPEstat confirman a AS29471 como el origen observado para195.140.208.0/22,195.225.208.0/22y195.158.54.0/24.

El sitio web de la empresa añade una verificación a nivel de servicio. Lavista de cadena DNS de RIPEstat para webjanssen.deresolvió el sitio a195.140.208.58, dentro del primer /22, el 11 de julio. El sitio público de ventas se sirve, por tanto, desde una dirección originada actualmente por AS29471. Eso no prueba dónde se encuentra la máquina, pero conecta la actividad comercial actual con la huella de enrutamiento activa.

No apareció ningún prefijo IPv6 en la vista de estado de enrutamiento. PeeringDB también enumera cero prefijos IPv6 y dice que IPv6 no es compatible, aunque ese perfil se actualizó por última vez en 2022. El regulador de comunicaciones electrónicas de Francia, ARCEP, incluyó a AS29471 en subarómetro de hosting IPv6 de 2025y mostró una disponibilidad IPv6 nula para la muestra alojada en WebJanssen analizada. Esa prueba implicó una muestra muy pequeña y no es un inventario completo, pero coincide con la ausencia actual de IPv6 enrutado.

La operación solo IPv4 no implica una interrupción inmediata. Los clientes aún pueden acceder a los servicios a través de IPv4, y los mecanismos de traducción pueden tender puentes sobre algunos entornos de acceso IPv6. Sí significa que la red carece de una segunda familia de direcciones nativa que muchos hosts contemporáneos ofrecen. Más importante para la resiliencia, la ausencia reduce la superficie de enrutamiento: no hay un servicio IPv6 visible que pueda permanecer accesible a través de una ruta diseñada por separado si falla la política IPv4.

La pila dual no es automáticamente diversa, pero una sola pila elimina incluso esa posibilidad.

El número de direcciones tampoco debe confundirse con la capacidad de transferencia. Los nueve equivalentes /24 indican cuánto espacio IPv4 único es visible, no cuántos bits por segundo puede transportar la red. Un /22 mayormente inactivo puede tener poco ancho de banda; un /24 ocupado puede transportar un tráfico considerable. El recuento tampoco establece clientes, procesadores, almacenamiento o capacidad sobrante. Confirma una huella de direcciones no trivial y duradera adecuada para hosting y correo, nada más.

Todas las rutas actuales pasan por Aixit

La concentración central aparece un salto fuera de AS29471. Lavista de vecinos ASN de RIPEstatmostró una única red adyacente el 11 de julio de 2026: AS29551. La posición observada sitúa a AS29551 a la izquierda de WebJanssen en los caminos hacia la tabla global.bgp.toolsenumera independientemente a Aixit AS29551 como el único upstream para los tres prefijos IPv4 y cuenta un solo upstream.

Lavista de historial de enrutamiento de un año de RIPEstathace explícita la misma dependencia. Para cada uno de los tres prefijos, el par de origen observado es29551 29471: el tráfico aprendido a través del conjunto de colectores ve a Aixit inmediatamente antes de WebJanssen. Los colectores de rutas no ven todas las interconexiones privadas, y los contratos comerciales no son rutas BGP públicas. Aun así, la observación consistente en tres prefijos es la evidencia actual más sólida disponible.

Elregistro AS de la base de datos RIPEcontiene una descripción de políticas mucho más rica. Declara a AS29551 como upstream, a KleyReX AS31142 como plataforma de peering y a numerosos pares con nombre. Esto podría parecer una amplia diversidad si se lee como un mapa de topología en vivo. No lo es. El registro fue modificado por última vez en julio de 2021, y las declaraciones de políticas de ruta pueden sobrevivir a las sesiones, puertos y contratos. Las observaciones actuales de vecinos y el recuento de cero intercambios activos de PeeringDB no corroboran esas declaraciones de pares más antiguas.

KleyReX en sí sigue activo. Susitio oficialdescribe una infraestructura de intercambio conmutada que abarca más de 15 ubicaciones y ofrece puertos desde 100 Mbit/s hasta múltiples 100 Gbit/s. Eso establece un entorno de peering disponible en Frankfurt, no la participación actual de WebJanssen en él. Una línea en un registro de enrutamiento antiguo muestra intención o historia; se necesitaría un puerto actual, un registro de miembro de intercambio o una ruta de par observada para contarlo como una alternativa funcional.

Aixit no es un upstream arbitrario. Su sitio en Frankfurt es también la dirección del centro de datos que publica WebJanssen. Esa coubicación puede hacer que las operaciones sean eficientes: un inquilino puede comprar una conexión cruzada corta, llegar a la red del proveedor sin un circuito de larga distancia y obtener ayuda presencial cerca del equipo. También crea un límite común. Si los servidores de WebJanssen, la entrega de borde y el único upstream visible dependen todos de un proveedor en un edificio, un incidente de red de Aixit o un evento a nivel de sitio puede afectar tanto al alojamiento como al transporte conjuntamente.

Los datos públicos no pueden establecer que este límite común sea total. WebJanssen puede tener una conexión privada oculta a los colectores de rutas, un respaldo inactivo, un túnel u otro servicio que no anuncie los tres prefijos. Esas posibilidades no deben tratarse como salvaguardas operativas hasta que se prueben. La compra de resiliencia no puede depender de rutas que aparecen solo después de una interrupción a menos que el proveedor pueda demostrar que están aprovisionadas, monitorizadas, autorizadas para originar los prefijos y son capaces de transportar el tráfico pico.

La protección de origen de ruta cubre solo uno de tres anuncios

La concentración de enrutamiento no es el único problema del plano de control. La Infraestructura de Clave Pública de Recursos (RPKI) permite que un titular de direcciones publique una Autorización de Origen de Ruta declarando qué AS puede originar un prefijo. Otras redes pueden comparar un anuncio con esa autorización y rechazar o reducir la preferencia de los orígenes no válidos. Laexplicación de validación de origen BGP de RIPE NCCdescribe esto como una forma para que los operadores establezcan políticas según la validez del origen de la ruta.

Para WebJanssen, el resultado actual es mixto. RIPEstat informa195.158.54.0/24 como válidopara el origen AS29471. Elhistorial RPKI para AS29471mostró una autorización que cubre 256 direcciones a principios de julio de 2026. En otras palabras, el espacio protegido es el /24, aproximadamente el 11 por ciento de las 2.304 direcciones IPv4 enrutadas.

Las otras dos rutas erandesconocidas para 195.140.208.0/22ydesconocidas para 195.225.208.0/22en la misma verificación. Desconocido no significa inválido. Significa que ninguna autorización validada coincidente cubría ese origen y prefijo, por lo que las redes que validan el origen no pueden usar una autorización positiva para distinguir el anuncio legítimo de AS29471 de un origen no autorizado únicamente mediante este control.

Incluso el /24 válido no es a prueba de interrupciones. La validación de origen no prueba toda la ruta AS, no garantiza que los paquetes lleguen al servidor correcto, no previene cada fuga de ruta ni preserva el servicio durante un fallo del upstream. Reduce una clase de error o ataque de enrutamiento. Su valor práctico también depende de que otras redes apliquen la validación. Aun así, la cobertura es un control de higiene medible, y cubrir solo uno de tres anuncios deja una clara oportunidad de mejora.

La combinación de un único upstream observado y protección de origen parcial merece atención porque cada una aborda un riesgo diferente. Un segundo upstream funcional puede preservar la alcanzabilidad cuando falla un operador. Una autorización puede ayudar a otras redes a rechazar un origen no autorizado. Ninguna sustituye a la otra. Añadir una autorización no crearía una segunda ruta física; contratar otro operador no autorizaría automáticamente el nuevo acuerdo de enrutamiento ni protegería contra un origen incorrecto.

Un comprador no necesita exigir acceso a las configuraciones de los enrutadores. Puede solicitar una lista actual de prefijos originados, el estado de autorización, los números de AS upstream, el comportamiento de conmutación por error probado y la fecha del último ejercicio de pérdida de tránsito. La respuesta debe separar las rutas de producción de los registros antiguos. En el caso de WebJanssen, las observaciones de enrutamiento público respaldan una ruta de producción y un prefijo autorizado, por lo que afirmaciones más sólidas requieren evidencia directa.

La capacidad de la instalación no es la capacidad de WebJanssen

Las afirmaciones de la instalación de Aixit son impresionantes en comparación con los límites comerciales anunciados de WebJanssen. Casi 1.000 Gbit/s de ancho de banda del sitio y más de 300 interconexiones describen un gran mercado de conectividad. Los productos de servidor raíz de WebJanssen, por el contrario, anuncian tráfico de tarifa plana a 10 Mbit/s para los niveles privado y empresarial, y 100 Mbit/s para los niveles profesional y gestionado. PeeringDB describe el nivel de tráfico de AS29471 como 20-100 Mbit/s, aunque ese rango autoinformado se actualizó por última vez hace años.

Estas cifras ocupan capas diferentes. El número de la instalación es la capacidad instalada agregada entre muchos clientes y redes. El número del servidor virtual es un límite por producto. El rango de PeeringDB es una estimación categórica antigua del tráfico intercambiado por AS29471. Ninguno muestra la utilización actual en el puerto upstream de WebJanssen, la tasa de información comprometida comprada a Aixit, la capacidad de ráfaga, la pérdida de paquetes bajo carga o el margen disponible después de un fallo.

La capacidad utilizable durante un incidente puede ser mucho menor que la capacidad instalada normal. Supongamos que un proveedor tiene dos enlaces de 100 Mbit/s y normalmente envía 60 Mbit/s por cada uno. Perder uno deja 100 Mbit/s para 120 Mbit/s de demanda, por lo que una topología que parece redundante aún se congestiona. En el caso público de WebJanssen, la premisa es aún menos cierta porque un segundo enlace actual no es visible. La ruta restante debe absorber todo el tráfico solo si existe una ruta restante.

Los límites del servidor introducen otro cuello de botella. Un cliente que compra un servidor virtual de 10 Mbit/s no puede inferir una recuperación más rápida o más margen del agregado a escala de terabits del centro de datos. La entrada/salida de almacenamiento, la planificación del hipervisor, el tráfico de copias de seguridad, la capacidad del cortafuegos y el filtrado de denegación de servicio pueden convertirse cada uno en la restricción determinante antes de que se llene el puerto upstream. Las páginas de productos especifican CPU virtual, memoria, disco y tasas de tráfico, pero no publican ratios de contención ni rendimiento medido.

El inventario IPv4 tampoco es una reserva de capacidad. Las direcciones pueden asignarse sin consumir ancho de banda, y las direcciones agotadas pueden limitar el crecimiento de clientes incluso cuando los enlaces están inactivos. WebJanssen anuncia una dirección fija en servidores raíz estándar y hasta cinco en algunos productos gestionados. Ese uso es coherente con cargas de trabajo de hosting, correo y servicio de nombres. No revela cuánto de la huella de 2.304 direcciones sigue siendo asignable.

Para un cliente empresarial, la especificación comercial útil es, por tanto, específica del servicio: rendimiento comprometido y de ráfaga, política de congestión, manejo de denegación de servicio, efectos de la ventana de copias de seguridad, objetivos de pérdida de paquetes y latencia, y capacidad disponible tras el mayor fallo único. Un folleto de la instalación puede mostrar que existen opciones de expansión. No puede mostrar que se hayan comprado para un servidor en particular.

La redundancia eléctrica termina en el enchufe más débil

El edificio de Frankfurt es la principal dependencia física común. Aixit dice que AIX-FRA-1 utiliza tecnología moderna de UPS, energía de emergencia, refrigeración y conectividad, con diseño de red redundante y múltiples entradas al edificio. Susitio corporativo principaltambién dice que sus centros de datos tienen certificación ISO 27001 y funcionan con energía renovable. Estas son afirmaciones útiles del anfitrión, pero WebJanssen no publica la configuración del rack que las convertiría en una garantía de servicio de extremo a extremo.

La resiliencia eléctrica es una cadena. Las alimentaciones de la red eléctrica entran al edificio, los cuadros de distribución las reparten, los sistemas UPS puentean la interrupción, los generadores sostienen cortes más largos, las unidades de alimentación del rack suministran a los dispositivos, y cada servidor o enrutador convierte ese suministro. La redundancia en un punto puede ser anulada en el siguiente. Un rack con doble alimentación no ayuda a un dispositivo con una sola fuente conectada a una regleta. Dos fuentes conectadas a la misma regleta no crean independencia de ruta.

Un generador no garantiza continuidad sin combustible, mantenimiento, transferencia automática y pruebas de carga exitosas.

Las páginas de productos de WebJanssen no indican si los sistemas anfitriones de servidores raíz tienen fuentes de alimentación duales, si los enrutadores de borde están emparejados o si las réplicas de almacenamiento se encuentran en zonas separadas de incendio y electricidad. La virtualización Xen puede mover o reiniciar cargas de trabajo en algunos diseños, pero la afirmación de WebJanssen de que Xen hace que los servidores sean altamente resistentes a fallos no revela la agrupación, la migración en vivo, los dominios de fallo del almacenamiento compartido o la capacidad de hosts de repuesto.

La virtualización cambia cómo se maneja un fallo de máquina; no elimina el host físico subyacente.

La refrigeración es igualmente consecuente. Una sala de datos puede mantener la alimentación de la red eléctrica mientras las temperaturas aumentan tras un fallo del enfriador o del tratamiento del aire. La generación de emergencia debe soportar suficiente refrigeración además de la carga informática, o los servidores se apagarán para protegerse. Aixit dice que el sitio utiliza refrigeración actual y diseño redundante, pero ninguna de las partes publica umbrales de temperatura específicos de WebJanssen, pruebas de conmutación por error o comportamiento de apagado.

También hay una cuestión geográfica. La dirección comercial oficial está ahora en España y el centro de datos en Alemania. La operación remota es normal en el hosting, pero divide la autoridad del alcance físico. Una persona que contesta el teléfono puede ser capaz de diagnosticar un servidor fallido pero incapaz de reemplazar una fuente de alimentación sin acceso a Frankfurt. Un técnico de la instalación puede ser capaz de volver a asentar un cable, pero carecer de permiso o conocimientos de configuración para reemplazar un enrutador.

El tiempo de recuperación es la suma de detección, diagnóstico, autorización, viaje o envío, acceso, piezas, reparación y validación.

La evidencia pública respalda un buen potencial de la instalación. No respalda una afirmación específica de WebJanssen de mantenibilidad concurrente, continuidad en dos sitios u operación autónoma durante un evento eléctrico regional prolongado. Los clientes para quienes una hora importa necesitan que la alimentación del rack, la autonomía del generador, la redundancia de refrigeración, la propiedad del hardware de repuesto y los términos de intervención remota estén escritos en su servicio, no inferidos de la dirección.

El precio del servicio compra una velocidad particular de respuesta humana

Los proveedores pequeños a menudo compiten mediante la familiaridad. La página de inicio de WebJanssen dice que el soporte está disponible por correo electrónico, ticket o teléfono. Su aviso legal publica horarios laborales de lunes a jueves y horario reducido los viernes, con un servicio de emergencia facturable fuera de esos periodos. La página de servidores raíz dice que los extras gratuitos incluyen una respuesta en un día hábil, mientras que los niveles de servicio de pago pueden ofrecer una respuesta en cuatro horas.

Esto es inusualmente revelador porque convierte la mano de obra en parte del producto. Un servidor virtual de 19,99 € o 49,99 € al mes no incluye la misma obligación de respuesta que una plataforma de alta disponibilidad diseñada. La copia de seguridad opcional y la respuesta más rápida opcional permiten un precio de partida bajo, pero también dejan más riesgo de recuperación en manos del cliente. El servidor más barato puede ser totalmente adecuado para un sitio de afición; es una propuesta diferente para la nómina, el correo electrónico de clientes o un sistema de transacciones.

El tiempo de respuesta no es el tiempo de restauración. Una respuesta en cuatro horas puede significar que un ingeniero acusa recibo del ticket, comienza el diagnóstico o comunica un plan. No significa necesariamente que el servicio vaya a funcionar en cuatro horas. Una respuesta en un día hábil puede extenderse a lo largo de un fin de semana dependiendo de cuándo ocurra el fallo. Las páginas públicas no definen niveles de gravedad, inicio del cómputo, escalado, crédito, reemplazo de piezas, objetivo de restauración ni número máximo de incidencias simultáneas.

La frase "gastos de intervención" en el aviso legal también es significativa. Sugiere que alguna intervención fuera de horario es trabajo físico facturable en lugar de un servicio incluido automáticamente las 24 horas. La página no identifica si esas manos pertenecen al personal de WebJanssen, al de Aixit o a otro contratista. Todas pueden ser modalidades eficaces, pero tienen diferentes colas y autoridad. Un técnico del centro de datos puede atender a muchos inquilinos durante un evento que afecta a toda la instalación; un propietario-operador puede conocer la red en profundidad pero tener una capacidad paralela limitada.

No se encontró ningún recuento público actual de personal, cuadro de turnos, inventario de repuestos o registro de envíos. Sería incorrecto inferir un soporte deficiente de ese silencio. Sería igualmente incorrecto inferir un centro de operaciones de red atendido las 24 horas a partir de un número de teléfono. La evidencia disponible respalda un soporte accesible en horario laboral, una respuesta más rápida opcional y una intervención de emergencia facturable.

Este límite de mano de obra es donde la estructura transfronteriza se vuelve operativamente importante. El diagnóstico puede hacerse desde España, el enrutamiento puede cambiarse de forma remota y el software puede reiniciarse desde un panel de control. Los componentes ópticos, discos, fuentes de alimentación, cables y sistemas anfitriones fallidos aún requieren a alguien en Frankfurt o cerca. La resiliencia de una factura de hosting de bajo coste depende, por tanto, de si hay manos capacitadas y repuestos compatibles disponibles cuando varios clientes los necesitan a la vez.

Cinco fallos revelan lo que la factura no dice

La primera prueba es la pérdida del tránsito de Aixit. Las rutas públicas actuales muestran a AS29551 inmediatamente aguas arriba de AS29471 para los tres prefijos. Si esa sesión BGP, entrega o ruta de proveedor falla y no hay ningún respaldo oculto activo, los prefijos pueden desaparecer de Internet en general incluso si todos los servidores de WebJanssen permanecen encendidos. La recuperación requeriría restaurar la sesión, mover los anuncios a una alternativa preautorizada o reparar la entrega compartida. Una antigua línea de política de KleyReX no es evidencia suficiente de tal respaldo.

La segunda es un evento eléctrico o de la instalación en Rebstoeckerstrasse. Un incidente en el edificio puede afectar conjuntamente a los sistemas anfitriones, al equipo de borde y al upstream adyacente. El UPS y la generación pueden reducir la probabilidad de interrupción, pero la evidencia pública no muestra sitios separados de WebJanssen ni una copia en vivo en otro lugar. Los clientes cuyas aplicaciones existen solo en un servidor virtual pueden perder tanto la computación como la conectividad al mismo tiempo.

La tercera es un fallo del host, del almacenamiento o del hipervisor. Xen puede aislar máquinas virtuales y permitir una gestión flexible, pero un host fallido aún necesita capacidad de repuesto para reiniciar o migrar. El almacenamiento compartido puede preservar los datos a la vez que se convierte en un punto de fallo común; el almacenamiento local puede aislar fallos a la vez que complica la recuperación. WebJanssen vende copia de seguridad de imagen opcional pero no indica objetivos de punto de recuperación o tiempo de recuperación.

Una copia de seguridad que existe pero no ha sido restaurada en condiciones realistas es recuperación potencial, no recuperación probada.

La cuarta es la congestión o un ataque. Un producto de 10 o 100 Mbit/s puede verse abrumado muy por debajo de la capacidad agregada de la instalación. Un evento de denegación de servicio puede saturar el límite del cliente, la entrega de WebJanssen o un filtro upstream. La oferta pública no cuantifica la capacidad de mitigación ni los acuerdos de limpieza. Los clientes deben distinguir una etiqueta de facturación de tráfico ilimitado del ancho de banda instantáneo ilimitado; una tarifa plana de tráfico elimina un contador de uso, no un límite de velocidad física.

La quinta es la escasez de mano de obra durante un incidente amplio. Un disco fallido en un día laborable puede ser sencillo. Un evento de la red eléctrica, una alarma de refrigeración o un fallo de red que afecte a muchos inquilinos puede crear tickets y tareas físicas simultáneas. El primer técnico disponible debe priorizar, obtener acceso y localizar piezas. Ni una línea directa en horario laboral ni una promesa de respuesta en cuatro horas dice cuántas incidencias pueden manejarse en paralelo.

Varios otros fallos pueden situarse por encima de esta infraestructura. Un cliente puede configurar mal el DNS, perder credenciales, dejar caducar un certificado o eliminar datos. Un operador de acceso local puede fallar mientras el servicio alojado permanece en buen estado. El objetivo no es asignar cada problema a WebJanssen; es separar la responsabilidad para que cada fallo tenga un propietario y una ruta de recuperación probada.

Lo que una afirmación de resiliencia necesitaría demostrar

Para la diversidad de upstream, la evidencia decisiva sería un segundo operador actual o conexión de intercambio que transporte rutas de producción, visible en las observaciones actuales o demostrada en una conmutación por error controlada. La segunda ruta debe verificarse en cuanto a conductos compartidos, entradas, salas de interconexión, alimentación eléctrica y dependencias upstream. Dos sesiones BGP entregadas a través de una sola conexión cruzada protegen contra algunos fallos de enrutador, pero no contra un cable cortado.

Para la seguridad de enrutamiento, los dos anuncios desconocidos /22 podrían cubrirse con autorizaciones de origen apropiadas si los titulares de direcciones y los acuerdos operativos lo permiten. Los objetos de ruta, filtros de prefijos y contactos actuales deben coincidir con la topología de producción. Las declaraciones de políticas históricas deben eliminarse o distinguirse claramente para que clientes y pares no las confundan con capacidad activa.

Para la continuidad de la instalación, WebJanssen necesitaría identificar si los dispositivos críticos tienen alimentación dual, si la capacidad del host sobrevive a un fallo de chasis, dónde residen las copias de seguridad y cuánto tiempo pueden soportar la carga relevante la generación y la refrigeración. Una copia en un segundo sitio necesitaría un dominio de fallo independiente y un método de activación probado. Simplemente nombrar otro edificio o almacenar medios de copia de seguridad en otro lugar no establecería la recuperación de la aplicación.

Para la mano de obra, la evidencia útil incluiría definiciones de gravedad, objetivos de acuse de recibo y restauración, autoridad fuera de horario, propiedad de la intervención remota, cobertura de piezas de repuesto y el resultado de ejercicios de reparación recientes. El comprador debe saber si el compromiso de cuatro horas se aplica de forma continua o solo en ciertos horarios y si termina en la primera respuesta.

Para la continuidad comercial, el próximo contrato debe conciliar WebJanssen U.Janssen, WebJanssen ISP UG y el nombre vinculado a AS29471. Debe identificar qué parte controla los datos del cliente, los dominios, las direcciones y los equipos, y qué parte sigue siendo responsable si un subcontratista u operador de instalaciones cambia. La cuestión no es si un nombre histórico puede permanecer en un registro de enrutamiento. Es si el firmante actual puede controlar todas las dependencias necesarias para restaurar el servicio adquirido.

Ninguna de estas peticiones requiere que un pequeño operador publique diagramas sensibles. Una carta de garantía concisa, un programa de servicio actual y el resultado de una conmutación por error presenciada pueden establecer mucho más que un adjetivo de marketing. El estándar debe escalar según las consecuencias del fallo para el cliente: un sitio web de folleto puede necesitar poco más que una copia de seguridad restaurable, mientras que una plataforma de correo empresarial necesita una recuperación probada, un escalado claro y comunicaciones alternativas.

La economía recompensa la claridad más que la escala

Los precios de WebJanssen hacen visible por qué persiste el hosting especializado. Una pequeña empresa puede comprar un entorno Linux o Windows gestionado, buzones, dominios y soporte telefónico sin tener que dotar de personal su propia sala de servidores. El proveedor puede repartir un rack en Frankfurt, la entrega upstream, las licencias de software y el conocimiento de ingeniería entre muchos clientes. La instalación más grande de Aixit reparte la alimentación, la refrigeración, la seguridad y el acceso a operadores entre muchos inquilinos. Cada capa convierte la infraestructura abultada en una factura mensual.

La misma estratificación puede ocultar la concentración. WebJanssen puede parecer ofrecer servidor, conectividad, correo electrónico y copia de seguridad como productos diferentes, pero pueden compartir el mismo edificio, upstream y técnicos. Un cliente puede comprar varios servicios y creer que tiene diversidad cuando todos fallan a la vez. El precio bajo no es el problema; lo son las dependencias comunes no examinadas.

La copia de seguridad opcional y la respuesta más rápida son económicamente racionales. No toda carga de trabajo merece replicación sincrónica o intervención inmediata, y cobrar a cada cliente por el nivel más alto haría que el hosting básico no fuera rentable. Lo importante es que el cliente compre deliberadamente. Una copia de seguridad de imagen opcional debe indicar la frecuencia, la retención, la ubicación y la responsabilidad de restauración. Una respuesta de pago debe indicar qué acción ocurre y qué sucede si el hardware no está disponible.

El peering también podría mejorar la economía de las redes pequeñas al mantener parte del tráfico fuera del tránsito de pago, acortar las rutas y reducir la dependencia del upstream. La antigua política RIPE de WebJanssen apunta a KleyReX, cuya oferta de peering básico gratuito está diseñada precisamente para este tipo de operador. Sin embargo, las observaciones actuales no muestran una conexión de intercambio activa. La oportunidad económica no es lo mismo que una salvaguarda instalada.

La instalación ofrece otra vía de expansión. Aixit dice que puede proporcionar conexiones cruzadas a los principales operadores e intercambios, por lo que WebJanssen está ubicado donde se puede obtener diversidad adicional. Si comprarla está justificado depende de los ingresos de los clientes en riesgo, el coste de un segundo puerto y la capacidad del operador para soportar la complejidad añadida. Un segundo camino que nunca se supervisa ni se ejercita puede crear una falsa confianza y errores de enrutamiento.

Para los clientes, la comparación justa es el coste total de continuidad en lugar de la partida del servidor. Eso incluye el acceso a Frankfurt, la copia de seguridad de la aplicación, el correo electrónico alternativo o las comunicaciones de estado, la mano de obra de recuperación y el impacto en los ingresos del tiempo de inactividad. WebJanssen puede seguir siendo competitivo sin imitar a un proveedor de hiperescala, pero su propuesta más sólida sería la precisión: qué está incluido, qué se comparte, qué es opcional y cómo se manejan los fallos.

Una red especializada activa con una divulgación de resiliencia débil

La pregunta sobre el estado operativo puede responderse con más firmeza que la de la resiliencia. AS29471 está activo, sus tres rutas IPv4 eran visibles globalmente, webjanssen.de se resuelve en una de ellas, las páginas de ventas y soporte siguen disponibles y el operador nombra una dirección actual de centro de datos en Frankfurt. El anuncio de la sede de octubre de 2025 es reciente. Estos hechos respaldan un negocio en curso, no una red abandonada.

No respaldan la imagen implícita en una amplia categoría de ISP regional. No hay evidencia pública de fibra de última milla propia, torres inalámbricas, acometidas de cliente, licencias de acceso local o equipos de campo que presten servicio en un territorio de acceso. La evidencia respalda a un especialista en hosting y comunicaciones cuya red pública está centrada en Frankfurt y cuya dirección comercial está ahora en España. "Global" describe mejor el alcance de Internet y el antiguo campo de alcance de PeeringDB que un área de servicio físico documentada.

La evidencia de resiliencia es Débil porque las incógnitas restantes se encuentran en la ruta crítica. Un solo upstream observado transporta los tres prefijos. No se ve ninguna ruta IPv6. Solo un prefijo tiene autorización de origen de ruta positiva. Los datos de peering e instalación son antiguos o autoinformados. La instalación anfitriona anuncia sólidas capacidades generales, pero no se publica ningún diseño específico de WebJanssen sobre alimentación, rutas o segundo sitio. La respuesta humana se describe en horas, pero la restauración, la profundidad de los turnos y las piezas no.

Una evidencia débil no es una predicción de fallo. Es un límite a lo que se puede afirmar responsablemente. Un operador pequeño y experimentado en una capaz instalación de Frankfurt puede ofrecer un servicio fiable durante años. El registro público simplemente no establece la independencia de Aixit, la recuperación ante un gran evento de modo común o la respuesta física inmediata fuera del horario normal.

Esa distinción debe orientar la compra. Un sitio web de bajo impacto puede aceptar la concentración y mantener una copia de seguridad portable. Un cliente de misión crítica debe obtener la contraparte legal actual, el diseño de rutas, la disposición eléctrica, los términos de recuperación de copias de seguridad y el compromiso del técnico antes de confiar en la conexión. La factura mensual es local y sencilla; la continuidad depende de una cadena que cruza una sede española, un rack en Frankfurt, un único upstream visible y las manos disponibles cuando algo físico se rompe.