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

Router IP core e peering aperti

L'IP core e peering router aperto trasporta la 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.

Consulti il router completo Datasheet OcNOS-SP
Comprovato in produzione

Operatori che eseguono core e peering router aperti.

Quattro operatori eseguono oggi in produzione core e peering router aperti.

NWPS Esegue multihoming BGP dual-stack su un UfiSpace S9600-72XC con TCAM esterno OP2, mantenendo la tabella BGP internet completa in hardware per un ospedale svizzero. Read the story → Citynet Aggiornato un backbone Cisco a router aperti su OcNOS, citando una CLI standard di settore e un ampio set di funzionalità su un backbone europeo. Read the story → Targo Cresciuta da WISP a fibra su router aperti che eseguono OcNOS, interoperando con apparecchiature Cisco, MikroTik e Ubiquiti installate. 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)

L'architettura di riferimento

Il core e peering router in quattro ruoli.

Lo stesso OcNOS-SP router copre ogni ruolo core, così l'operatore esegue un'unica immagine e un unico contratto di supporto invece di acquistare un box diverso per l'edge, il core, il peering e il 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.

La stessa immagine router esegue tutti e quattro i ruoli, concessa in licenza e dimensionata per ruolo.

Open IP core

Core router

Trasporti ogni servizio tra i siti su un unico underlay alla massima capacità che il portafoglio offre: l'UfiSpace S9610-36D at 14.4 Tbps, with a single SR-MPLS or SRv6 core doing the forwarding.

Un doppio piano ridondante mantiene quel core in funzione mentre un collegamento o un nodo si ripristina, così un guasto nel mezzo della rete non diventa mai un'interruzione.

Core design →
Provider / transit

P router

Nel core, il P router commuta il traffico etichettato e non mantiene route cliente, così spende l'intero budget in capacità e fast reroute anziché in stato delle route. OcNOS-SP runs it with Flex-Algo, TI-LFA, and BFD.

Poiché il livello resta solo a etichette, si scala il core sulla sola capacità di inoltro.

SR-MPLS →MPLS-TE →
Provider edge

PE router

Il PE router è dove i siti cliente si uniscono al core: impone l'etichetta di trasporto e mantiene lo stato di servizio L3VPN ed EVPN, così trasporta la scala VPN che il livello P non tocca mai.

Da lì passa l'edge di servizio all'aggregazione metro, così il core resta pulito e lo stato del servizio risiede all'edge dove appartiene.

Service edge →SRv6 →
Internet edge

Peering router

Il peering router è la sua porta verso i transit provider e gli internet exchange, trasportando la tabella BGP internet completa per entrambi. OcNOS-SP validates every route with RPKI and applies your route policy right at the edge.

I route reflector mantengono scalabile il piano di controllo iBGP dietro di esso man mano che il numero di peer cresce.

Full-table scale →BGP →
Route scale

Mantenimento della tabella BGP internet completa in hardware.

Il peering router trasporta la 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.

Inoltro a tabella completa

La tabella completa, dual-stack, in hardware

Il peering router trasporta una 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.

I route reflector trasportano la tabella iBGP tra i core router così che i client evitino una full mesh, il che mantiene scalabile il piano di controllo man mano che la rete cresce.

Percorso TCAM esterno

Un ampio TCAM esterno per le tabelle più grandi

Quando un router deve mantenere la tabella globale completa in un ampio percorso di inoltro hardware, il design usa una piattaforma con un TCAM esterno. NWP Services esegue esattamente questo: un UfiSpace S9600-72XC with OP2 external TCAM, dual-stack, with OcNOS-SP handling RPKI and route policy.

IP Infusion convalida, preinstalla e supporta quel router, così il percorso di inoltro a tabella completa viene consegnato come un unico sistema supportato.

NWPS case study →
Engineering dell'edge di peering

Sicurezza delle route e controllo del traffico all'edge internet.

Il peering router convalida le route che accetta, filtra ciò che annuncia e invia la mitigazione all'edge durante un attacco. RPKI, BGP FlowSpec, black-holing remote-triggered e community BGP danno all'edge internet i suoi controlli di sicurezza delle route.

RFC 8210

Rifiuto di route non valide RPKI

Il router esegue 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 per la mitigazione DDoS

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

Black-holing remote-triggered

Il router effettua il black-hole di una destinazione attaccata usando la Community di blackhole RFC 7999, so a single route announcement steers attack traffic to a discard next-hop across the peering edge.

RFC 1997 / 8092

Community BGP per la policy di peering

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

Topologia BGP-LS ed engineering di uscita

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 e confederazioni

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.

Consulti il dettaglio della funzionalità BGP nella BGP technology page →

SR core design

Un core SR-MPLS a doppio piano, con SRv6 affiancato.

Il core router esegue IS-IS con estensioni segment-routing come suo IGP predefinito, così un unico percorso label-switched trasporta ogni servizio. Flexible Algorithm costruisce un piano a bassa latenza affiancato al piano predefinito sulla stessa topologia, e TI-LFA offre fast reroute sotto i 50ms.

Piano IGP ed etichette

IS-IS con SR, SRGB pianificato

IS-IS SR è l'IGP predefinito, e ogni nodo condivide un unico SRGB so a prefix-SID maps to the same label everywhere. The default SRGB range is 16000 to 23999.

SR-MPLS →
Dual plane

Piano a bassa latenza Flex-Algo

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 con un 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 →

Pianificazione SRGB, secondo la guida di configurazione segment-routing di OcNOS-SP: 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

Quale router convalidato per quale ruolo.

IP Infusion fornisce il core e peering router su 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.

Router convalidati per ruolo core e peering. Ultima verifica: lug 2026.
Ruolo Validated router Silicio e capacità Perché si adatta al ruolo
Core / P router
UfiSpace S9610-36D open core router, 14.4 TbpsUfiSpace S9610-36D
 Broadcom Jericho2C+ (BCM88850), 14.4 Tbps, 36×400G, deep buffer Massima capacità di inoltro con deep buffering e alimentazione e ventole ridondanti hot-swappable per il core e l'edge internet.
Edge di peering a tabella completa
UfiSpace S9600-72XC open peering router with OP2 external TCAMUfiSpace S9600-72XC + OP2
 Percorso di inoltro TCAM esterno, dual-stack Mantiene la tabella BGP internet completa in un ampio percorso di inoltro TCAM esterno. Il router che NWP Services ha distribuito per il multihoming a tabella completa.
Edge di servizio (PE)
UfiSpace S9600-56DX open service-edge routerUfiSpace S9600-56DX
 Broadcom Qumran2C, 4.8 Tbps, 8×400G plus 100G access Impone l'etichetta di trasporto e mantiene lo stato L3VPN ed EVPN, con uplink 400G verso il core. Supporta SRv6 insieme a SR-MPLS sul livello di silicio di supporto.
Edge di servizio compatto
UfiSpace S9600-28DX compact service-edge routerUfiSpace S9600-28DX
 Broadcom Qumran2C, 2.4 Tbps, dual-stack Un edge di servizio compatto per i siti più piccoli che necessitano comunque del trasporto SR-MPLS e dei servizi L3VPN ed EVPN, sul livello di silicio compatibile con SRv6.
Livello di aggregazione sotto il core
UfiSpace S9600-56DX open aggregation router, 4.8 TbpsUfiSpace S9600-56DX
 Broadcom Qumran2c, 4.8 Tbps, 8×400G + 48×100G Alimenta il core con un uplink 400G. Il design di aggregazione è di competenza del metro Ethernet page.

Il router a tabella completa con TCAM esterno è citato come la piattaforma che NWP Services ha distribuito. Consulti ogni piattaforma convalidata nell' hardware compatibility list, e abbina le funzionalità all'hardware nella matrice delle funzionalità.

Come dimensionare il core e il peering router

  • Tabella completa ora o margine di crescita. Dimensiona l'edge di peering su un router che mantiene oggi la tabella BGP internet completa in hardware, o un ampio percorso TCAM esterno quando hai bisogno di margine per far crescere la tabella.
  • Capacità e buffering del core. Dimensiona il core sulla capacità di inoltro e sul deep buffering per i microburst dell'edge internet, non sullo stato delle route, poiché il livello P non mantiene route cliente.
  • Core in singolo chassis o in cluster. Progettate il core come una coppia ridondante affinché TI-LFA disponga di un percorso di backup. Il piano ridondante trasporta il traffico durante un guasto.
  • SR-MPLS or SRv6. Esegui SR-MPLS come core predefinito, e SRv6 affiancato dove la tua strategia di trasporto lo richiede, disponibilità per piattaforma e release.
  • Route reflection. Colloca i route reflector per scalare iBGP: inline sui core router per una rete più piccola, o reflector dedicati man mano che il numero di peer cresce.
  • Peering diretto o route server. Effettuate il peering diretto con le reti ad alto volume per il controllo e utilizzate un route server IXP per la coda lunga dei peer settlement-free.
  • One contract. IP Infusion convalida e supporta ogni ruolo come un unico router, e l'hardware e il software si aggiornano su cicli indipendenti.
Config: cluster di route-reflector

Configura un cluster di route-reflector.

Scali iBGP senza una full mesh puntando i client verso i reflector e lasciando che i reflector passino le route tra loro. La configurazione OcNOS-SP qui sotto fa esattamente questo: tre neighbor iBGP, due dei quali designati route-reflector-client nella famiglia di indirizzi IPv4 unicast.

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

Cosa fa ogni riga

  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. Per reflector ridondanti, aggiungi un'identità di cluster condivisa con 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.

Migrazione per fasi

Migra il core un ruolo alla volta.

I core router aperti interoperano con una rete Cisco, Juniper o Nokia installata, così migri nodo per nodo. Il segment routing funziona affiancato a LDP e RSVP-TE, così il trasporto esistente e quello nuovo coesistono durante la transizione.

01 / Interop

Effettua il peering con la rete installata

Un nuovo router aperto forma adiacenze IS-IS, OSPF e BGP con la rete Cisco, Juniper e 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 nel dominio LDP

Annuncia i prefix-SID per i nodi legacy

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 / Migrazione per ruolo

Converti P, poi PE, poi peering

Converti prima i core P router, poi il PE edge, poi i peering router, convalidando ciascuno prima che trasporti traffico di produzione. Graceful restart e TI-LFA mantengono la tabella BGP internet completa in inoltro durante ogni sostituzione. IP Infusion supporta il router a ogni passaggio.

È disponibile assistenza per la traduzione CLI da Cisco IOS-XR a OcNOS per accelerare la conversione della configurazione. Consulti la OcNOS-SP rispetto a Cisco comparison for capability and licensing detail.

Aperto vs proprietario

Core e peering router aperto rispetto a un core proprietario.

La vera domanda al core è se un router aperto possa mantenere una tabella di peering completa e un core SR-MPLS altrettanto bene di un box Cisco o Juniper. Può, e lo fa consentendo all'operatore di acquistare hardware da più di un fornitore e mantenere un unico contratto di supporto.

Core e peering router aperto su OcNOS-SP rispetto a piattaforme core proprietarie. Ultima verifica: lug 2026.
Capacità core / peering Router aperto (OcNOS-SP) Chassis proprietario (Cisco / Juniper / Nokia)
Tabella BGP internet completa (transito e peering) ✓ ✓
Rifiuto di route non valide RPKI, filtraggio allineato a MANRS ✓ details → ✓
BGP FlowSpec, RTBH, BGP-LS ✓ ✓
SR-MPLS con Flex-Algo e TI-LFA ✓ details → ✓
SRv6 (supportato affiancato a SR-MPLS) ✓ details → ✓
Route reflection e confederazioni ✓ ✓
Approvvigionamento hardware Silicio merchant aperto da più fornitori Chassis single-vendor
Consegna e supporto Router completo, un unico contratto di supporto, rinnovo di hardware e software separatamente Vendor-bundled
Core capacity 14.4 Tbps su Broadcom Jericho2C+, deep buffer Silicio merchant e custom

Cisco, IOS-XR, Cisco 8000, Juniper, Junos, Nokia e SR OS sono marchi dei rispettivi proprietari. IP Infusion non è affiliata e non approva questi fornitori; il confronto riflette le capacità di OcNOS-SP verificabili nella matrice delle funzionalità. To replace a proprietary core, see the OcNOS-SP rispetto a Cisco comparison.

Risorse

Datasheet e solution brief.

Il datasheet OcNOS-SP e il brief di upgrade SR-MPLS da condividere con il suo team. Modulo rapido, e il PDF si scarica immediatamente.

Datasheet

Datasheet OcNOS-SP

La panoramica OcNOS-SP completa: ruoli, protocolli, timing e l'hardware convalidato, in un unico PDF.

Ottieni il datasheet
Solution brief

Upgrade SR-MPLS con OcNOS

Un percorso di migrazione da Cisco IOS-XR e Juniper Junos SR-MPLS a OcNOS su hardware aperto.

Scarica il brief
Prima di valutare

Domande sul core e sull'edge di peering.

IP Infusion fornisce il P, PE e peering router come un unico sistema: hardware aperto convalidato Edgecore o UfiSpace con OcNOS-SP preinstallato, qualificato in laboratorio per piattaforma e stepping ASIC, e una baseline Day 0 convalidata con onboarding ZTP. Un unico fornitore possiede il software, l'hardware e l'RMA sotto un unico contratto di supporto, così un unico team possiede la risoluzione. Continua a scegliere e a rinnovare il box e il software su cicli indipendenti.
Nel core esegui due ruoli da un'unica immagine router. Il provider edge (PE) collega i siti cliente e impone l'etichetta di trasporto, così mantiene lo stato di servizio L3VPN ed EVPN che il cliente vede. Il provider (P) router commuta i pacchetti etichettati tra i router PE senza mantenere le route cliente, così spende la sua capacità in inoltro e fast reroute. Poiché entrambi i ruoli funzionano dalla stessa immagine, un PE termina i servizi e un P router li trasporta attraverso il core SR-MPLS o SRv6, e si tiene a magazzino e si concede in licenza un'unica piattaforma per entrambi.
Sì. Il peering router trasporta la tabella BGP internet completa per transito e peering settlement-free, IPv4 e IPv6 dual-stack, mantenuta in hardware su silicio merchant. Quando hai bisogno di margine per le tabelle più grandi, dimensioni l'edge di peering su una piattaforma con un ampio TCAM esterno. NWP Services esegue esattamente questo su un UfiSpace S9600-72XC con TCAM esterno OP2, dual-stack fin dal primo giorno, con OcNOS-SP che gestisce RPKI e la policy delle route.
I route reflector ti consentono di far crescere il core senza una full mesh iBGP: i client effettuano il peering solo con i reflector, e i reflector passano le route tra loro. OcNOS-SP effettua il route reflection BGP secondo RFC 4456, con un'identità di cluster così che i reflector ridondanti si presentino ai client come un unico cluster, e designazione dei client per-address-family per IPv4 unicast, VPNv4, VPNv6 e L2VPN EVPN. Puoi scalare quel piano di controllo con route reflection o con confederazioni BGP secondo RFC 5065, a seconda di ciò che si adatta alla rete.
Sì. Il peering router effettua il rifiuto di route non valide RPKI secondo RFC 8210, così le route che falliscono la validazione dell'origine vengono scartate all'edge internet, e il filtraggio dei prefissi è applicato in allineamento alle pratiche MANRS. BGP FlowSpec secondo RFC 8955 invia filtri di mitigazione DDoS all'edge, e il black-holing remote-triggered usa la community di blackhole RFC 7999. Le community BGP, incluse le large community secondo RFC 8092, guidano la policy di peering.
Il core router esegue IS-IS come IGP con estensioni segment-routing, così un unico percorso label-switched trasporta ogni servizio tra i siti. Flexible Algorithm secondo RFC 9350 costruisce un piano a bassa latenza affiancato al piano predefinito a percorso più breve sulla stessa topologia, e TI-LFA offre fast reroute sotto i 50ms. Le policy SR-TE con un PCE calcolano percorsi espliciti, incluso lo steering di uscita all'edge di peering. La pianificazione SRGB usa l'intervallo predefinito da 16000 a 23999 su ogni nodo.
Il core reindirizza nel data plane. TI-LFA precalcola un percorso di backup loop-free per ogni destinazione, così quando un collegamento o un nodo si guasta il core passa al backup in meno di 50ms mentre IS-IS riconverge in background. Graceful restart BGP, OSPF e IS-IS mantengono la tabella BGP internet completa in inoltro durante quella riconvergenza, e BFD rileva il guasto velocemente su percorsi single-hop, multi-hop e SR. Un doppio piano ridondante e alimentazione e ventole hot-swappable mantengono il box in funzione durante un evento hardware.
SR-MPLS è il data plane core predefinito, e SRv6 è disponibile su piattaforme e release supportate dove una rete desidera un data plane IPv6 senza un piano di controllo MPLS separato. Poiché entrambi funzionano sulla stessa immagine router e IGP, un operatore migra l'underlay a SRv6 senza re-homing dei servizi L3VPN ed EVPN sovrastanti. La disponibilità di SRv6 dipende dalla piattaforma e dalla release, quindi ci contatti per confermare il set di funzionalità per il suo hardware.
Valuta il router

Consulti il core e peering router aperto.

Scopra come IP Infusion fornisce il P, PE e peering router, oppure ci contatti per mappare il suo core e edge di peering sulle piattaforme convalidate e sulle licenze corrette.

Consulti il router completo Contattaci How to buy
Dal blog

Correlati dal blog

Perché i Service Provider stanno adottando l'open networking: 5 fattori

Business case lato operatore per lo spostamento delle reti core e peering SP verso router aperti disaggregati

Leggi il post →

Segment Routing Spiegato: SR-MPLS e SRv6 nel Core

Trasporto SR-MPLS e SRv6 per l'IP core, l'underlay dietro i ruoli P e PE

Leggi il post →
Tutti gli articoli del blog →