Core (P) · Provider edge (PE) · Peering

Offene IP-Core- und Peering-Router

Name: OcNOS-SP
Brand: IP Infusion
Author: IP Infusion

Der offene IP-Core- und Peering-Router trägt die full internet BGP table for transit and peering and runs the SR-MPLS or SRv6 core between sites. IP Infusion delivers it complete: validated open hardware, OcNOS-SP pre-loaded, supported under one contract.

Den vollständigen Router ansehen OcNOS-SP Datenblatt

In der Produktion bewährt

Betreiber, die offene Core- und Peering-Router betreiben.

Vier Betreiber betreiben heute offene Core- und Peering-Router im Produktivbetrieb.

NWPS Betreibt Dual-Stack-BGP-Multihoming auf einem UfiSpace S9600-72XC mit OP2-External-TCAM und hält die vollständige Internet-BGP-Tabelle in Hardware für ein Schweizer Krankenhaus. Read the story → Citynet Rüstete ein Cisco-Backbone auf offene Router mit OcNOS um und nannte eine branchenübliche CLI und einen umfangreichen Funktionsumfang auf einem europäischen Backbone als Gründe. Read the story → Targo Von WISP zu Fiber gewachsen auf offenen Routern mit OcNOS, interoperabel mit installierter Cisco-, MikroTik- und Ubiquiti-Ausrüstung. Read the story → Africell Rollte ein disaggregiertes IP/MPLS-Backbone mit hoher Kapazität auf offenen Routern aus, um sowohl Mobil- als auch Festnetzverkehr in Sierra Leone zurückzuführen. Read the story →

"From a technical standpoint, OcNOS checked every box, full BGP table in hardware, dual-stack from day one, and a feature set that holds up against the traditional vendors." Markus Wellauer, Co-CEO, NWP Services GmbH (NWPS)

Die Referenzarchitektur

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.

OcNOS-SP-Router

SR-MPLS / SRv6 Transport

Redundante Dual-Plane

Extern / angrenzend

Öffnen Sie die Vektoransicht, um jeden Knoten für Rollen- und Protokolldetails zu überfahren.

Dasselbe Router-Image betreibt alle vier Rollen, lizenziert und dimensioniert je Rolle.

Open IP core

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 at 14.4 Tbps, with a single SR-MPLS or SRv6 core doing the forwarding.

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.

Core design →

Provider / transit

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 runs it with Flex-Algo, TI-LFA, and BFD.

Da die Schicht rein label-basiert bleibt, skalieren Sie den Core allein über die Weiterleitungskapazität.

SR-MPLS →MPLS-TE →

Provider edge

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.

Service edge →SRv6 →

Internet edge

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 validates every route with RPKI and applies your route policy right at the edge.

Route Reflectors halten die iBGP-Control-Plane dahinter skalierbar, während die Zahl der Peers wächst.

Full-table scale →BGP →

Route scale

Die vollständige Internet-BGP-Tabelle in Hardware vorhalten.

Der Peering-Router trägt die full internet BGP table for transit and settlement-free peering, IPv4 and IPv6 dual-stack, held in hardware on merchant silicon. For the largest tables, the design uses a platform with a large external TCAM.

Full-Table-Forwarding

Die vollständige Tabelle, Dual-Stack, in Hardware

Der Peering-Router trägt eine full internet BGP table for transit and settlement-free peering, IPv4 and IPv6 from day one. Graceful restart and TI-LFA keep forwarding stable while the control plane reconverges.

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.

Externer TCAM-Pfad

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 with OP2 external TCAM, dual-stack, with OcNOS-SP handling RPKI and route policy.

IP Infusion validiert, installiert vor und unterstützt diesen Router, sodass der Full-Table-Forwarding-Pfad als ein unterstütztes System ausgeliefert wird.

NWPS case study →

Peering-Edge-Engineering

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.

RFC 8210

RPKI-Ablehnung ungültiger Routen

Der Router führt RPKI route-origin validation and rejects invalid routes at the edge, with prefix filtering aligned with MANRS practices, so hijacked and leaked prefixes are dropped before they enter the table.

RFC 8955

BGP FlowSpec für DDoS-Abwehr

BGP FlowSpec distributes match-and-action filters across the edge, so a volumetric attack is dropped or rate-limited in the forwarding path as a routing workflow, without a per-router touch.

RFC 7999

Remote-Triggered Black-Holing

Der Router leitet ein angegriffenes Ziel per Black-Hole um mithilfe der RFC 7999 Blackhole-Community, so a single route announcement steers attack traffic to a discard next-hop across the peering edge.

RFC 1997 / 8092

BGP-Communities für Peering-Policy

BGP communities, including large communities per RFC 8092, tag and classify routes so peering, transit, and customer policy is applied consistently across the edge and inside the AS.

RFC 7752 / 8571

BGP-LS-Topologie und Egress-Engineering

BGP-LS exports the link-state topology to a PCE or controller, and SR BGP egress peer engineering steers traffic to a chosen peer, so egress selection becomes a controllable decision.

RFC 4456 / 5065

Route Reflection und Konföderationen

Route reflectors per RFC 4456 or BGP confederations per RFC 5065 scale the iBGP control plane, so the peering and core routers share the table without a full iBGP mesh.

Die BGP-Funktionsdetails ansehen auf der BGP technology page →

SR core design

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.

IGP- und Label-Plan

IS-IS mit SR, geplantes SRGB

IS-IS SR ist das Standard-IGP, und jeder Knoten teilt einen SRGB so a prefix-SID maps to the same label everywhere. The default SRGB range is 16000 to 23999.

SR-MPLS →

Dual plane

Flex-Algo Low-Latency-Ebene

Flexible Algorithm per RFC 9350 builds a second forwarding plane, tuned for low latency, alongside the default shortest-path plane on the same physical topology, with no overlay.

Fast reroute

Sub-50ms TI-LFA

TI-LFA precomputes a loop-free backup path for every destination, so the core reroutes in under 50ms around a link or node failure while IS-IS reconverges.

Traffic engineering

SR-TE mit einem PCE

SR-TE policies steer traffic on explicit paths, computed by a stateful PCE over PCEP, including egress steering at the peering edge for a chosen exit.

Segment routing →

SRGB-Planung, gemäß dem OcNOS-SP Segment-Routing Configuration Guide: a prefix-SID index of 1000 on a loopback maps to label 17000 when the SRGB base is 16000. Using an identical SRGB on every node keeps the same label for a prefix on every node, which simplifies operations.

Platform sizing

Welcher validierte Router für welche Rolle.

IP Infusion liefert den Core- und Peering-Router auf 43 validated platforms from Edgecore and UfiSpace, each lab-qualified per ASIC stepping with OcNOS-SP pre-loaded. The core sizes on forwarding capacity and buffering; the full-table edge sizes on the forwarding path that holds the table.

Validierte Router nach Core- und Peering-Rolle. Zuletzt verifiziert: Jul 2026.
Rolle	Validated router	Silicon und Kapazität	Warum es zur Rolle passt
Core / P-Router	UfiSpace S9610-36D	Broadcom Jericho2C+ (BCM88850), 14.4 Tbps, 36×400G, deep buffer	Höchste Weiterleitungskapazität mit Deep-Buffering sowie redundante, im laufenden Betrieb austauschbare Netzteile und Lüfter für Core und Internet-Edge.
Full-Table-Peering-Edge	UfiSpace S9600-72XC + OP2	Externer TCAM-Forwarding-Pfad, Dual-Stack	Hält die vollständige Internet-BGP-Tabelle in einem großen Forwarding-Pfad mit externem TCAM. Der Router, den NWP Services für Full-Table-Multihoming eingesetzt hat.
Aggregationsebene unterhalb des Core	UfiSpace S9600-56DX	Broadcom Qumran2c, 4.8 Tbps, 8×400G + 48×100G	Speist den Core mit einem 400G-Uplink. Das Aggregationsdesign wird verantwortet auf der metro Ethernet page.

Der Full-Table-External-TCAM-Router wird als die von NWP Services eingesetzte Plattform genannt. Jede validierte Plattform ansehen in der hardware compatibility list, and match features to hardware in the 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.
SR-MPLS or 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.
One contract. IP Infusion validiert und unterstützt jede Rolle als einen Router, und Hardware und Software werden in unabhängigen Zyklen erneuert.

Konfiguration: Route-Reflector-Cluster

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.

OcNOS-SP · route reflector

! 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-client

Was jede Zeile bewirkt

router bgp 200 enters BGP for the autonomous system that the core and peering routers share.
The three neighbor ... remote-as 200 lines form the iBGP sessions. 6.6.6.6 is a plain iBGP peer, so it does not get the route-reflector-client line below.
route-reflector-client designates each client per address family, here IPv4 unicast, and the same pattern applies to VPNv4, VPNv6, and L2VPN EVPN.
Für redundante Reflektoren fügen Sie eine gemeinsame Cluster-Identität hinzu mit dem bgp cluster-id command in router bgp mode, a separate step not shown in this minimal example, so clients see one cluster. Clients need no reflector-specific configuration.

Commands follow the OcNOS-SP Layer 3 configuration guide, documentation.ipinfusion.com.

Schrittweise Migration

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.

01 / Interop

Peering mit dem installierten Netzwerk

Ein neuer offener Router bildet IS-IS-, OSPF- und BGP-Adjazenzen mit dem installierten Cisco, Juniper und Nokia nodes, so it joins the core without a redesign. Targo migrated this way, interoperating with its installed Cisco, MikroTik, and Ubiquiti equipment.

02 / SR in die LDP-Domäne einbringen

Prefix-SIDs für die Legacy-Knoten ankündigen

An SR Mapping Server advertises prefix-SIDs on behalf of the LDP-only nodes, so segment routing and LDP forward across one domain during the conversion. LDP and SR interworking, with LDP and RSVP-TE graceful restart, adds SR-MPLS without a flag-day cutover.

03 / Umschaltung pro Rolle

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 comparison for capability and licensing detail.

Offen im Vergleich zu proprietär

Offener Core- und Peering-Router im Vergleich zu einem proprietären Core.

Die eigentliche Frage im Core ist, ob ein offener Router eine vollständige Peering-Tabelle und einen SR-MPLS-Core ebenso gut halten kann wie eine Cisco- oder Juniper-Box. Er kann es, und er tut es, während er dem Betreiber ermöglicht, Hardware von mehr als einem Anbieter zu kaufen und einen einzigen Supportvertrag zu behalten.

Offener Core- und Peering-Router auf OcNOS-SP im Vergleich zu proprietären Core-Plattformen. Zuletzt verifiziert: Juli 2026.
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	Vendor-bundled
Core capacity	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. To replace a proprietary core, see the OcNOS-SP im Vergleich zu Cisco comparison.

Ressourcen

Datenblatt und Solution-Brief.

Das OcNOS-SP-Datenblatt und der SR-MPLS-Upgrade-Brief zum Teilen mit Ihrem Team. Kurzes Formular, und das PDF wird sofort heruntergeladen.

Datenblatt

OcNOS-SP Datenblatt

Der vollständige OcNOS-SP-Überblick: Rollen, Protokolle, Timing und die validierte Hardware, in einem PDF.

Datasheet abrufen

Solution Brief

SR-MPLS-Upgrade mit OcNOS

Ein Migrationspfad von Cisco IOS-XR und Juniper Junos SR-MPLS zu OcNOS auf offener Hardware.

Brief anfordern

Bevor Sie evaluieren

Fragen zum Core und zum Peering-Edge.

Wie liefert IP Infusion einen offenen IP-Core-Router?

IP Infusion liefert den P-, PE- und Peering-Router als ein System: validierte offene Hardware von Edgecore oder UfiSpace mit vorinstalliertem OcNOS-SP, laborqualifiziert je Plattform und ASIC-Stepping, sowie eine validierte Day-0-Baseline mit ZTP-Onboarding. Ein Anbieter verantwortet Software, Hardware und RMA unter einem einzigen Supportvertrag, sodass ein Team für die Behebung zuständig ist. Box und Software wählen und erneuern Sie weiterhin in unabhängigen Zyklen.

Was ist ein P-Router gegenüber einem PE-Router im Core?

Im Core betreiben Sie zwei Rollen aus einem Router-Image. Der Provider-Edge (PE) bindet Kundenstandorte an und setzt das Transportlabel, sodass er den L3VPN- und EVPN-Servicezustand hält, den der Kunde sieht. Der Provider-Router (P) vermittelt gelabelte Pakete zwischen PE-Routern, ohne Kundenrouten zu halten, sodass er seine Kapazität für Forwarding und Fast Reroute einsetzt. Da beide Rollen aus demselben Image laufen, terminiert ein PE Services und ein P-Router trägt sie über den SR-MPLS- oder SRv6-Core, und Sie bevorraten und lizenzieren eine Plattform für beide.

Kann ein offener Router die vollständige Internet-BGP-Tabelle in Hardware halten?

Ja. Der Peering-Router trägt die vollständige Internet-BGP-Tabelle für Transit und Settlement-Free-Peering, IPv4- und IPv6-Dual-Stack, gehalten in Hardware auf Merchant-Silicon. Wenn Sie Platz für die größten Tabellen benötigen, dimensionieren Sie den Peering-Edge auf einer Plattform mit großem externem TCAM. NWP Services betreibt genau das auf einem UfiSpace S9600-72XC mit OP2 externem TCAM, Dual-Stack vom ersten Tag an, wobei OcNOS-SP RPKI und Route-Policy übernimmt.

Wie skalieren Route Reflector iBGP im Core?

Route Reflectors ermöglichen es Ihnen, den Core ohne ein iBGP-Full-Mesh zu erweitern: Clients peeren nur mit den Reflectors, und die Reflectors geben Routen zwischen ihnen weiter. OcNOS-SP führt BGP Route Reflection gemäß RFC 4456 aus, mit einer Cluster-Identität, sodass redundante Reflectors gegenüber Clients als ein Cluster erscheinen, und mit Client-Zuordnung je Address-Family für IPv4 Unicast, VPNv4, VPNv6 und L2VPN EVPN. Sie können diese Control Plane mit Route Reflection oder mit BGP-Konföderationen gemäß RFC 5065 skalieren, je nachdem, was zum Netz passt.

Unterstützt der Peering-Router RPKI und MANRS für die Routensicherheit?

Ja. Der Peering-Router führt gemäß RFC 8210 die Zurückweisung ungültiger RPKI-Routen durch, sodass Routen, die die Origin-Validierung nicht bestehen, am Internet-Edge verworfen werden, und Präfixfilterung wird im Einklang mit MANRS-Praktiken angewendet. BGP FlowSpec gemäß RFC 8955 schiebt DDoS-Mitigation-Filter an den Edge, und Remote-Triggered Black-Holing nutzt die RFC 7999 Blackhole-Community. BGP Communities, einschließlich Large Communities gemäß RFC 8092, steuern die Peering-Policy.

Wie betreibt der Router einen Dual-Plane-SR-MPLS-Core?

Der Core-Router betreibt IS-IS als IGP mit Segment-Routing-Erweiterungen, sodass ein Label-Switched-Path jeden Dienst zwischen Standorten trägt. Flexible Algorithm gemäß RFC 9350 baut eine Low-Latency-Ebene neben der standardmäßigen Shortest-Path-Ebene auf derselben Topologie auf, und TI-LFA liefert Fast Reroute unter 50ms. SR-TE-Policies mit einem PCE berechnen explizite Pfade, einschließlich Egress-Steering am Peering-Edge. Die SRGB-Planung nutzt den Standardbereich 16000 bis 23999 auf jedem Knoten.

Wie leitet der SR-MPLS-Core um einen Ausfall herum um?

Der Core reroutet in der Data Plane. TI-LFA berechnet vorab einen schleifenfreien Backup-Pfad für jedes Ziel, sodass der Core bei Ausfall eines Links oder Knotens in unter 50ms auf den Backup umschaltet, während IS-IS im Hintergrund rekonvergiert. BGP-, OSPF- und IS-IS Graceful Restart halten die vollständige Internet-BGP-Tabelle während dieser Rekonvergenz im Forwarding, und BFD erkennt den Ausfall schnell über Single-Hop-, Multi-Hop- und SR-Pfade. Eine redundante Dual-Plane sowie hot-swap-fähige Netzteile und Lüfter halten die Box durch ein Hardwareereignis hindurch im Traffic.

Unterstützt der Core SRv6 oder nur SR-MPLS?

SR-MPLS ist die standardmäßige Core-Data-Plane, und SRv6 ist auf unterstützenden Plattformen und Releases verfügbar, wenn ein Netz eine IPv6-Data-Plane ohne separate MPLS-Control-Plane wünscht. Da beide auf demselben Router-Image und IGP laufen, migriert ein Betreiber das Underlay auf SRv6, ohne die darüberliegenden L3VPN- und EVPN-Dienste umzuhängen. Die SRv6-Verfügbarkeit hängt von Plattform und Release ab, kontaktieren Sie uns daher, um den Funktionsumfang für Ihre Hardware zu bestätigen.

Den Router evaluieren

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.

Den vollständigen Router ansehen Kontakt How to buy

Aus dem Blog

Passend aus dem Blog

Sep 2022

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 → May 2024

Segment Routing erklärt: 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 →

Alle Blog-Beiträge →

Lösungen

Produkte

Partner