Offene IP-Core- und Peering-Router
Der offene IP-Core- und Peering-Router trägt die vollständige Internet-BGP-Tabelle für Transit und Peering und betreibt den SR-MPLS- oder SRv6-Core zwischen den Standorten. IP Infusion liefert ihn komplett: validierte offene Hardware, OcNOS-SP vorinstalliert, unterstützt unter einem Vertrag.
Betreiber, die offene Core- und Peering-Router betreiben.
Netzbetreiber setzen heute offene Core- und Peering-Router mit OcNOS produktiv ein. Vier davon sind unten genannt, jeweils mit einer veröffentlichten Fallstudie oder Ankündigung.
"Aus technischer Sicht erfüllte OcNOS jede Anforderung: volle BGP-Tabelle in Hardware, Dual-Stack vom ersten Tag an und ein Funktionsumfang, der mit den traditionellen Anbietern mithält." Markus Wellauer, Co-CEO, NWP Services GmbH (NWPS)
Der Core- und Peering-Router in vier Rollen.
Derselbe OcNOS-SP Router deckt jede Core-Rolle ab, sodass der Betreiber ein Image und einen Supportvertrag betreibt, anstatt eine andere Box für den Edge, den Core, das Peering und die Route-Reflection zu kaufen.
Dasselbe Router-Image betreibt alle vier Rollen, lizenziert und dimensioniert je Rolle.
Core-Router
Sie tragen jeden Dienst zwischen den Standorten auf einem Underlay mit der höchsten Kapazität, die das Portfolio bietet: dem UfiSpace S9610-36D mit 14.4 Tbps, wobei ein einziger SR-MPLS- oder SRv6-Core das Forwarding übernimmt.
Eine redundante Dual-Plane hält den Core beim Verkehrstransport, während eine Verbindung oder ein Knoten wiederhergestellt wird, sodass ein Ausfall in der Mitte des Netzes nie zu einem Betriebsausfall wird.
P-Router
Im Core vermittelt der P-Router gelabelten Verkehr und hält keine Kundenrouten, sodass er sein gesamtes Budget für Kapazität und Fast Reroute statt für Routenzustand einsetzt. OcNOS-SP betreibt ihn mit Flex-Algo, TI-LFA und BFD.
Da die Schicht rein label-basiert bleibt, skalieren Sie den Core allein über die Weiterleitungskapazität.
PE-Router
Der PE-Router ist der Punkt, an dem Kundenstandorte dem Core beitreten: Er legt das Transport-Label auf und hält den L3VPN- und EVPN-Service-State, sodass er die VPN-Skalierung trägt, die die P-Ebene nie berührt.
Von dort übergibt es den Service-Edge an die Metro-Aggregation, sodass der Core sauber bleibt und der Service-Status am Edge lebt, wo er hingehört.
Peering-Router
Der Peering-Router ist Ihr Tor zu Transit-Providern und Internet-Exchanges und trägt die vollständige Internet-BGP-Tabelle für beide. OcNOS-SP validiert jede Route mit RPKI und wendet Ihre Route-Policy direkt an der Edge an.
Route Reflectors halten die iBGP-Control-Plane dahinter skalierbar, während die Zahl der Peers wächst.
Die vollständige Internet-BGP-Tabelle in Hardware vorhalten.
Der Peering-Router trägt die vollständige Internet-BGP-Tabelle für Transit und Settlement-free Peering, IPv4 und IPv6 Dual-Stack, in Hardware auf Merchant-Silicon gehalten. Für die größten Tabellen nutzt das Design eine Plattform mit großem externem TCAM.
Die vollständige Tabelle, Dual-Stack, in Hardware
Der Peering-Router trägt eine vollständige Internet-BGP-Tabelle für Transit und Settlement-free Peering, IPv4 und IPv6 vom ersten Tag an, auf einer Plattform mit großem externem TCAM. Graceful Restart und TI-LFA halten das Forwarding stabil, während die Control Plane neu konvergiert.
Route Reflectors tragen die iBGP-Tabelle zwischen Core-Routern, sodass Clients ein Full Mesh vermeiden, was die Control Plane skalierbar hält, während das Netz wächst.
Ein großer externer TCAM für die größten Tabellen
Wenn ein Router die vollständige globale Tabelle in einem großen Hardware-Forwarding-Pfad halten muss, verwendet das Design eine Plattform mit externem TCAM. NWP Services betreibt genau das: einen UfiSpace S9600-72XC mit externem OP2-TCAM, Dual-Stack, wobei OcNOS-SP RPKI und Route-Policy übernimmt.
IP Infusion validiert, installiert vor und unterstützt diesen Router, sodass der Full-Table-Forwarding-Pfad als ein unterstütztes System ausgeliefert wird.
Route-Sicherheit und Traffic-Steuerung am Internet-Edge.
Der Peering-Router validiert die Routen, die er annimmt, filtert das, was er ankündigt, und schiebt bei einem Angriff die Mitigation an den Edge. RPKI, BGP FlowSpec, Remote-Triggered Black-Holing und BGP Communities geben dem Internet-Edge seine Routen-Sicherheitskontrollen.
RPKI-Ablehnung ungültiger Routen
Der Router führt RPKI Route-Origin-Validierung und verwirft ungültige Routen an der Edge, mit Präfixfilterung gemäß MANRS-Praktiken, sodass gekaperte und geleakte Präfixe verworfen werden, bevor sie in die Tabelle gelangen.
BGP FlowSpec für DDoS-Abwehr
BGP FlowSpec verteilt Match-and-Action-Filter über die Edge, sodass ein volumetrischer Angriff im Forwarding-Pfad als Routing-Workflow verworfen oder ratenbegrenzt wird, ohne jeden Router einzeln anzufassen. Der Workflow für Erkennung und Mitigation wird auf der Seite DDoS-Schutz beschrieben.
Remote-Triggered Black-Holing
Der Router leitet ein angegriffenes Ziel per Black-Hole um mithilfe der RFC 7999 Blackhole-Community, sodass eine einzige Routenankündigung Angriffstraffic über die gesamte Peering-Edge zu einem Discard-Next-Hop lenkt.
BGP-Communities für Peering-Policy
BGP Communities, einschließlich Large Communities gemäß RFC 8092, markieren und klassifizieren Routen, sodass Peering-, Transit- und Kunden-Policies konsistent an der Edge und innerhalb des AS angewendet werden.
BGP-LS-Topologie und Egress-Engineering
BGP-LS exportiert die Link-State-Topologie an ein PCE oder einen Controller, und SR BGP Egress Peer Engineering lenkt Traffic zu einem gewählten Peer, sodass die Egress-Auswahl zu einer steuerbaren Entscheidung wird.
Route Reflection und Konföderationen
Route Reflectors gemäß RFC 4456 oder BGP-Konföderationen gemäß RFC 5065 skalieren die iBGP-Control-Plane, sodass Peering- und Core-Router die Tabelle ohne vollständiges iBGP-Mesh teilen.
Die BGP-Funktionsdetails ansehen auf der BGP-Technologieseite →
Ein Dual-Plane-SR-MPLS-Core, mit SRv6 parallel dazu.
Der Core-Router betreibt IS-IS mit Segment-Routing-Erweiterungen als sein Standard-IGP, sodass ein Label-Switched-Path jeden Dienst trägt. Flexible Algorithm baut eine Low-Latency-Ebene neben der Standardebene auf derselben Topologie auf, und TI-LFA liefert Fast Reroute unter 50ms.
IS-IS mit SR, geplantes SRGB
IS-IS SR ist das Standard-IGP, und jeder Knoten teilt einen SRGB damit eine Prefix-SID überall auf dasselbe Label abgebildet wird. Der Standardbereich des SRGB ist 16000 bis 23999.
Flex-Algo Low-Latency-Ebene
Flexible Algorithm gemäß RFC 9350 baut eine zweite Forwarding-Ebene auf, auf niedrige Latenz abgestimmt, neben der standardmäßigen Shortest-Path-Ebene auf derselben physischen Topologie, ohne Overlay.
TI-LFA unter 50 ms
TI-LFA berechnet für jedes Ziel einen schleifenfreien Backup-Pfad im Voraus, sodass der Core bei einem Link- oder Knotenausfall in unter 50 ms umleitet, während IS-IS neu konvergiert.
SR-TE mit einem PCE
SR-TE Policies lenken Traffic auf expliziten Pfaden, berechnet von einem Stateful PCE über PCEP, einschließlich Egress-Steering an der Peering-Edge für einen gewählten Ausgang.
SRGB-Planung, gemäß dem OcNOS-SP Segment-Routing Configuration Guide: ein Prefix-SID-Index von 1000 auf einem Loopback entspricht Label 17000 bei einer SRGB-Basis von 16000. Ein identischer SRGB auf jedem Knoten sorgt für dasselbe Label für ein Präfix auf jedem Knoten, was den Betrieb vereinfacht.
Welcher validierte Router für welche Rolle.
IP Infusion liefert den Core- und Peering-Router auf 40+ qualifizierte Plattformen von Edgecore und UfiSpace, jeweils pro ASIC-Stepping im Labor qualifiziert, mit vorinstalliertem OcNOS-SP. Der Core wird nach Forwarding-Kapazität und Pufferung dimensioniert, die Full-Table-Edge nach dem Forwarding-Pfad, der die Tabelle hält.
| Rolle | Validierte Router | Warum er zur Rolle passt |
|---|---|---|
| Core / P-Router |
|
Kernklassen-Kapazität ab 7,2 Tbps, mit 400G-Ports zum Abschluss der PE-Uplinks und Deep Buffer. Die P-Schicht hält keine Kundenrouten und wird daher nach Forwarding-Kapazität dimensioniert. |
| Full-Table-Peering-Edge |
|
Ein Forwarding-Pfad mit externem TCAM hält die vollständige Internet-BGP-Tabelle in Hardware, mit Deep Buffer für Microbursts am Internet-Edge. NWP Services betreibt den S9600-72XC in dieser Rolle. |
| Service-Edge (PE) |
|
400G-Uplinks in den Kern auf der Service-Edge-Stufe von 2,4 bis 4,8 Tbps. Setzt das Transport-Label und hält den L3VPN- und EVPN-Zustand, mit SRv6-Unterstützung neben SR-MPLS auf dieser Silizium-Stufe. |
| Kompakter Service-Edge |
|
400G-Uplinks bei 2,4 Tbps und darunter, für kleinere PE-Standorte, die SR-MPLS-Transport sowie L3VPN- und EVPN-Services benötigen, auf der SRv6-fähigen Silizium-Stufe. |
| Aggregationsebene unterhalb des Core |
|
Speist den Core mit einem 400G-Uplink. Das Aggregationsdesign wird verantwortet auf der Metro-Ethernet beschrieben. |
Der Full-Table-External-TCAM-Router wird als die von NWP Services eingesetzte Plattform genannt. Jede validierte Plattform ansehen in der Hardware-Kompatibilitätsliste, und ordnen Sie Features der Hardware zu in der Feature-Matrix.
Wie Sie den Core- und Peering-Router dimensionieren
- Vollständige Tabelle jetzt oder Reserve. Dimensionieren Sie den Peering-Edge auf einem Router, der die vollständige Internet-BGP-Tabelle heute in Hardware hält, oder auf einem großen External-TCAM-Pfad, wenn Sie Spielraum zum Wachstum der Tabelle benötigen.
- Core-Kapazität und Buffering. Dimensionieren Sie den Core nach Forwarding-Kapazität und Deep-Buffering für Internet-Edge-Microbursts, nicht nach Route-State, da die P-Ebene keine Kundenrouten hält.
- Single-Box oder geclusterter Core. Gestalten Sie den Core als redundantes Paar, damit TI-LFA einen Backup-Pfad hat. Die redundante Ebene führt den Datenverkehr durch einen Ausfall hindurch.
- SR-MPLS oder SRv6. Betreiben Sie SR-MPLS als Standard-Core und SRv6 daneben, wo Ihre Transportstrategie es erfordert, Verfügbarkeit je Plattform und Release.
- Route Reflection. Platzieren Sie Route Reflectors, um iBGP zu skalieren: inline auf Core-Routern für ein kleineres Netzwerk oder dedizierte Reflectors, wenn die Zahl der Peers wächst.
- Direktes Peering oder Route-Server. Peeren Sie direkt mit verkehrsstarken Netzen für die Kontrolle und nutzen Sie einen IXP-Route-Server für den Long Tail der Settlement-Free-Peers.
- Edgecore oder UfiSpace. Jede Rolle ist auf Hardware von Edgecore und UfiSpace mit demselben OcNOS-SP Image validiert, sodass Sie sich auf einen Anbieter standardisieren oder beide kombinieren können, ohne die Software zu ändern.
- Ein Vertrag. IP Infusion validiert und unterstützt jede Rolle als einen Router, und Hardware und Software werden in unabhängigen Zyklen erneuert.
Einen Route-Reflector-Cluster konfigurieren.
Sie skalieren iBGP ohne Full-Mesh, indem Sie Clients auf die Reflektoren verweisen und die Reflektoren Routen untereinander weitergeben lassen. Die untenstehende OcNOS-SP Konfiguration tut genau das: drei iBGP-Nachbarn, zwei davon als Route-Reflector-Clients in der IPv4-Unicast-Adressfamilie festgelegt.
! Reflector: reflect routes between iBGP clients
configure terminal
Router bgp 200
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 200
neighbor 6.6.6.6 remote-as 200
address-family ipv4 unicast
neighbor 3.3.3.3 route-reflector-client
neighbor 2.2.2.2 route-reflector-clientWas jede Zeile bewirkt
router bgp 200wechselt in BGP für das autonome System, das Core- und Peering-Router gemeinsam nutzen.- Die drei
neighbor ... remote-as 200Zeilen bilden die iBGP-Sessions. 6.6.6.6 ist ein einfacher iBGP-Peer und erhält daher nicht dieroute-reflector-clientZeile unten. route-reflector-clientbestimmt jeden Client pro Adressfamilie, hier IPv4 Unicast, und dasselbe Muster gilt für VPNv4, VPNv6 und L2VPN EVPN.- Für redundante Reflektoren fügen Sie eine gemeinsame Cluster-Identität hinzu mit dem
bgp cluster-idBefehl imrouter bgpModus, ein separater Schritt, der in diesem Minimalbeispiel nicht gezeigt wird, sodass Clients einen Cluster sehen. Clients benötigen keine reflektorspezifische Konfiguration.
Die Befehle folgen dem OcNOS-SP Layer 3 Configuration Guide, documentation.ipinfusion.com.
Migrieren Sie den Core eine Rolle nach der anderen.
Offene Core-Router arbeiten mit einem installierten Cisco-, Juniper- oder Nokia-Netzwerk zusammen, sodass Sie Knoten für Knoten migrieren. Segment Routing läuft neben LDP und RSVP-TE, sodass der bestehende und der neue Transport während des Übergangs koexistieren.
Peering mit dem installierten Netzwerk
Ein neuer offener Router bildet IS-IS-, OSPF- und BGP-Adjazenzen mit dem installierten Cisco, Juniper und Nokia Knoten, sodass er sich ohne Redesign in den Core einfügt. Targo ist auf diese Weise migriert, interoperabel mit seinen installierten Cisco-, MikroTik- und Ubiquiti-Geräten.
Prefix-SIDs für die Legacy-Knoten ankündigen
Ein SR-Mapping-Server kündigt Prefix-SIDs im Namen der reinen LDP-Knoten an, sodass Segment Routing und LDP während der Umstellung über eine Domäne weiterleiten. Die LDP-SR-Interaktion, mit Graceful Restart für LDP und RSVP-TE, fügt SR-MPLS ohne Flag-Day-Umstellung hinzu.
Erst P, dann PE, dann Peering umstellen
Zuerst werden die Core-P-Router umgestellt, dann der PE-Edge, dann die Peering-Router, jeweils validiert, bevor sie produktiven Verkehr tragen. Graceful Restart und TI-LFA halten die vollständige Internet-BGP-Tabelle bei jedem Wechsel im Forwarding. IP Infusion unterstützt den Router in jedem Schritt.
Unterstützung bei der CLI-Übersetzung von Cisco IOS-XR zu OcNOS ist verfügbar, um die Konfigurationskonvertierung zu beschleunigen. Siehe die OcNOS-SP im Vergleich zu Cisco Vergleich für Details zu Funktionen und Lizenzierung.
Offener Core- und Peering-Router im Vergleich zu einem proprietären Core.
Ein offener Router hält die vollständige Peering-Tabelle und betreibt den SR-MPLS-Core mit derselben Leistungsfähigkeit wie eine Cisco- oder Juniper-Box, während der Betreiber Hardware von mehr als einem Hersteller unter einem einzigen Supportvertrag beziehen kann.
| Core-/Peering-Leistung | Offener Router (OcNOS-SP) | Proprietäres Chassis (Cisco / Juniper / Nokia) |
|---|---|---|
| Vollständige Internet-BGP-Tabelle (Transit und Peering) | ✓ | ✓ |
| RPKI-Ablehnung ungültiger Routen, MANRS-konforme Filterung | ✓ Details → | ✓ |
| BGP FlowSpec, RTBH, BGP-LS | ✓ | ✓ |
| SR-MPLS mit Flex-Algo und TI-LFA | ✓ Details → | ✓ |
| SRv6 (unterstützt neben SR-MPLS) | ✓ Details → | ✓ |
| Route Reflection und Konföderationen | ✓ | ✓ |
| Hardware-Beschaffung | Offenes Merchant-Silicon von mehreren Anbietern | Chassis aus einer Hand |
| Bereitstellung und Support | Kompletter Router, ein Supportvertrag, Hardware- und Software-Refresh getrennt | Herstellergebündelt |
| Core-Kapazität | 14.4 Tbps auf einem Broadcom Jericho2C+, großer Puffer | Merchant- und Custom-Silicon |
Cisco, IOS-XR, Cisco 8000, Juniper, Junos, Nokia und SR OS sind Marken ihrer jeweiligen Eigentümer. IP Infusion ist mit diesen Anbietern nicht verbunden und empfiehlt sie nicht; der Vergleich spiegelt die OcNOS-SP-Fähigkeiten wider, die überprüfbar sind in der Feature-Matrix. Um einen proprietären Core zu ersetzen, siehe den Vergleich OcNOS-SP im Vergleich zu Cisco .
Datenblatt, Solution-Brief und Referenzarchitektur.
Das OcNOS-SP-Datenblatt, der SR-MPLS-Upgrade-Brief und die Referenzarchitektur für den offenen IP-Core zum Teilen mit Ihrem Team. Kurzes Formular, und das PDF wird sofort heruntergeladen.
OcNOS-SP-Datenblatt
Der vollständige OcNOS-SP-Überblick: Rollen, Protokolle, Timing und die validierte Hardware, in einem PDF.
Datenblatt abrufenSR-MPLS-Upgrade mit OcNOS
Ein Migrationspfad von Cisco IOS-XR und Juniper Junos SR-MPLS zu OcNOS auf offener Hardware.
Brief anfordernReferenzarchitektur für einen offenen IP-Core
Ein validiertes Design für den Service-Provider-Core und den Peering-Edge: Dual-Plane-SR-MPLS, Full-Table-Peering mit RPKI, Route Reflection und Day-2-Betrieb.
Referenzarchitektur anfordernFragen zum Core und zum Peering-Edge.
Den offenen Core- und Peering-Router ansehen.
Sehen Sie, wie IP Infusion den P-, PE- und Peering-Router liefert, oder kontaktieren Sie uns, um Ihren Core- und Peering-Edge den passenden validierten Plattformen und Lizenzen zuzuordnen.
OcNOS-SP-Datenblatt
Kurzes Formular. Ihr PDF wird unmittelbar nach dem Absenden heruntergeladen.
✓ Ihr PDF wird in einem neuen Tab geöffnet.
Falls es sich nicht geöffnet hat, verwenden Sie den Link unten.
SR-MPLS-Upgrade mit OcNOS
Kurzes Formular. Ihr PDF wird unmittelbar nach dem Absenden heruntergeladen.
✓ Ihr PDF wird in einem neuen Tab geöffnet.
Falls es sich nicht geöffnet hat, verwenden Sie den Link unten.
Referenzarchitektur für einen offenen IP-Core
Kurzes Formular. Ihr PDF öffnet sich unmittelbar nach dem Absenden in einem neuen Tab.
✓ Ihr PDF wird in einem neuen Tab geöffnet…
Falls es sich nicht geöffnet hat, nutzen Sie den untenstehenden Link.
Passend aus dem Blog
Warum Service Provider auf Open Networking setzen: 5 Treiber
Betreiberseitiger Business-Case für die Verlagerung von SP-Core- und Peering-Netzen auf offene disaggregierte Router
Beitrag lesen →RPKI Route Origin Validation in OcNOS: ROV am Peering-Edge konfigurieren
BGP RPKI Origin Validation in OcNOS konfigurieren, um invalid-Routen am Peering-Edge zu verwerfen
Beitrag lesen →Segment Routing: SR-MPLS und SRv6 im Core
SR-MPLS- und SRv6-Transport für den IP-Core, das Underlay hinter den P- und PE-Rollen
Beitrag lesen →Möchten Sie, dass wir Sie kontaktieren?
Hinterlassen Sie Ihre Kontaktdaten, und ein Mitarbeiter des IP Infusion Teams unterstützt Sie gerne beim Design Ihres IP-Core- und Peering-Netzwerks. Wir melden uns nur, wenn Sie es wünschen.