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

Open IP core and peering routers

The open IP core and peering router carries the 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.

See the complete router OcNOS-SP Datasheet
Proven in production

Operators running open core and peering routers.

Four operators run open core and peering routers in production today.

NWPS Runs dual-stack BGP multihoming on a UfiSpace S9600-72XC with OP2 external TCAM, holding the full internet BGP table in hardware for a Swiss hospital. Read the story → Citynet Upgraded a Cisco backbone to open routers on OcNOS, citing an industry-standard CLI and an extensive feature set on a European backbone. Read the story → Targo Grew from WISP to fiber on open routers running OcNOS, interoperating with installed Cisco, MikroTik, and Ubiquiti equipment. Read the story → Africell Rolled out a high-capacity IP/MPLS backbone on open routers to backhaul both mobile and fixed traffic in Sierra Leone. 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)

The reference architecture

The core and peering router in four roles.

The same OcNOS-SP router covers every core role, so the operator runs one image and one support contract instead of buying a different box for the edge, the core, peering, and route reflection.

IP core and peering topology: P routers running an SR-MPLS or SRv6 core, PE routers at the service edge, and a peering router holding the full internet BGP table to an IXP with RPKI origin validation.
IP core and peering: OcNOS-SP P routers on an SR-MPLS or SRv6 core, PE routers at the service edge, and a peering router to Internet transit and an IXP.

The same router image runs all four roles, licensed and sized per role.

Open IP core

Core router

You carry every service between sites on one underlay at the highest capacity the portfolio offers: the UfiSpace S9610-36D at 14.4 Tbps, with a single SR-MPLS or SRv6 core doing the forwarding.

A redundant dual plane keeps that core carrying traffic while a link or node recovers, so a failure in the middle of the network never becomes an outage.

Core design →
Provider / transit

P router

In the core, the P router switches labeled traffic and holds no customer routes, so it spends its whole budget on capacity and fast reroute rather than route state. OcNOS-SP runs it with Flex-Algo, TI-LFA, and BFD.

Because the layer stays label-only, you scale the core on forwarding capacity alone.

SR-MPLS →MPLS-TE →
Provider edge

PE router

The PE router is where customer sites join the core: it imposes the transport label and holds the L3VPN and EVPN service state, so it carries the VPN scale the P layer never touches.

From there it hands the service edge off to metro aggregation, so the core stays clean and the service state lives at the edge where it belongs.

Service edge →SRv6 →
Internet edge

Peering router

The peering router is your door to transit providers and internet exchanges, carrying the full internet BGP table for both. OcNOS-SP validates every route with RPKI and applies your route policy right at the edge.

Route reflectors keep the iBGP control plane scalable behind it as the peer count grows.

Full-table scale →BGP →
Route scale

Holding the full internet BGP table in hardware.

The peering router carries the 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

The full table, dual-stack, in hardware

The peering router carries a full internet BGP table for transit and settlement-free peering, IPv4 and IPv6 from day one, on a platform sized with a large external TCAM. Graceful restart and TI-LFA keep forwarding stable while the control plane reconverges.

Route reflectors carry the iBGP table between core routers so clients avoid a full mesh, which keeps the control plane scalable as the network grows.

External-TCAM path

A large external TCAM for the biggest tables

When a router needs to hold the full global table in a large hardware forwarding path, the design uses a platform with an external TCAM. NWP Services runs exactly this: a UfiSpace S9600-72XC with OP2 external TCAM, dual-stack, with OcNOS-SP handling RPKI and route policy.

IP Infusion validates, pre-loads, and supports that router, so the full-table forwarding path ships as one supported system.

NWPS case study →
Peering-edge engineering

Route security and traffic control at the internet edge.

The peering router validates the routes it accepts, filters what it announces, and pushes mitigation to the edge during an attack. RPKI, BGP FlowSpec, remote-triggered black-holing, and BGP communities give the internet edge its route security controls.

RFC 8210

RPKI invalid-route rejection

The router performs 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 for DDoS mitigation

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

The router black-holes an attacked destination using the 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 for 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 topology and 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 and confederations

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.

See the BGP feature detail on the BGP technology page →

SR core design

A dual-plane SR-MPLS core, SRv6 alongside.

The core router runs IS-IS with segment-routing extensions as its default IGP, so one label-switched path carries every service. Flexible Algorithm builds a low-latency plane alongside the default plane on the same topology, and TI-LFA gives sub-50ms fast reroute.

IGP and label plan

IS-IS with SR, planned SRGB

IS-IS SR is the default IGP, and every node shares one 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 plane

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 with a 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 planning, per the 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

Which validated router for which role.

IP Infusion delivers the core and peering router on 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.

Validated routers by core and peering role. Last verified: Jul 2026.
Role Validated router Silicon and capacity Why it fits the role
Core / P router
UfiSpace S9610-36D open core router, 14.4 TbpsUfiSpace S9610-36D
 Broadcom Jericho2C+ (BCM88850), 14.4 Tbps, 36×400G, deep buffer Highest forwarding capacity with deep buffering and redundant hot-swappable power and fans for the core and the internet edge.
Full-table peering edge
UfiSpace S9600-72XC open peering router with OP2 external TCAMUfiSpace S9600-72XC + OP2
 External TCAM forwarding path, dual-stack Holds the full internet BGP table in a large external-TCAM forwarding path. The router NWP Services deployed for full-table multihoming.
Service edge (PE)
UfiSpace S9600-56DX open service-edge routerUfiSpace S9600-56DX
 Broadcom Qumran2C, 4.8 Tbps, 8×400G plus 100G access Imposes the transport label and holds L3VPN and EVPN state, with 400G uplinks into the core. Supports SRv6 alongside SR-MPLS on the supporting silicon tier.
Compact service edge
UfiSpace S9600-28DX compact service-edge routerUfiSpace S9600-28DX
 Broadcom Qumran2C, 2.4 Tbps, dual-stack A compact service edge for smaller sites that still needs SR-MPLS transport and L3VPN and EVPN services, on the SRv6-capable silicon tier.
Aggregation tier below core
UfiSpace S9600-56DX open aggregation router, 4.8 TbpsUfiSpace S9600-56DX
 Broadcom Qumran2c, 4.8 Tbps, 8×400G + 48×100G Feeds the core with a 400G uplink. Aggregation design is owned on the metro Ethernet page.

The full-table external-TCAM router is cited as the platform NWP Services deployed. See every validated platform in the hardware compatibility list, and match features to hardware in the feature matrix.

How to size the core and peering router

  • Full table now or headroom. Size the peering edge on a router that holds the full internet BGP table in hardware today, or a large external-TCAM path when you need room to grow the table.
  • Core capacity and buffering. Size the core on forwarding capacity and deep buffering for internet-edge microbursts, not on route state, since the P layer holds no customer routes.
  • Single-box or clustered core. Design the core as a redundant pair so TI-LFA has a backup path. The redundant plane carries traffic through a failure.
  • SR-MPLS or SRv6. Run SR-MPLS as the default core, and SRv6 alongside it where your transport strategy calls for it, availability per platform and release.
  • Route reflection. Place route reflectors to scale iBGP: inline on core routers for a smaller network, or dedicated reflectors as the peer count grows.
  • Direct peering or route server. Peer directly with high-volume networks for control, and use an IXP route server for the long tail of settlement-free peers.
  • One contract. IP Infusion validates and supports every role as one router, and the hardware and software refresh on independent cycles.
Config: route-reflector cluster

Configure a route-reflector cluster.

You scale iBGP without a full mesh by pointing clients at the reflectors and letting the reflectors pass routes between them. The OcNOS-SP configuration below does exactly that: three iBGP neighbors, two of them designated route-reflector-clients in the IPv4 unicast address family.

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

What each line does

  1. router bgp 200 enters BGP for the autonomous system that the core and peering routers share.
  2. 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.
  3. route-reflector-client designates each client per address family, here IPv4 unicast, and the same pattern applies to VPNv4, VPNv6, and L2VPN EVPN.
  4. For redundant reflectors, add a shared cluster identity with the 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.

Phased migration

Migrate the core one role at a time.

Open core routers interoperate with an installed Cisco, Juniper, or Nokia network, so you migrate node by node. Segment routing runs alongside LDP and RSVP-TE, so the existing and new transport coexist during the transition.

01 / Interop

Peer with the installed network

A new open router forms IS-IS, OSPF, and BGP adjacencies with the installed Cisco, Juniper, and 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 into the LDP domain

Advertise prefix-SIDs for the legacy nodes

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 / Per-role cutover

Convert P, then PE, then peering

Convert the core P routers first, then the PE edge, then the peering routers, validating each before it carries production traffic. Graceful restart and TI-LFA keep the full internet BGP table forwarding through each swap. IP Infusion supports the router at every step.

Cisco IOS-XR to OcNOS CLI translation assistance is available to speed configuration conversion. See the OcNOS-SP versus Cisco comparison for capability and licensing detail.

Open vs proprietary

Open core and peering router vs a proprietary core.

The real question at the core is whether an open router can hold a full peering table and an SR-MPLS core as well as a Cisco or Juniper box. It can, and it does it while letting the operator buy hardware from more than one vendor and keep a single support contract.

Open core and peering router on OcNOS-SP versus proprietary core platforms. Last verified: Jul 2026.
Core / peering capability Open router (OcNOS-SP) Proprietary chassis (Cisco / Juniper / Nokia)
Full internet BGP table (transit and peering) ✓ ✓
RPKI invalid-route rejection, MANRS-aligned filtering ✓ details → ✓
BGP FlowSpec, RTBH, BGP-LS ✓ ✓
SR-MPLS with Flex-Algo and TI-LFA ✓ details → ✓
SRv6 (supported alongside SR-MPLS) ✓ details → ✓
Route reflection and confederations ✓ ✓
Hardware sourcing Open merchant silicon from multiple vendors Single-vendor chassis
Delivery and support Complete router, one support contract, hardware and software refresh separately Vendor-bundled
Core capacity 14.4 Tbps on a Broadcom Jericho2C+, deep buffer Merchant and custom silicon

Cisco, IOS-XR, Cisco 8000, Juniper, Junos, Nokia, and SR OS are trademarks of their respective owners. IP Infusion is not affiliated with and does not endorse these vendors; the comparison reflects OcNOS-SP capabilities verifiable in the feature matrix. To replace a proprietary core, see the OcNOS-SP versus Cisco comparison.

Resources

Datasheet and solution brief.

The OcNOS-SP datasheet and the SR-MPLS upgrade brief to share with your team. Quick form, and the PDF downloads immediately.

Datasheet

OcNOS-SP Datasheet

The full OcNOS-SP overview: roles, protocols, timing, and the validated hardware, in one PDF.

Get the datasheet
Solution Brief

SR-MPLS Upgrade with OcNOS

A migration path from Cisco IOS-XR and Juniper Junos SR-MPLS to OcNOS on open hardware.

Get the brief
Before you evaluate

Questions about the core and the peering edge.

IP Infusion delivers the P, PE, and peering router as one system: validated open hardware from Edgecore or UfiSpace with OcNOS-SP pre-loaded, lab-qualified per platform and ASIC stepping, and a validated Day 0 baseline with ZTP onboarding. One vendor owns the software, the hardware, and the RMA under a single support contract, so one team owns the fix. You still choose and refresh the box and the software on independent cycles.
In the core you run two roles from one router image. The provider edge (PE) attaches customer sites and imposes the transport label, so it holds the L3VPN and EVPN service state the customer sees. The provider (P) router switches labeled packets between PE routers without holding customer routes, so it spends its capacity on forwarding and fast reroute. Because both roles run from the same image, a PE terminates services and a P router carries them across the SR-MPLS or SRv6 core, and you stock and license one platform for both.
Yes. The peering router carries the full internet BGP table for transit and settlement-free peering, IPv4 and IPv6 dual-stack, held in hardware on merchant silicon. When you need room for the largest tables, you size the peering edge on a platform with a large external TCAM. NWP Services runs exactly this on a UfiSpace S9600-72XC with OP2 external TCAM, dual-stack from day one, with OcNOS-SP handling RPKI and route policy.
Route reflectors let you grow the core without an iBGP full mesh: clients peer only with the reflectors, and the reflectors pass routes between them. OcNOS-SP does BGP route reflection per RFC 4456, with a cluster identity so redundant reflectors present as one cluster to clients, and per-address-family client designation for IPv4 unicast, VPNv4, VPNv6, and L2VPN EVPN. You can scale that control plane with route reflection or with BGP confederations per RFC 5065, whichever fits the network.
Yes. The peering router performs RPKI invalid-route rejection per RFC 8210, so routes that fail origin validation are dropped at the internet edge, and prefix filtering is applied aligned with MANRS practices. BGP FlowSpec per RFC 8955 pushes DDoS mitigation filters to the edge, and remote-triggered black-holing uses the RFC 7999 blackhole community. BGP communities, including large communities per RFC 8092, drive peering policy.
The core router runs IS-IS as the IGP with segment-routing extensions, so one label-switched path carries every service between sites. Flexible Algorithm per RFC 9350 builds a low-latency plane alongside the default shortest-path plane on the same topology, and TI-LFA gives sub-50ms fast reroute. SR-TE policies with a PCE compute explicit paths, including egress steering at the peering edge. SRGB planning uses the default 16000 to 23999 range on every node.
The core reroutes in the data plane. TI-LFA precomputes a loop-free backup path for every destination, so when a link or node fails the core switches to the backup in under 50ms while IS-IS reconverges in the background. BGP, OSPF, and IS-IS graceful restart keep the full internet BGP table forwarding during that reconvergence, and BFD detects the failure fast across single-hop, multi-hop, and SR paths. A redundant dual plane and hot-swappable power and fans keep the box carrying traffic through a hardware event.
SR-MPLS is the default core data plane, and SRv6 is available on supporting platforms and releases where a network wants an IPv6 data plane without a separate MPLS control plane. Because both run on the same router image and IGP, an operator migrates the underlay to SRv6 without re-homing the L3VPN and EVPN services on top. SRv6 availability depends on the platform and the release, so contact us to confirm the feature set for your hardware.
Evaluate the router

See the open core and peering router.

See how IP Infusion delivers the P, PE, and peering router, or contact us to map your core and peering edge to the right validated platforms and licensing.

See the complete router Contact us How to buy
From the blog

Related from the blog

Why Service Providers Are Deploying Open Networking: 5 Drivers

Operator-side business case for moving SP core and peering networks to open disaggregated routers

Read the post →

Segment Routing Explained: SR-MPLS and SRv6 in the Core

SR-MPLS and SRv6 transport for the IP core, the underlay behind the P and PE roles

Read the post →
All blog posts →