Zusammenfassung

  • WebJanssen betreibt ein aktives Hosting- und Kommunikationsgeschäft, aber der Name in diesem Artikel entspricht nicht mehr dem Namen, der im eigenen Impressum angezeigt wird. Die Unternehmensseite gibt an, dass der Hauptsitz am 1. Oktober 2025 nach Miami Platja, Spanien, verlegt wurde und die offizielle Bezeichnung WebJanssen U.Janssen lautet. Die RIPE-Registrierung und mehrere ältere kommerzielle Seiten verwenden weiterhin WebJanssen ISP ltd & Co KG oder WebJanssen ISP UG. Ein Käufer sollte die Vertragspartei überprüfen und nicht davon ausgehen, dass Markenkontinuität rechtliche Kontinuität bedeutet.
  • AS29471 ist aktiv. RIPEstat beobachtete am 11. Juli 2026 drei IPv4-Ankündigungen:195.140.208.0/22,195.225.208.0/22und195.158.54.0/24, insgesamt 2.304 Adressen. Alle waren zum Beobachtungszeitpunkt für jeden IPv4-Full-Feed-Peer in RIPE RIS sichtbar. Dieselbe Ansicht zeigte keine IPv6-Ankündigung.
  • Die aktuellen Routenbelege zeigen ein benachbartes Netzwerk, Aixit AS29551, für alle drei Präfixe. WebJanssens RIPE-Policy-Record beschreibt KleyReX und zahlreiche historische Peers, während ein älterer PeeringDB-Eintrag zwei Frankfurter Einrichtungen auflistet, aber keiner stellt einen zweiten aktuellen Upstream dar. Logische und physikalische Routendiversität sollten daher als unbewiesen gelten.
  • WebJanssen gibt seinen Rechenzentrumsstandort mit "c/o Aixit, Rebstoeckerstrasse 55 in Frankfurt" an. Aixit beschreibt redundante Gebäudezugänge, 20 Carrier, fast 1.000 Gbit/s aggregierte Bandbreite, über 300 Peerings, USV, Notstrom und redundantes Netzwerkdesign an diesem Standort. Dies sind Host-Facility-Fähigkeiten, kein Beleg dafür, dass WebJanssen zwei unabhängige Carrier-Pfade, doppelte Stromversorgung oder reservierte Kapazität bei allen kauft.
  • Das Einzelhandelsangebot macht die Wiederherstellung zu einer wirtschaftlichen Entscheidung. WebJanssen bewirbt virtuelle Server mit 10 oder 100 Mbit/s, optionales Image-Backup, eine Standardantwort innerhalb eines Werktags und kostenpflichtige Service-Level mit einer Antwort innerhalb von vier Stunden. Das Impressum besagt, dass der Notdienst außerhalb der Geschäftszeiten mit Handaufschlag berechnet wird. Kunden, die von einem Upstream-Ausfall, Host-Ausfall, Stromproblem oder Mangel an verfügbaren Technikern betroffen sind, benötigen im Vertrag die Angabe, wer, wo und innerhalb welcher Zeit reagiert.
  • Das Netzwerk ist nachweislich in Betrieb, aber die Beweislage für die Ausfallsicherheit ist schwach. Ein sichtbarer Upstream, kein geroutetes IPv6, Routenursprungsschutz für nur eines von drei Präfixen, alte Interkonnektionsaufzeichnungen und kein veröffentlichter Wiederherstellungsverlauf lassen zu viele Unsicherheiten, um ein widerstandsfähiges regionales Zugangsnetz zu beanspruchen. Die Belege stützen stattdessen ein kleines, auf Frankfurt zentriertes Hosting-Netzwerk, das unter einer grenzüberschreitenden kommerziellen Identität betrieben wird.

Der Name überlebte, während die Vertragspartei wechselte

Das erste Problem ist kein Paketverlust. Es ist die Identifizierung, wer verspricht, den Dienst wiederherzustellen. Der Name WebJanssen ISP ltd & Co KG bleibt mit AS29471 imRIPE-RDAP-Eintragverbunden, und es ist der bestehende Name, unter dem das Unternehmen allgemein bekannt ist. Doch WebJanssens eigeneNachrichtenseitesagt, dass sein Hauptsitz am 1. Oktober 2025 nach Spanien umgezogen ist und die offizielle Bezeichnung WebJanssen U.Janssen wurde. Das aktuelleImpressumgibt eine Adresse in Miami Platja, Tarragona, und eine spanische Steuernummer an.

Dies ist keine kosmetische Fußnote. Ein Kunde mag die Marke, den Autonomen-System-Namen und die Vertragsgesellschaft im Gespräch austauschbar verwenden, aber diese Bezeichnungen beantworten unterschiedliche Fragen. Die Marke sagt dem Kunden, wo er Hilfe suchen kann. Die AS-Registrierung teilt anderen Netzen mit, welche Routing-Identität die Adressen ursprünglich ankündigt. Der Vertrag bestimmt, wer den Dienst schuldet, wer ihn in Rechnung stellt, welches Recht gilt und wer eine Reparatur organisieren muss. Wenn diese Bezeichnungen auseinanderfallen, benötigt der Käufer aktuelle Dokumente, die sie explizit miteinander verknüpfen.

Die öffentlichen Seiten tun dies nicht sauber. WebJanssensAllgemeine Geschäftsbedingungenbesagen, dass die Vertragspartei WebJanssen ISP UG (haftungsbeschränkt) ist, während das Impressum WebJanssen U.Janssen nennt. Eine deutsche Handelsregister-Seite beschreibt eineaktive WebJanssen UG, die 2022 in Oldenburg eingetragen wurde, um Telekommunikations-, Hosting-, Housing-, Netzwerk- und Verwaltungsdienstleistungen zu erbringen und als persönlich haftende Gesellschafterin einer WebJanssen-Partnerschaft zu fungieren. Dieser sekundäre Eintrag stützt die geschäftliche Kontinuität in Deutschland, löst aber nicht, welche Person oder Firma 2026 einen neuen, in Spanien ansässigen Servicevertrag unterzeichnet.

Es gibt einen weiteren historischen Bruch. Der Eintrag des britischen Companies House fürWEBJANSSEN ISP LIMITEDbesagt, dass diese Gesellschaft 2001 gegründet und am 31. März 2020 aufgelöst wurde. IhreEinreichungshistorieenthält ruhende Konten vor der Zwangsauflösung. Der exakte Name und gemeinsame Geschäftsführer machen den Eintrag zu einem relevanten Kontext, aber die hier geprüften öffentlichen Belege beweisen nicht die rechtliche Rolle, die das britische Unternehmen einst in der deutschen Partnerschaft spielte. Es wäre unsicher, die Auflösung zu ignorieren oder daraus zu schließen, dass sie das operative Netzwerk beendete.

Die Netzwerkbelege weisen in die andere Richtung: Der Dienst wurde fortgesetzt. Die Unternehmenswebsite ist live, aktuelle Produktseiten akzeptieren Geschäfte, die Support- und Kundenportale sind verlinkt, und AS29471 war am 11. Juli 2026 in globalen Routing-Daten sichtbar. Die korrekte Schlussfolgerung ist eng. WebJanssen bleibt eine operierende Marke und ein Netzwerk, während die rechtliche Identität hinter neuen Serviceverpflichtungen bestätigt werden muss.

Ein Kaufauftrag sollte den aktuellen Vertragspartner, die Steuernummer, das anzuwendende Recht, den Service-Standort und die für Daten und Geräte nach Beendigung verantwortliche Einheit nennen. Diese administrative Klarheit ist Teil der Ausfallsicherheit, da ein Ausfall der schlechteste Zeitpunkt ist, um festzustellen, dass die Netzwerkregistrierung, die Rechnung und der Notfallkontakt sich auf unterschiedliche Rechtsformen beziehen.

Das Angebot ist zuerst Hosting, kein nachgewiesenes lokales Zugangsnetz

Die Kategorie "ISP" kann Masten, Leitungen, Glasfaserabzweige, Funkmasten und Feldtechniker, die zu Kundenstandorten fahren, suggerieren. WebJanssens aktuelles öffentliches Angebot stützt ein anderes Bild. IhreStartseiteführt mit Webspace, virtuellen Servern, gehostetem Microsoft Exchange, E-Mail-Archivierung und VPN. DerKundenbereichverlinkt zu separaten Steuerungen für Windows-Server und Exchange, Linux-Server, virtuelle Serververwaltung, Webmail und Support. Dies sind die Schnittstellen eines Hosting- und Managed-Service-Anbieters.

DieWebspace-Plänebieten Linux- oder Windows-Umgebungen, Domainkapazität, Mailboxen, Datenbanken, FTP-Zugriff, SSL-Zertifikate und Control Panels. DieRoot-Server-Plänesind virtuelle Maschinen auf Basis von Xen mit festen Adressen, Remote-Konsolenfunktionen und optionaler verwalteter Administration. DieHosted-Exchange-Seitekombiniert Mailboxen, Spam- und Virenfilter, Kalender- und Adressbuchfunktionen, Webzugriff und optionales Archivieren. Keine dieser Seiten bietet eine Karte der versorgten Haushalte, Straßenkästen, Funkzellensektoren, Glasfaserrouten oder Installationsteams.

Dieses Fehlen ist wichtig, weil es die analysierte physische Abhängigkeit verändert. Ein gehosteter Server kann für einen deutschen Kunden in dem Sinne "lokal" sein, dass sein Rack in Frankfurt steht, der Telefonsupport vertraut ist und der Betreiber klein ist. Es ist kein letzte-Meile-Kreis zum Gebäude des Kunden. Der Kunde erreicht WebJanssen weiterhin über einen separaten Zugangsanbieter, lokalen Router, Bürostrom und öffentlichen Internetpfad.

WebJanssen kontrolliert die gehostete Maschine, die zugewiesene Adresse, die Servicekonfiguration und sein eigenes Border-Routing; es kontrolliert damit nicht die Glasfaser- oder Mobilverbindung von jedem Kunden nach Frankfurt.

Die Unterscheidung ändert auch, wer leidet, wenn der Dienst ausfällt. Ein Root-Server-Ausfall kann die Website, den Mailserver, den Spieldienst, den Nameserver oder die Geschäftsanwendung eines Kunden lahmlegen. Ein Exchange-Vorfall kann die Kommunikation einer kleinen Firma unterbrechen, selbst während der normale Internetzugang funktioniert. Ein Ausfall von AS29471 kann viele nicht zusammenhängende gehostete Domains gleichzeitig unerreichbar machen. Umgekehrt kann ein durchtrenntes lokales Zugangskabel im Büro eines Kunden alle WebJanssen-Systeme gesund lassen, während der Kunde sie nicht erreichen kann.

WebJanssens öffentliche Größenordnung erscheint konsistent mit einem spezialisierten Host.IPinfos AS29471-Ansichtklassifiziert das Netzwerk als Hosting, zählt 2.304 geroutete IPv4-Adressen und meldet Hunderte gehosteter Domains. Die Anzahl der gehosteten Domains ist eine Beobachtung, keine Kundenanzahl: Ein Kunde kann viele Domains betreiben, viele Domains können sich eine Adresse teilen, und inaktive Namen können auf einen alten Server zeigen. Dennoch ist die Kombination aus Hosting-Produkten, Control Panels, Mail-Systemen und Adressnutzung ein stärkerer Beleg als das Etikett "Regionaler ISP" für das Verständnis der Betriebslast.

Der Artikel-Titel "Eine lokale Konnektivitätsrechnung" sollte daher als die Rechnung für eine lokal unterstützte gehostete Verbindung gelesen werden, nicht als Beleg für eine WebJanssen-eigene Zugangsanlage. Die wesentlichen Vermögenswerte sind Racks, Hostsysteme, Speicher, Strom, Kühlung, Glasfaserübergaben, Border-Routing, Namens- und Maildienste, Ersatzteile und Personen, die daran arbeiten können. Türme, Masten und Installationen beim Kunden würden nur relevant, wenn ein spezifischer Vertrag zeigte, dass WebJanssen sie bereitstellt. Es wurden keine solchen öffentlichen Belege gefunden.

Eine Frankfurter Adresse verankert den physischen Dienst

Der stärkste Standortbeleg stammt vom Betreiber selbst. WebJanssens aktuelles Impressum gibt sein Rechenzentrum an als WebJanssen U. Janssen, c/o Aixit GmbH, Rebstoeckerstrasse 55, 60326 Frankfurt am Main. Dies ist dieselbe Adresse, die Aixit fürAIX-FRA-1, sein Frankfurter Rechenzentrum und seinen Hauptsitz, angibt. Die Adresse verbindet WebJanssens kommerzielle Seiten mit einer bestimmten Einrichtung und nicht mit einer allgemeinen Behauptung von "deutschem Hosting".

Aixit sagt, das Gebäude verfüge über mehr als 4.000 Quadratmeter Rechenzentrumsfläche, redundante Gebäudezugänge von 20 Carriern, fast 1.000 Gbit/s Bandbreite und Zugang zu mehr als 300 nationalen und internationalen Peers. Es beschreibt USV, Kühlung, Notstrom- und Konnektivitätssysteme und sagt, das Netzwerkdesign sei von Grund auf redundant. AixitsUnternehmensseitesagt, es habe sich nach dem Umzug Ende 2018 am Standort Rebstoeckerstrasse erweitert. Diese Behauptungen machen den Standort zu einer plausiblen physischen Basis für ein kleines Netzwerk, das Racks und Carrier-Auswahl benötigt.

Aber die Speisekarte einer Einrichtung ist nicht die Konfiguration eines Mieters. 20 Carrier, die ein Gebäude betreten, bedeuten nicht, dass WebJanssen Transit von 20 Carriern kauft. Zwei Gebäudezugänge beweisen nicht, dass sein Rack zwei Cross-Connects auf unabhängigen Wegen hat. USV- und Generatorsysteme für die gesamte Einrichtung belegen nicht, dass ein bestimmter Schrank A- und B-Stromversorgungen hat, dass beide Versorgungen korrekt genutzt werden, oder dass ein Server mit einem einzigen Netzteil den Verlust eines Verteilungsweges überlebt.

Fast 1.000 Gbit/s aggregierte Bandbreite sagen nichts über die für AS29471 gebuchte Kapazität aus.

Die gleiche Vorsicht gilt für das Eigentum. Aixit betreibt die Rechenzentrumsumgebung und AS29551; WebJanssen bewirbt dort installierte Dienste und kündigt Adressen über AS29471 an. Das öffentliche Material sagt nicht, ob WebJanssen seine Server-Chassis besitzt, komplette Systeme least, Rack-Einheiten mietet, eine verwaltete Plattform kauft oder diese Arrangements kombiniert. Es sagt auch nicht, wem die optischen Transceiver und Border-Router am Übergabepunkt gehören. Diese Grenzen bestimmen, wer Ersatzteile hält und wer bei einem Vorfall Geräte berühren darf.

PeeringDBsNetzwerkeintrag für AS29471listet zwei Frankfurter Einrichtungen: "aixit Frankfurt" und "Digital Realty Frankfurt FRA28 (Geschlossen)". Die Datenzentrumszuordnungen wurden jedoch zuletzt 2016 aktualisiert, und derselbe Eintrag zeigt keine aktive öffentliche Exchange-Verbindung. Die Bezeichnung "geschlossene Einrichtung" und das alte Aktualisierungsdatum machen den Eintrag als Geschichte nützlich, nicht als aktuelle Zwei-Standort-Redundanzbehauptung. Er kann keine Schlussfolgerung stützen, dass WebJanssen zwei betriebsbereite Frankfurter Standorte hat.

Es gibt kein veröffentlichtes zweites WebJanssen-Rechenzentrum in einer anderen Stadt, kein Rack-Level-Stromdiagramm und keinen erklärten Wiederherstellungsstandort. Die sicherste physische Ansicht ist ein auf Frankfurt zentrierter Dienst an der Aixit-Adresse, mit breiteren Einrichtungsoptionen, aber mandantenspezifischer Ausfallsicherheit, die nicht offengelegt ist. Der spanische Hauptsitz ist ein kommerzieller und Support-Standort, kein Beleg dafür, dass Produktionsserver nach Spanien verlegt wurden. WebJanssens eigene Seiten verorten das Rechenzentrum auch nach dem Hauptsitzumzug weiterhin in Frankfurt.

AS29471 ist aktiv, global sichtbar und IPv4-only

Ein Autonomes System ist keine Firma, kein Server und kein Gebäude. Es ist eine Routing-Identität, die verwendet wird, um Richtlinien anzuwenden und erreichbaren Adressraum anzukündigen. AS29471 liefert dennoch den besten unabhängigen Beleg, dass WebJanssens Netzwerk in Betrieb ist.RIPEstats AS-Übersichtmarkierte es am 11. Juli 2026 als angekündigt und nannte den Inhaber WebJanssen-DE, WebJanssen ISP ltd & Co KG.

DieRouting-Status-Ansichtmeldete drei IPv4-Präfixe mit 2.304 Adressen. Alle 325 IPv4-Full-Feed-RIS-Peers im Snapshot sahen die Routen. Die aktuellste Route wurde an diesem Morgen beobachtet, und die erste dem AS in RIPEstats Historie zugeschriebene Route stammt vom Oktober 2003. Dies ist ein starkes Indiz für Kontinuität an der Control-Plane-Kante: Das Netzwerk ist nicht nur ein veralteter Geschäftseintrag oder eine ungenutzte AS-Nummer.

DieAnsicht der angekündigten Präfixeidentifizierte195.140.208.0/22,195.225.208.0/22und195.158.54.0/24. Jedes /22 enthält 1.024 IPv4-Adressen und das /24 enthält 256, was die Gesamtzahl von 2.304 ergibt. Separate RIPEstat-Netzwerkansichten bestätigen AS29471 als den beobachteten Ursprung für195.140.208.0/22,195.225.208.0/22und195.158.54.0/24.

Die Unternehmenswebsite fügt eine servicebezogene Querverbindung hinzu. RIPEstatsDNS-Chain-Ansicht für webjanssen.delöste die Site am 11. Juli zu195.140.208.58auf, innerhalb des ersten /22. Die öffentliche Verkaufsseite wird daher von einer Adresse bedient, die derzeit von AS29471 stammt. Das beweist nicht, wo die Maschine steht, verbindet aber die aktuelle kommerzielle Aktivität mit dem Live-Routing-Fußabdruck.

In der Routing-Status-Ansicht erschien kein IPv6-Präfix. PeeringDB listet ebenfalls null IPv6-Präfixe und sagt, dass IPv6 nicht unterstützt wird, obwohl dieses Profil zuletzt 2022 aktualisiert wurde. Die französische Regulierungsbehörde für elektronische Kommunikation ARCEP nahm AS29471 in ihrenIPv6-Hosting-Barometer 2025auf und zeigte eine IPv6-Verfügbarkeit von null für die getestete WebJanssen-gehostete Stichprobe. Dieser Test umfasste eine sehr kleine Stichprobe und ist keine vollständige Bestandsaufnahme, stimmt aber mit dem derzeitigen Fehlen von geroutetem IPv6 überein.

IPv4-only-Betrieb bedeutet keinen sofortigen Ausfall. Kunden können die Dienste weiterhin über IPv4 erreichen, und Übersetzungsmechanismen können einige IPv6-Zugangsumgebungen überbrücken. Es bedeutet jedoch, dass das Netzwerk keine native zweite Adressfamilie hat, die viele zeitgenössische Hosts bieten. Wichtiger für die Ausfallsicherheit: Das Fehlen schmälert die Routing-Oberfläche: Es ist kein sichtbarer IPv6-Dienst vorhanden, der über einen separat ausgelegten Pfad erreichbar bleiben könnte, falls die IPv4-Richtlinie versagt. Dual-Stack ist nicht automatisch divers, aber Single-Stack eliminiert selbst diese Möglichkeit.

Die Adressanzahl sollte auch nicht mit dem Durchsatz verwechselt werden. Die neun /24-Äquivalente sagen, wie viel einzigartiger IPv4-Raum sichtbar ist, nicht wie viele Bits pro Sekunde das Netzwerk transportieren kann. Ein meist untätiges /22 kann wenig Bandbreite haben; ein ausgelastetes /24 kann erheblichen Verkehr tragen. Auch die Anzahl begründet keine Kunden, Prozessoren, Speicher oder Reservekapazität. Sie bestätigt einen nicht trivialen, langlebigen Adressfußabdruck, der für Hosting und E-Mail geeignet ist, nicht mehr.

Jede aktuelle Route führt durch Aixit

Die zentrale Konzentration zeigt sich einen Hop außerhalb von AS29471. RIPEstatsASN-Nachbarn-Ansichtzeigte am 11. Juli 2026 ein eindeutiges benachbartes Netzwerk: AS29551. Die beobachtete Position platziert AS29551 links von WebJanssen in Pfaden zur globalen Tabelle.bgp.toolslistet unabhängig Aixit AS29551 als einzigen Upstream für alle drei IPv4-Präfixe und zählt einen Upstream.

Die einjährigeRIPEstat-Routing-Verlaufsansichtmacht dieselbe Abhängigkeit explizit. Für jedes der drei Präfixe ist das beobachtete Ursprungspaar29551 29471: Der über das Collector-Set gelernte Verkehr sieht Aixit unmittelbar vor WebJanssen. Route-Collectors sehen nicht jede private Interkonnektion, und kommerzielle Verträge sind keine öffentlichen BGP-Pfade. Dennoch ist die konsistente Beobachtung über drei Präfixe der stärkste derzeit verfügbare Beleg.

DerRIPE-Datenbank-AS-Eintragenthält eine viel reichhaltigere Policy-Beschreibung. Er erklärt AS29551 als Upstream, KleyReX AS31142 als Peering-Plattform und zahlreiche benannte Peers. Dies könnte wie eine breite Diversität aussehen, wenn es als Live-Topologiekarte gelesen wird. Es ist nicht. Der Eintrag wurde zuletzt im Juli 2021 geändert, und Routing-Policy-Erklärungen können Sitzungen, Ports und Verträge überdauern. Aktuelle Nachbarbeobachtungen und PeeringDBs Nullanzahl aktiver Exchanges bestätigen diese älteren Peer-Aussagen nicht.

KleyReX selbst ist weiterhin aktiv. Seineoffizielle Sitebeschreibt eine vermittelte Exchange-Fabric, die sich über mehr als 15 Standorte erstreckt und Ports von 100 Mbit/s bis zu mehreren 100 Gbit/s anbietet. Dies schafft eine verfügbare Frankfurter Peering-Umgebung, nicht WebJanssens derzeitige Teilnahme daran. Eine Zeile in einem alten Routing-Eintrag zeigt Absicht oder Geschichte; ein aktueller Port, Exchange-Member-Eintrag oder beobachteter Peer-Pfad wäre erforderlich, um es als funktionierende Alternative zu zählen.

Aixit ist kein willkürlicher Upstream. Sein Frankfurter Standort ist auch die Rechenzentrumsadresse, die WebJanssen veröffentlicht. Diese Colocation kann den Betrieb effizient machen: Ein Mieter kann eine kurze Cross-Connect kaufen, das Netzwerk des Anbieters ohne lange Tail Circuit erreichen und Hilfe vor Ort in der Nähe der Geräte erhalten. Sie schafft auch eine gemeinsame Grenze. Wenn WebJanssens Server, Border-Übergabe und der einzige sichtbare Upstream alle von einem Anbieter an einem Standort abhängen, kann ein Aixit-Netzwerkvorfall oder ein standortweites Ereignis sowohl Hosting als auch Transport gemeinsam betreffen.

Die öffentlichen Daten können nicht belegen, dass diese gemeinsame Grenze vollständig ist. WebJanssen kann eine private Verbindung haben, die vor Route-Collectors verborgen ist, einen ruhenden Backup, einen Tunnel oder einen anderen Dienst, der die drei Präfixe nicht ankündigt. Diese Möglichkeiten sollten nicht als Betriebssicherungen behandelt werden, bis sie getestet sind. Der Kauf von Ausfallsicherheit kann sich nicht auf Pfade verlassen, die erst nach einem Ausfall erscheinen, es sei denn, der Anbieter kann zeigen, dass sie bereitgestellt, überwacht, autorisiert sind, die Präfixe anzukündigen und Spitzenverkehr zu tragen.

Der Routenursprungsschutz deckt nur eine von drei Ankündigungen ab

Die Routing-Konzentration ist nicht das einzige Control-Plane-Problem. Die Resource Public Key Infrastructure (RPKI) ermöglicht es einem Adressinhaber, eine Route Origin Authorization (ROA) zu veröffentlichen, die festlegt, welches AS ein Präfix ankündigen darf. Andere Netzwerke können eine Ankündigung mit dieser Autorisierung vergleichen und ungültige Ursprünge ablehnen oder herabstufen. RIPEstatsErklärung zur BGP-Ursprungsvalidierungbeschreibt dies als eine Möglichkeit für Betreiber, Richtlinien basierend auf der Gültigkeit des Routenursprungs festzulegen.

Für WebJanssen ist das derzeitige Ergebnis gemischt. RIPEstat meldet195.158.54.0/24 als gültigfür Ursprung AS29471. DieRPKI-Historie für AS29471zeigte Anfang Juli 2026 eine Autorisierung, die 256 Adressen abdeckt. Mit anderen Worten, der geschützte Raum ist das /24, etwa 11 % der 2.304 gerouteten IPv4-Adressen.

Die anderen beiden Routen warenunbekannt für 195.140.208.0/22undunbekannt für 195.225.208.0/22zur gleichen Prüfung. Unbekannt bedeutet nicht ungültig. Es bedeutet, dass keine übereinstimmende validierte Autorisierung diesen Ursprung und dieses Präfix abdeckte, sodass ursprungsvalidierende Netzwerke keine positive Autorisierung verwenden können, um die legitime AS29471-Ankündigung von einem nicht autorisierten Ursprung allein durch diese Kontrolle zu unterscheiden.

Auch das gültige /24 ist nicht ausfallsicher. Die Ursprungsvalidierung beweist nicht den gesamten AS-Pfad, stellt nicht sicher, dass Pakete den richtigen Server erreichen, verhindert nicht jeden Route-Leak oder erhält den Dienst während eines Upstream-Ausfalls. Sie reduziert eine Klasse von Routing-Fehlern oder -Angriffen. Ihr praktischer Wert hängt auch davon ab, ob andere Netzwerke die Validierung durchsetzen. Dennoch ist die Abdeckung eine messbare Hygiene-Kontrolle, und die Abdeckung von nur einer von drei Ankündigungen lässt eine klare Verbesserungsmöglichkeit erkennen.

Die Kombination aus einem einzigen beobachteten Upstream und teilweisem Ursprungsschutz verdient Aufmerksamkeit, da jedes Risiko ein anderes adressiert. Ein zweiter funktionierender Upstream kann die Erreichbarkeit erhalten, wenn ein Carrier ausfällt. Eine ROA kann anderen Netzwerken helfen, einen nicht autorisierten Ursprung abzuweisen. Keines ersetzt das andere. Das Hinzufügen einer ROA würde keinen zweiten physischen Pfad schaffen; der Kauf eines anderen Carriers würde nicht automatisch die neue Routing-Vereinbarung autorisieren oder vor einem falschen Ursprung schützen.

Ein Käufer muss keinen Zugang zu Router-Konfigurationen verlangen. Er kann eine aktuelle Liste der angekündigten Präfixe, den Autorisierungsstatus, die Upstream-AS-Nummern, das getestete Failover-Verhalten und das Datum der letzten Transitverlustübung anfordern. Die Antwort sollte Produktionspfade von alten Registrierungen trennen. Im Fall von WebJanssen stützen öffentliche Routing-Beobachtungen einen Produktionspfad und ein autorisiertes Präfix, sodass stärkere Behauptungen direkte Belege erfordern.

Die Kapazität der Einrichtung ist nicht die Kapazität von WebJanssen

Die Kapazitätsangaben von Aixit sind im Vergleich zu WebJanssens beworbenen Einzelhandelsgrenzen beeindruckend. Fast 1.000 Gbit/s Standortbandbreite und über 300 Peerings beschreiben einen großen Konnektivitätsmarktplatz. WebJanssens Root-Server-Produkte bewerben dagegen Flatrate-Traffic mit 10 Mbit/s für die Privat- und Business-Stufen und 100 Mbit/s für die Professional- und Managed-Stufen. PeeringDB beschreibt das Verkehrsaufkommen von AS29471 mit 20-100 Mbit/s, obwohl dieser selbstberichtete Bereich vor Jahren aktualisiert wurde.

Diese Zahlen befinden sich auf verschiedenen Ebenen. Die Einrichtungszahl ist die aggregierte installierte Kapazität über viele Kunden und Netzwerke. Die virtuelle Serverzahl ist ein Pro-Produkt-Limit. Der PeeringDB-Bereich ist eine alte kategoriale Schätzung des von AS29471 ausgetauschten Verkehrs. Keine zeigt die aktuelle Auslastung auf WebJanssens Upstream-Port, die von Aixit gekaufte garantierte Informationsrate (CIR), Burst-Kapazität, Paketverlust unter Last oder freie Reserve nach einem Ausfall.

Die nutzbare Kapazität während eines Vorfalls kann viel kleiner sein als die normal installierte Kapazität. Angenommen, ein Anbieter hat zwei 100-Mbit/s-Links und sendet normalerweise 60 Mbit/s über jeden. Der Verlust eines Links hinterlässt 100 Mbit/s für 120 Mbit/s Nachfrage, sodass eine Topologie, die redundant aussieht, dennoch überlastet. Im öffentlichen Fall von WebJanssen ist die Prämisse noch unsicherer, da ein zweiter aktueller Link nicht sichtbar ist. Der verbleibende Pfad muss den gesamten Verkehr absorbieren – vorausgesetzt, es existiert überhaupt noch ein Pfad.

Server-Limits führen einen weiteren Engpass ein. Ein Kunde, der einen virtuellen Server mit 10 Mbit/s kauft, kann von der Terabit-skaligen Aggregation des Rechenzentrums keine schnellere Wiederherstellung oder mehr Reserve ableiten. Speicher-I/O, Hypervisor-Scheduling, Backup-Verkehr, Firewall-Kapazität und DDoS-Filterung können jeweils zum bindenden Engpass werden, bevor der Upstream-Port voll ist. Die Produktseiten geben virtuelle CPU, Arbeitsspeicher, Festplatte und Verkehrsraten an, veröffentlichen aber keine Überbuchungsverhältnisse oder gemessene Leistung.

Der IPv4-Bestand ist ebenfalls keine Kapazitätsreserve. Adressen können zugewiesen werden, ohne Bandbreite zu verbrauchen, und erschöpfte Adressen können das Kundenwachstum einschränken, selbst wenn die Links idle sind. WebJanssen bewirbt eine feste Adresse bei Standard-Root-Servern und bis zu fünf bei einigen Managed-Produkten. Diese Nutzung ist konsistent mit Hosting-, Mail- und Nameservice-Workloads. Sie zeigt nicht, wie viel des 2.304-Adress-Fußabdrucks noch zuweisbar ist.

Für einen Geschäftskunden ist die nützliche kommerzielle Spezifikation daher dienstspezifisch: garantierter und Burst-Durchsatz, Überlastungspolitik, DDoS-Handhabung, Backup-Fenster-Effekte, Paketverlust- und Latenzziele sowie die nach dem größten Einzelfehler verfügbare Kapazität. Eine Einrichtungsbroschüre kann zeigen, dass Erweiterungsoptionen existieren. Sie kann nicht zeigen, dass sie für einen bestimmten Server gekauft wurden.

Stromausfallsicherheit endet am schwächsten Stecker

Das Frankfurter Gebäude ist die wichtigste gemeinsame physische Abhängigkeit. Aixit gibt an, dass AIX-FRA-1 moderne USV-, Notstrom-, Kühlungs- und Konnektivitätstechnologie mit redundantem Netzwerkdesign und mehreren Gebäudezugängen verwendet. Seine Haupt-Unternehmensseitesagt auch, dass seine Rechenzentren ISO 27001-zertifiziert sind und mit erneuerbarer Energie betrieben werden. Dies sind nützliche Host-Behauptungen, aber WebJanssen veröffentlicht nicht die Rack-Konfiguration, die sie in eine Ende-zu-Ende-Dienstgarantie verwandeln würde.

Stromausfallsicherheit ist eine Kette. Netzanschlüsse betreten das Gebäude, Schaltanlagen verteilen sie, USV-Anlagen überbrücken Unterbrechungen, Generatoren überbrücken längere Ausfälle, Rack-Stromversorgungen versorgen Geräte, und jeder Server oder Router wandelt diese Versorgung um. Redundanz an einem Punkt kann am nächsten zunichte gemacht werden. Ein dual-gespeistes Rack hilft nicht bei einem Gerät mit einem einzigen Netzteil, das an einer Steckerleiste angeschlossen ist. Zwei Netzteile, die an derselben Steckerleiste angeschlossen sind, schaffen keine Pfadunabhängigkeit.

Ein Generator garantiert keine Kontinuität ohne Treibstoff, Wartung, automatische Umschaltung und erfolgreiche Lasttests.

WebJanssens Produktseiten geben nicht an, ob Root-Server-Hostsysteme duale Netzteile haben, ob Border-Router gepaart sind oder ob Speicherrepliken in separaten Brand- und Stromzonen liegen. Xen-Virtualisierung kann Workloads unter bestimmten Designs verschieben oder neu starten, aber WebJanssens Behauptung, dass Xen die Server hoch ausfallsicher macht, offenbart kein Clustering, Live-Migration, Shared-Storage-Fehlerdomänen oder Reserve-Host-Kapazität. Virtualisierung ändert, wie ein Maschinenausfall behandelt wird; sie entfernt nicht den physischen Host darunter.

Kühlung ist ebenso folgenreich. Eine Datenhalle kann Netzkraft behalten, während die Temperaturen nach einem Ausfall der Kältemaschine oder der Luftbehandlung steigen. Die Notstromversorgung muss genügend Kühlung sowie IT-Last unterstützen, sonst schalten sich Server zum Selbsterhalt ab. Aixit gibt an, dass der Standort moderne Kühlung und redundantes Design verwendet, aber keine der Parteien veröffentlicht WebJanssen-spezifische Temperaturschwellen, Failover-Tests oder Abschaltverhalten.

Es gibt auch ein geografisches Problem. Die offizielle Geschäftsadresse ist jetzt in Spanien und das Rechenzentrum in Deutschland. Fernbetrieb ist beim Hosting normal, aber er teilt Autorität und physische Reichweite. Eine Person, die das Telefon beantwortet, kann möglicherweise einen ausgefallenen Server diagnostizieren, aber ohne Zugang zu Frankfurt kein Netzteil austauschen. Ein Einrichtungstechniker kann möglicherweise ein Kabel neu einstecken, hat aber möglicherweise keine Berechtigung oder Konfigurationskenntnisse, um einen Router zu ersetzen.

Die Wiederherstellungszeit ist die Summe aus Erkennung, Diagnose, Autorisierung, Anreise oder Entsendung, Zugang, Teilen, Reparatur und Validierung.

Die öffentlichen Belege stützen ein gutes Einrichtungspotenzial. Sie stützen keinen WebJanssen-spezifischen Anspruch auf gleichzeitige Wartbarkeit, Zwei-Standort-Kontinuität oder autonomen Betrieb durch ein langes regionales Stromereignis. Kunden, für die eine Stunde zählt, benötigen die Rack-Stromversorgung, Generator-Autonomie, Kühlungsredundanz, Eigentum an Ersatzhardware und die Bedingungen für Remote-Hands in ihren Vertrag geschrieben, nicht von der Adresse abgeleitet.

Der Servicepreis kauft eine bestimmte Geschwindigkeit der menschlichen Reaktion

Kleine Anbieter konkurrieren oft durch Vertrautheit. WebJanssens Startseite sagt, dass Support per E-Mail, Ticket oder Telefon verfügbar ist. Das Impressum veröffentlicht Geschäftszeiten von Montag bis Donnerstag und kürzere Zeiten am Freitag, mit einem kostenpflichtigen Notdienst außerhalb dieser Zeiten. Die Root-Server-Seite sagt, dass zu den kostenlosen Extras eine Antwort innerhalb eines Werktags gehört, während kostenpflichtige Service-Level eine Antwort innerhalb von vier Stunden bieten können.

Dies ist ungewöhnlich aufschlussreich, weil es die Arbeit zum Teil des Produkts macht. Ein virtueller Server für 19,99 € oder 49,99 € pro Monat beinhaltet nicht die gleiche Reaktionsverpflichtung wie eine konstruierte Hochverfügbarkeitsplattform. Optionales Backup und optionale schnellere Reaktion ermöglichen einen niedrigen Listenpreis, lassen aber auch mehr Wiederherstellungsrisiko beim Kunden. Der günstigste Server kann für eine Hobby-Seite völlig geeignet sein; er ist eine andere Sache für die Lohnabrechnung, Kunden-E-Mail oder ein Transaktionssystem.

Die Reaktionszeit ist nicht die Wiederherstellungszeit. Eine vierstündige Antwort kann bedeuten, dass ein Ingenieur das Ticket bestätigt, mit der Diagnose beginnt oder einen Plan kommuniziert. Es bedeutet nicht unbedingt, dass der Dienst innerhalb von vier Stunden funktioniert. Eine Antwort am Werktag kann sich je nach Zeitpunkt des Fehlers über ein Wochenende erstrecken. Die öffentlichen Seiten definieren keine Schweregrade, Startzeit der Uhr, Eskalation, Gutschrift, Teileersatz, Wiederherstellungsziel oder maximale Anzahl gleichzeitiger Vorfälle.

Die Formulierung "Handaufschlag" im Impressum ist ebenfalls bedeutsam. Sie deutet darauf hin, dass einige Eingriffe außerhalb der Geschäftszeiten berechenbare physische Arbeit sind und kein automatisch inbegriffener Rund-um-die-Uhr-Dienst. Die Seite identifiziert nicht, ob diese Hände zu WebJanssen-Mitarbeitern, Aixit-Mitarbeitern oder einem anderen Auftragnehmer gehören. Das können alles effektive Arrangements sein, aber sie haben unterschiedliche Warteschlangen und Autoritäten.

Ein Rechenzentrumstechniker kann während eines standortweiten Ereignisses viele Mieter bedienen; ein Eigentümer-Betreiber kennt das Netzwerk vielleicht genau, hat aber begrenzte parallele Kapazität.

Es wurden keine aktuellen öffentlichen Personalzahlen, Schichtpläne, Ersatzteilbestände oder Entsendungsaufzeichnungen gefunden. Es wäre falsch, aus diesem Schweigen auf schlechten Support zu schließen. Es wäre ebenso falsch, aus einer Telefonnummer auf ein besetztes 24-Stunden-Network-Operations-Center zu schließen. Die verfügbaren Belege stützen erreichbaren Support während der Geschäftszeiten, optionale schnellere Reaktion und kostenpflichtige Notfallintervention.

Diese Arbeitsgrenze ist der Punkt, an dem die grenzüberschreitende Struktur operativ wichtig wird. Die Diagnose kann von Spanien aus erfolgen, das Routing kann ferngesteuert geändert werden, und die Software kann über ein Control Panel neu gestartet werden. Ausgefallene Optiken, Laufwerke, Netzteile, Kabel und Hostsysteme erfordern immer noch jemanden in oder nahe Frankfurt. Die Ausfallsicherheit einer kostengünstigen Hosting-Rechnung hängt daher davon ab, ob geschulte Hände und kompatible Ersatzteile verfügbar sind, wenn mehrere Kunden sie gleichzeitig benötigen.

Fünf Ausfälle zeigen, was die Rechnung unausgesprochen lässt

Der erste Test ist der Verlust des Aixit-Transits. Aktuelle öffentliche Pfade zeigen AS29551 unmittelbar vor AS29471 für alle drei Präfixe. Wenn diese BGP-Sitzung, Übergabe oder der Anbieterpfad ausfällt und kein verstecktes Backup aktiv ist, können die Präfixe aus dem weiteren Internet verschwinden, selbst während jeder WebJanssen-Server noch mit Strom versorgt wird. Die Wiederherstellung würde die Wiederherstellung der Sitzung, die Verschiebung der Ankündigungen zu einem vorab autorisierten Alternativpfad oder die Reparatur der gemeinsamen Übergabe erfordern.

Eine alte KleyReX-Policy-Zeile ist kein ausreichender Beleg für ein solches Fallback.

Der zweite ist ein Einrichtungs- oder Stromereignis in der Rebstoeckerstrasse. Ein Gebäudevorfall kann Hostsysteme, Border-Geräte und den benachbarten Upstream gleichzeitig betreffen. USV und Generator können die Ausfallwahrscheinlichkeit reduzieren, aber die öffentlichen Belege zeigen keine separaten WebJanssen-Standorte oder eine Live-Kopie an einem anderen Ort. Kunden, deren Anwendungen nur auf einem virtuellen Server existieren, können gleichzeitig Rechenleistung und Konnektivität verlieren.

Der dritte ist ein Host-, Speicher- oder Hypervisor-Fehler. Xen kann virtuelle Maschinen isolieren und flexible Verwaltung ermöglichen, aber ein ausgefallener Host benötigt immer noch Reservekapazität für Neustart oder Migration. Gemeinsamer Speicher kann Daten bewahren, während er zu einem gemeinsamen Fehlerpunkt wird; lokaler Speicher kann Fehler isolieren, während er die Wiederherstellung erschwert. WebJanssen verkauft optionales Image-Backup, gibt aber keine Recovery-Point- oder Recovery-Time-Ziele an.

Ein Backup, das existiert, aber noch nie unter realistischen Bedingungen wiederhergestellt wurde, ist potenzielle Wiederherstellung, keine nachgewiesene Wiederherstellung.

Der vierte ist Überlastung oder Angriff. Ein 10- oder 100-Mbit/s-Produkt kann weit unterhalb der aggregierten Kapazität der Einrichtung überwältigt werden. Ein DDoS-Ereignis kann das Kundenlimit, WebJanssens Übergabe oder einen Upstream-Filter sättigen. Das öffentliche Angebot quantifiziert keine Abwehrkapazität oder Scrubbing-Arrangements. Kunden sollten ein Unlimited-Traffic-Abrechnungsetikett von unbegrenzter momentaner Bandbreite unterscheiden; ein Traffic-Flatrate entfernt einen Nutzungszähler, keine physikalische Ratengrenze.

Der fünfte ist Arbeitskräftemangel während eines breiten Vorfalls. Eine ausgefallene Festplatte an einem Werktag kann einfach sein. Ein Stromereignis, Kühlungsalarm oder Netzwerkfehler, der viele Mieter betrifft, kann gleichzeitige Tickets und physische Aufgaben erzeugen. Der erste verfügbare Techniker muss priorisieren, Zugang erhalten und Teile lokalisieren. Weder eine Hotline zu Geschäftszeiten noch ein Vier-Stunden-Antwortversprechen sagen, wie viele Vorfälle parallel bewältigt werden können.

Mehrere andere Ausfälle können oberhalb dieser Infrastruktur liegen. Ein Kunde kann DNS falsch konfigurieren, Anmeldeinformationen verlieren, ein Zertifikat ablaufen lassen oder Daten löschen. Ein lokaler Zugangscarrier kann ausfallen, während der gehostete Dienst gesund bleibt. Ziel ist es nicht, jedes Problem WebJanssen zuzuweisen; es geht darum, die Verantwortung zu trennen, sodass jeder Ausfall einen Eigentümer und einen getesteten Wiederherstellungspfad hat.

Was ein Belastbarkeitsanspruch zeigen müsste

Für Upstream-Diversität wäre der entscheidende Beleg ein zweiter aktueller Carrier oder eine Exchange-Verbindung, die Produktionsrouten trägt, in aktuellen Beobachtungen sichtbar oder in einem kontrollierten Failover demonstriert. Der zweite Pfad sollte auf gemeinsame Leitungen, Eingänge, Meet-Me-Räume, Stromversorgung und Upstream-Abhängigkeiten überprüft werden. Zwei BGP-Sitzungen über eine Cross-Connect schützen vor einigen Routerausfällen, aber nicht vor einem durchtrennten Kabel.

Für Routing-Sicherheit könnten die beiden unbekannten /22-Ankündigungen mit geeigneten Ursprungsautorisierungen abgedeckt werden, wenn die Adressinhaber und die betrieblichen Vereinbarungen dies zulassen. Aktuelle Route-Objects, Prefix-Filter und Kontakte sollten mit der Produktionstopologie übereinstimmen. Historische Policy-Aussagen sollten entfernt oder klar gekennzeichnet werden, damit Kunden und Peers sie nicht für Live-Kapazität halten.

Für Einrichtungskontinuität müsste WebJanssen identifizieren, ob kritische Geräte duale Stromversorgung haben, ob die Host-Kapazität einen Chassis-Ausfall überlebt, wo Backups residieren und wie lange Generator und Kühlung die relevante Last tragen können. Eine Zweitstandort-Kopie würde eine unabhängige Fehlerdomäne und eine getestete Aktivierungsmethode benötigen. Allein die Nennung eines anderen Gebäudes oder die Lagerung von Backup-Medien an einem anderen Ort würde keine Anwendungswiederherstellung begründen.

Für die Arbeit wären nützliche Belege Schweregraddefinitionen, Bestätigungs- und Wiederherstellungsziele, außerhalb der Geschäftszeiten geltende Autorität, Eigentum an Remote-Hands, Ersatzteilabdeckung und das Ergebnis kürzlicher Reparaturübungen. Der Käufer sollte wissen, ob die Vier-Stunden-Verpflichtung kontinuierlich oder nur in bestimmten Fenstern gilt und ob sie mit der ersten Antwort endet.

Für die geschäftliche Kontinuität sollte der nächste Vertrag WebJanssen U.Janssen, WebJanssen ISP UG und den mit AS29471 verbundenen Namen in Einklang bringen. Er sollte identifizieren, welche Partei Kundendaten, Domains, Adressen und Geräte kontrolliert und welche Partei verantwortlich bleibt, wenn sich ein Subunternehmer oder Einrichtungsbetreiber ändert. Die Frage ist nicht, ob ein historischer Name in einem Routing-Register verbleiben kann. Sie ist, ob der aktuelle Unterzeichner jede Abhängigkeit anordnen kann, die erforderlich ist, um den gekauften Dienst wiederherzustellen.

Keine dieser Anfragen erfordert, dass ein kleiner Betreiber sensible Diagramme veröffentlicht. Ein prägnanter Bestätigungsbrief, ein aktueller Serviceplan und ein bezeugtes Failover-Ergebnis können viel mehr begründen als ein Marketing-Adjektiv. Der Maßstab sollte mit der Ausfallfolge des Kunden skalieren: Eine Broschürenseite benötigt möglicherweise kaum mehr als ein wiederherstellbares Backup, während eine geschäftliche E-Mail-Plattform getestete Wiederherstellung, klare Eskalation und alternative Kommunikation benötigt.

Die Wirtschaftlichkeit belohnt Klarheit mehr als Größe

WebJanssens Preise machen sichtbar, warum spezialisiertes Hosting bestehen bleibt. Eine kleine Firma kann eine verwaltete Linux- oder Windows-Umgebung, Mailboxen, Domains und Telefonsupport kaufen, ohne einen eigenen Serverraum zu betreiben. Der Anbieter kann ein Frankfurter Rack, eine Upstream-Übergabe, Softwarelizenzen und Ingenieurwissen auf viele Kunden verteilen. Aixits größere Einrichtung verteilt Strom, Kühlung, Sicherheit und Carrier-Zugang auf viele Mieter. Jede Schicht wandelt klobige Infrastruktur in eine monatliche Rechnung um.

Dieselbe Schichtung kann Konzentration verschleiern. WebJanssen mag Server, Konnektivität, E-Mail und Backup als verschiedene Produkte anbieten, aber sie können dasselbe Gebäude, denselben Upstream und dieselben Techniker teilen. Ein Kunde kann mehrere Dienste kaufen und glauben, Diversität zu haben, wenn alle gleichzeitig ausfallen. Niedriger Preis ist nicht das Problem; ungeprüfte gemeinsame Abhängigkeiten sind es.

Optionales Backup und schnellere Reaktion sind wirtschaftlich rational. Nicht jede Arbeitslast verdient synchrone Replikation oder sofortiges Eingreifen, und die Belastung jedes Kunden mit dem höchsten Niveau würde grundlegendes Hosting unwirtschaftlich machen. Der wichtige Punkt ist, dass der Kunde bewusst kauft. Ein optionales Image-Backup sollte Häufigkeit, Aufbewahrung, Speicherort und Wiederherstellungsverantwortung angeben. Eine kostenpflichtige Antwort sollte angeben, welche Aktion erfolgt und was passiert, wenn Hardware nicht verfügbar ist.

Peering könnte auch die Wirtschaftlichkeit kleiner Netzwerke verbessern, indem es etwas Verkehr von kostenpflichtigem Transit fernhält, Pfade verkürzt und die Upstream-Abhängigkeit reduziert. WebJanssens ältere RIPE-Policy verweist auf KleyReX, dessen kostenloses grundlegendes Peering-Angebot genau für diese Art von Betreiber konzipiert ist. Doch aktuelle Beobachtungen zeigen keine aktive Exchange-Verbindung. Die wirtschaftliche Chance ist nicht dasselbe wie eine installierte Sicherung.

Die Einrichtung bietet einen weiteren Expansionspfad. Aixit gibt an, Cross-Connects zu großen Carriern und Exchanges bereitstellen zu können, sodass WebJanssen sich an einem Ort befindet, an dem zusätzliche Diversität erhältlich sein kann. Ob der Kauf gerechtfertigt ist, hängt vom gefährdeten Kundenumsatz, den Kosten eines zweiten Ports und der Fähigkeit des Betreibers ab, die zusätzliche Komplexität zu unterstützen. Ein zweiter Pfad, der nie überwacht oder geübt wird, kann falsches Vertrauen und Routing-Fehler erzeugen.

Für Kunden ist der faire Vergleich die Gesamtkontinuitätskosten und nicht der Server-Posten. Dazu gehören Zugang zu Frankfurt, Anwendungs-Backup, alternative E-Mail- oder Statuskommunikation, Wiederherstellungsarbeit und die Umsatzauswirkung von Ausfallzeiten. WebJanssen kann wettbewerbsfähig bleiben, ohne einen Hyperscaler nachzuahmen, aber sein stärkstes Angebot wäre Präzision: Was ist inbegriffen, was wird geteilt, was ist optional und wie wird mit Ausfällen umgegangen.

Ein lebendiges spezialisiertes Netzwerk mit schwacher Belastbarkeitsoffenlegung

Die Betriebsstatusfrage kann zuverlässiger beantwortet werden als die Belastbarkeitsfrage. AS29471 ist aktiv, seine drei IPv4-Routen waren global sichtbar, webjanssen.de wird in eine davon aufgelöst, die Verkaufs- und Supportseiten bleiben verfügbar, und der Betreiber nennt eine aktuelle Frankfurter Rechenzentrumsadresse. Die Hauptsitzankündigung vom Oktober 2025 ist aktuell. Diese Fakten stützen ein fortlaufendes Geschäft, kein aufgegebenes Netzwerk.

Sie stützen nicht das Bild, das eine breite regionale ISP-Kategorie impliziert. Es gibt keine öffentlichen Belege für eigene Glasfaser der letzten Meile, Funkmasten, Kundenabgänge, lokale Zugangslizenzen oder Feldtechniker, die ein Zugangsgebiet bedienen. Die Belege stützen einen Hosting- und Kommunikationsspezialisten, dessen öffentliches Netzwerk auf Frankfurt zentriert ist und dessen Geschäftsadresse jetzt in Spanien liegt. "Global" beschreibt die Internetreichweite und PeeringDBs altes Scope-Feld besser als ein dokumentiertes physisches Servicegebiet.

Die Belastbarkeitsbelege sind schwach, weil die verbleibenden Unbekannten auf dem kritischen Pfad liegen. Ein beobachteter Upstream trägt alle drei Präfixe. Keine IPv6-Route ist sichtbar. Nur ein Präfix hat eine positive Routenursprungsautorisierung. Peering- und Einrichtungsdaten sind alt oder selbstberichtet. Die Host-Einrichtung bewirbt starke allgemeine Fähigkeiten, aber keine WebJanssen-spezifische Strom-, Routen- oder Zweitstandort-Auslegung wird veröffentlicht. Die menschliche Reaktion wird in Stunden beschrieben, aber Wiederherstellung, Schichttiefe und Teile sind nicht angegeben.

Schwache Belege sind keine Vorhersage eines Ausfalls. Sie sind eine Grenze dessen, was verantwortungsvoll behauptet werden kann. Ein kleiner, erfahrener Betreiber in einer leistungsfähigen Frankfurter Einrichtung kann jahrelang zuverlässigen Dienst liefern. Der öffentliche Rekord begründet einfach keine Unabhängigkeit von Aixit, Wiederherstellung nach einem großen gemeinsamen Ereignis oder sofortige physische Reaktion außerhalb der Normalgeschäftszeiten.

Diese Unterscheidung sollte den Kauf prägen. Eine Website mit geringen Auswirkungen kann die Konzentration akzeptieren und ein portables Backup unterhalten. Ein geschäftskritischer Kunde sollte die aktuelle rechtliche Vertragspartei, das Routendesign, die Stromversorgungsanordnung, die Backup-Wiederherstellungsbedingungen und die Technikerverpflichtung einholen, bevor er sich auf die Verbindung verlässt. Die monatliche Rechnung ist lokal und einfach; die Kontinuität hängt von einer Kette ab, die einen spanischen Hauptsitz, ein Frankfurter Rack, einen sichtbaren Upstream und die Hände umfasst, die verfügbar sind, wenn etwas Physisches bricht.