WAN & Internet
Eigene IPv4-/IPv6-Prefixe und mehrere Provider, stabil betrieben.
Wir planen und betreiben BGP-Edges für Unternehmen, die eigene IPv4-/IPv6-Prefixe, redundante Rechenzentren, Anycast oder mehrere Upstreams brauchen: von ASN- und Prefix-Prüfung über RPKI/IRR und Filter bis Monitoring, Providerkoordination und Betrieb.
IPv4-/IPv6-Adressraum unter Kontrolle
- Providerwechsel ohne Renumbering-Projekt
- Whitelists, DNS und Schnittstellen bleiben stabil
Mehrere Upstreams steuerbar
- Failover und Präferenz pro Carrier definieren
- Traffic Engineering über Policies und Communities
Know-how im Betrieb
- Design, Umsetzung und Betrieb durch erfahrene IT-Architekten
- RPKI, IRR, IPv4-/IPv6-Prefix-Filter und Monitoring nicht nur geplant, sondern gepflegt
Selbst-Check
Wann lohnt sich eigenes Internet-Routing?
Mehrere Provider, aber keine echte Ausfallsicherheit? Diese Anzeichen sprechen für eigenes Routing.
- Ihre öffentlichen IP-Adressen sind bei Partnern, Banken, Plattformen oder Behörden fest freigeschaltet.
- Ein Carrierwechsel würde heute DNS, Firewall-Regeln, VPNs, Schnittstellen oder Kundenfreigaben anfassen.
- Dienste im Rechenzentrum, in einer Colocation oder am Hauptstandort müssen über mehrere Provider erreichbar sein.
- Redundante Rechenzentren oder Standorte sollen Dienste aktiv/aktiv oder mit schnellem Failover bereitstellen.
- Sie wollen eigene IPv4-/IPv6-Prefixe über zwei oder mehr Transit-Provider kontrolliert ankündigen.
- Routing-Sicherheit, RPKI, IRR-Objekte, Prefix-Filter und Change-Dokumentation sollen nachvollziehbar betrieben werden.
- Webserver, Kubernetes, DNS, APIs oder andere Dienste sollen über Anycast-BGP hochverfügbar erreichbar sein.
- Ihnen fehlt intern das Spezialwissen, um BGP, Anycast und Routing-Sicherheit dauerhaft selbst zu betreiben.
Lösungsansätze
Drei Bausteine für eine eigene BGP-Edge.
Eine BGP-Anbindung ist kein Produkt von der Stange. Sie entsteht aus Ressourcen, Providerfähigkeit, Routing-Policy und einem belastbaren Betriebsmodell.
AS-Nummer und IPv4-/IPv6-Adressraum
Klärung von ASN, PI-/PA-Adressraum, IPv4- und IPv6-Verfügbarkeit, LIR-/Sponsoring-Modell und Provider-Voraussetzungen.
Multi-Provider-BGP
eBGP-Sessions zu mehreren Upstreams, definierte Import-/Export-Policies, Communities, Local Preference, Prepending und kontrolliertes Failover.
Anycast, Peering und Dienste
Anycast-BGP, IXP-Peering oder private Übergaben für verteilte Dienste wie DNS, Web, APIs, Kubernetes-Ingress oder andere hochverfügbare Plattformen.
Abgrenzung
Wann BGP, wann IP Access Flex, wann klassische Redundanz?
Die Themen liegen nah beieinander, lösen aber unterschiedliche Probleme. Entscheidend ist, ob Sie globalen IPv4-/IPv6-Adressraum selbst ankündigen wollen oder nur einen Standort stabil erreichbar machen.
Eigene Routing-Domäne
BGP & Multi-Provider
Für Kunden mit eigener AS-Nummer, eigenen oder portierbaren IPv4-/IPv6-Prefixen, mehreren Upstreams, RPKI/IRR und selbst kontrollierten Routing-Policies.
Pragmatischer Standortzugang
IP Access Flex
Für feste öffentliche IPs, geroutete Netze oder optional BGP/IP-Transit am Standort, ohne eine vollständige Dual-Carrier-BGP-Edge selbst betreiben zu müssen.
Klassische Ausfallsicherheit
Redundante Anbindung
Für Dual-WAN, LTE/5G-Backup, Router-Redundanz oder Provider-Failover, wenn keine eigenen globalen IPv4-/IPv6-Prefixe angekündigt werden sollen.
Betriebsmodell
BGP ist Spezialwissen. Wir machen daraus Betrieb.
Kundenumgebung betreiben
Wir bauen die BGP-Edge im Rechenzentrum, in der Colocation oder am Kundenstandort auf und übernehmen Betrieb, Monitoring, Changes und Providerkoordination.
LINOXA-Rechenzentrum nutzen
Wir können Dienste für Kunden in unserem Rechenzentrum bereitstellen und über BGP oder Anycast erreichbar machen, etwa Webserver, Kubernetes-Workloads, APIs oder Plattformdienste.
Architektur und Betrieb verbinden
Wir übersetzen Routing, Provider, Dienste und Betrieb in eine Lösung, die Admins verstehen und Entscheider verantworten können.
Vorgehen
So wird aus BGP ein betreibbares System.
Ziel & Verantwortung
Klären, welche Dienste erreichbar bleiben müssen, welche IPv4-/IPv6-Prefixe betroffen sind und wer Routing-Verantwortung übernimmt.
Ressourcen & Provider
ASN, IPv4-/IPv6-Prefixe, LIR-/RIPE-Situation, Sponsoring, LOA, Transit und Cross-Connects prüfen.
Policy-Design
Import, Export, Communities, Local Preference, AS-Path-Prepending, RPKI/ROA, IRR und Prefix-Filter festlegen.
Staging & Migration
BGP-Sessions, Filter, BFD, Max-Prefix-Limits und Failover kontrolliert testen, bevor IPv4-/IPv6-Prefixe produktiv umziehen.
Betrieb & Nachweis
Monitoring, Looking-Glass-Prüfungen, Route-Collector-Sicht, Change-Doku und Runbooks für Störungen etablieren.
Ziel & Verantwortung
Klären, welche Dienste erreichbar bleiben müssen, welche IPv4-/IPv6-Prefixe betroffen sind und wer Routing-Verantwortung übernimmt.
Ressourcen & Provider
ASN, IPv4-/IPv6-Prefixe, LIR-/RIPE-Situation, Sponsoring, LOA, Transit und Cross-Connects prüfen.
Policy-Design
Import, Export, Communities, Local Preference, AS-Path-Prepending, RPKI/ROA, IRR und Prefix-Filter festlegen.
Staging & Migration
BGP-Sessions, Filter, BFD, Max-Prefix-Limits und Failover kontrolliert testen, bevor IPv4-/IPv6-Prefixe produktiv umziehen.
Betrieb & Nachweis
Monitoring, Looking-Glass-Prüfungen, Route-Collector-Sicht, Change-Doku und Runbooks für Störungen etablieren.
Technische Bausteine
Womit wir arbeiten.
Eine Auswahl der Bausteine, die wir zum Beispiel einsetzen.
BGP & Policy
Routing-Sicherheit
Edge-Plattformen
Anbindung
Adressierung
Anycast & Dienste
Betrieb
Betriebsmodell
Übergabe
Was vor dem ersten IPv4-/IPv6-Prefix sauber stehen muss.
BGP-Fehler sind selten lokal. Deshalb gehören Filter, Nachweise, Rollback, Monitoring und ein Change-Prozess zum Design, nicht erst zum späteren Betrieb.
- Ressourcenprüfung: AS-Nummer, IPv4-/IPv6-Prefixe, LIR-/Sponsoring-Situation, LOA und Provider-Anforderungen
- BGP-Design mit Upstreams, Import-/Export-Policy, Communities, Local Preference und Rückweg-Steuerung
- RPKI/ROA, IRR-Objekte, Prefix-Listen, Bogon-Filter, Max-Prefix-Limits und dokumentierte Freigaben
- Edge-Konfiguration für Router oder Linux-BGP-Stack inklusive Fallback- und Rollback-Plan
- Anycast-Design für verteilte Dienste inklusive Health-Checks, Standortlogik und Rückfallverhalten
- Monitoring von Sessions, IPv4-/IPv6-Prefix-Sichtbarkeit, RPKI-Status, Routenänderungen und Upstream-Verhalten
- Betriebsdokumentation für Providerwechsel, Wartungsfenster, Störungen und geplante Routing-Changes
Aus der Praxis
Wo BGP & Multi-Provider sinnvoll tragen.
Eigenes Rechenzentrum
Dienste, Plattformen oder Kundenumgebungen bleiben über mehrere Carrier erreichbar.
Redundante Rechenzentren
Zwei oder mehr Standorte veröffentlichen IPv4-/IPv6-Prefixe kontrolliert, damit Dienste bei Standort- oder Providerproblemen erreichbar bleiben.
B2B-Schnittstellen
Stabile Quell- und Ziel-IPs für Partner, Banken, Behörden oder Industrieplattformen.
Colocation & Hosting
Eigener IPv4-/IPv6-Adressraum am Rack, über Transit, Cross-Connect oder Peering angebunden.
Anycast-Dienste
DNS, Web-Frontends, APIs oder Kubernetes-Ingress werden an mehreren Standorten unter derselben IP angeboten.
LINOXA-gehostete Dienste
Wir stellen Kundenplattformen in unserem Rechenzentrum bereit und machen sie per BGP oder Anycast hochverfügbar erreichbar.
Providerwechsel
Neue Carrier können vorbereitet werden, ohne alle Systeme und Whitelists neu zu adressieren.
Wachsende IT-Organisation
Wenn aus Standort-IT eine eigene Routing- und Betriebsverantwortung entsteht.
Fehlendes Spezialwissen
Wenn BGP benötigt wird, aber intern kein Team für RPKI, Filter, Providerkommunikation und 24/7-Betrieb aufgebaut werden soll.
Sie haben Fragen?
FAQ
Antworten auf typische Fragen zu eigenen IPv4-/IPv6-Prefixen, mehreren Upstreams, Anycast, Providerwechsel und dem laufenden Betrieb einer BGP-Edge.
BGP-Projekt besprechenJa, wenn Sie echtes Multi-Provider-BGP mit eigenen oder portierbaren IPv4-/IPv6-Prefixen betreiben wollen. Die eigene AS-Nummer ist dann die Routing-Identität, über die diese Prefixe bei Transit-Providern, Peering-Partnern oder Anycast-Standorten angekündigt werden. Nicht nötig ist sie nur bei einfacheren Varianten wie IP Access Flex, statischer Übergabe oder einem einzelnen Provideranschluss.
Nicht zwingend. Je nach Ausgangslage kann eine direkte RIPE-NCC-Mitgliedschaft sinnvoll sein, oft reicht aber auch ein Sponsoring- oder LIR-Modell über einen Provider oder Partner. Wichtig ist, dass ASN, IPv4-/IPv6-Prefixe, Pflegeverantwortung und Abhängigkeiten sauber geklärt sind.
Manchmal, aber es ist keine saubere Standardannahme. Provider-zugewiesene IPv4-/IPv6-Adressen sind häufig an diesen Provider gebunden. Für echtes providerunabhängiges Multihoming sind PI-Adressraum, eigene IPv4-/IPv6-Prefixe oder eine ausdrücklich erlaubte Ankündigung per LOA die belastbarere Grundlage.
Oft ja. Wenn Sie feste öffentliche IPs, ein geroutetes IPv4-/IPv6-Netz oder optional IP-Transit an einem Standort brauchen, ohne selbst eine vollständige BGP-Edge zu betreiben, ist IP Access Flex meist pragmatischer. Klassisches BGP lohnt sich, wenn Sie eigene IPv4-/IPv6-Prefixe, mehrere Upstreams und Routing-Policies selbst verantworten wollen.
Kosten entstehen typischerweise durch Transit, Cross-Connects, Router, Betrieb, Monitoring und je nach Modell durch RIPE-/LIR-/Sponsoring-Themen oder IPv4-Transfer beziehungsweise Leasing. Wir trennen einmalige Projektkosten, laufende Providerkosten und Betriebsaufwand transparent.
RPKI hinterlegt per ROA, welche AS-Nummer einen Prefix originieren darf. Andere Netze können dadurch ungültige Origin-Ankündigungen erkennen und filtern. RPKI verhindert nicht jede falsche Route, gehört aber heute als Basisschutz zu einem sauberen BGP-Betrieb.
Nein. Häufig spricht nur die zentrale Edge, ein Rechenzentrum oder die Colocation BGP nach außen. Außenstandorte können über Standortvernetzung, IP Access Flex, statisches Routing oder ein internes IGP angebunden werden.
Nur begrenzt. Ausgehende Pfade lassen sich über Local Preference gut steuern. Eingehende Pfade hängen von den Entscheidungen anderer Netze ab und werden typischerweise über Communities, Prepending, spezifischere Prefixe oder Peering beeinflusst, nicht millimetergenau garantiert.
Das hängt vom Betriebsmodell ab. Wir können Planung und Umsetzung liefern, den Betrieb gemeinsam mit Ihrem Team übernehmen oder die BGP-, Multi-Provider- und Anycast-Umgebung vollständig betreuen. Dazu gehören Providerkoordination, Monitoring, Changes, RPKI/IRR-Pflege und Störungsanalyse.
Ja, wenn Architektur und Anwendung dafür geeignet sind. Wir können Dienste wie Webserver, Kubernetes-Frontends, APIs oder andere Plattformdienste in unserem Rechenzentrum bereitstellen und über BGP beziehungsweise Anycast so anbinden, dass Erreichbarkeit und Standortredundanz sauber überwacht werden.
Der nächste Schritt
Wir unterstützen Ihre BGP-Anbindung von der Planung bis zum Betrieb.
Ob eigene IPv4-/IPv6-Prefixe, redundante Rechenzentren, Anycast-Dienste oder mehrere Upstreams: Wir prüfen die Ausgangslage, entwerfen die Architektur und übernehmen auf Wunsch Umsetzung, Providerkoordination, Monitoring und laufenden Betrieb.