Router IP core e peering aperti
L'IP core e peering router aperto trasporta la tabella BGP Internet completa per transito e peering ed esegue il core SR-MPLS o SRv6 tra i siti. IP Infusion lo fornisce completo: hardware aperto validato, OcNOS-SP precaricato, con supporto in un unico contratto.
Operatori che eseguono core e peering router aperti.
Gli operatori utilizzano oggi in produzione router core e di peering aperti con OcNOS. Quattro sono citati di seguito, ciascuno con un caso di studio o un annuncio pubblicato.
"Dal punto di vista tecnico, OcNOS soddisfaceva ogni requisito: tabella BGP completa in hardware, dual-stack fin dal primo giorno e un set di funzionalità all'altezza dei fornitori tradizionali." Markus Wellauer, Co-CEO, NWP Services GmbH (NWPS)
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.
La stessa immagine router esegue tutti e quattro i ruoli, concessa in licenza e dimensionata per ruolo.
Router core
Trasporti ogni servizio tra i siti su un unico underlay alla massima capacità che il portafoglio offre: l'UfiSpace S9610-36D a 14.4 Tbps, con un unico core SR-MPLS o SRv6 che gestisce l'inoltro.
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.
Router P
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 lo esegue con Flex-Algo, TI-LFA e BFD.
Poiché il livello resta solo a etichette, si scala il core sulla sola capacità di inoltro.
Router PE
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.
Router di peering
Il peering router è la vostra porta verso i transit provider e gli internet exchange, trasportando la tabella BGP internet completa per entrambi. OcNOS-SP valida ogni route con RPKI e applica la vostra route policy direttamente sull'edge.
I route reflector mantengono scalabile il piano di controllo iBGP dietro di esso man mano che il numero di peer cresce.
Mantenimento della tabella BGP internet completa in hardware.
Il peering router trasporta la tabella BGP Internet completa per transito e peering settlement-free, dual-stack IPv4 e IPv6, mantenuta in hardware su merchant silicon. Per le tabelle più grandi, il design utilizza una piattaforma con un ampio TCAM esterno.
La tabella completa, dual-stack, in hardware
Il peering router trasporta una tabella BGP Internet completa per transito e peering settlement-free, IPv4 e IPv6 fin dal primo giorno, su una piattaforma dimensionata con un ampio TCAM esterno. Graceful restart e TI-LFA mantengono stabile l'inoltro mentre il control plane riconverge.
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.
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 con TCAM esterno OP2, dual-stack, con OcNOS-SP che gestisce RPKI e 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.
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.
Rifiuto di route non valide RPKI
Il router esegue RPKI la route origin validation e rifiuta le route non valide sull'edge, con filtraggio dei prefissi allineato alle pratiche MANRS, così i prefissi dirottati e trapelati vengono scartati prima di entrare nella tabella.
BGP FlowSpec per la mitigazione DDoS
BGP FlowSpec distribuisce filtri match-and-action sull'edge, così un attacco volumetrico viene scartato o limitato nel percorso di inoltro come workflow di routing, senza intervenire su ogni singolo router. Il workflow di rilevamento e mitigazione è descritto nella pagina Protezione DDoS dedicata.
Black-holing remote-triggered
Il router effettua il black-hole di una destinazione attaccata usando la Community di blackhole RFC 7999, così un singolo annuncio di route indirizza il traffico di attacco verso un next-hop di discard su tutto l'edge di peering.
Community BGP per la policy di peering
BGP community, incluse le large community secondo RFC 8092, etichettano e classificano le route così che le policy di peering, transito e clienti siano applicate in modo coerente sull'edge e all'interno dell'AS.
Topologia BGP-LS ed engineering di uscita
BGP-LS esporta la topologia link-state verso un PCE o un controller, e l'egress peer engineering SR BGP indirizza il traffico verso un peer scelto, così la selezione dell'uscita diventa una decisione controllabile.
Route reflection e confederazioni
Route reflector secondo RFC 4456 o le confederazioni BGP secondo RFC 5065 scalano il control plane iBGP, così i router di peering e core condividono la tabella senza una maglia iBGP completa.
Consultate il dettaglio della funzionalità BGP nella pagina tecnologica BGP →
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.
IS-IS con SR, SRGB pianificato
IS-IS SR è l'IGP predefinito, e ogni nodo condivide un unico SRGB così un prefix-SID corrisponde alla stessa etichetta ovunque. L'intervallo SRGB predefinito è da 16000 a 23999.
Piano a bassa latenza Flex-Algo
Flexible Algorithm secondo RFC 9350 crea un secondo piano di inoltro, ottimizzato per la bassa latenza, accanto al piano shortest-path predefinito sulla stessa topologia fisica, senza overlay.
TI-LFA sotto i 50 ms
TI-LFA precalcola un percorso di backup loop-free per ogni destinazione, così il core reinstrada in meno di 50 ms attorno a un guasto di link o di nodo mentre IS-IS riconverge.
SR-TE con un PCE
SR-TE policy indirizzano il traffico su percorsi espliciti, calcolati da un PCE stateful tramite PCEP, incluso l'egress steering sull'edge di peering verso un'uscita scelta.
Pianificazione SRGB, secondo la guida di configurazione segment-routing di OcNOS-SP: un indice prefix-SID pari a 1000 su un loopback corrisponde all'etichetta 17000 quando la base SRGB è 16000. Usare un SRGB identico su ogni nodo mantiene la stessa etichetta per un prefisso su ogni nodo, semplificando l'operatività.
Quale router convalidato per quale ruolo.
IP Infusion fornisce il core e peering router su 40+ piattaforme qualificate di Edgecore e UfiSpace, ciascuna qualificata in laboratorio per ogni stepping dell'ASIC con OcNOS-SP precaricato. Il core si dimensiona in base alla capacità di inoltro e al buffering, l'edge a tabella completa in base al percorso di inoltro che contiene la tabella.
| Ruolo | Router validati | Perché si adatta al ruolo |
|---|---|---|
| Core / router P |
|
Capacità di livello core da 7,2 Tbps in su, con porte 400G per terminare gli uplink dei PE e buffer profondo. Il livello P non contiene route dei clienti, quindi si dimensiona sulla capacità di inoltro. |
| Edge di peering a tabella completa |
|
Un percorso di inoltro con TCAM esterna mantiene in hardware l'intera tabella BGP di Internet, con buffer profondo per i microburst dell'edge Internet. NWP Services utilizza l'S9600-72XC in questo ruolo. |
| Edge di servizio (PE) |
|
Uplink 400G verso il core, al livello service edge da 2,4 a 4,8 Tbps. Impone l'etichetta di trasporto e mantiene lo stato L3VPN ed EVPN, con SRv6 supportato insieme a SR-MPLS su questo livello di silicio. |
| Edge di servizio compatto |
|
Uplink 400G a 2,4 Tbps e meno, per siti PE più piccoli che richiedono comunque trasporto SR-MPLS e servizi L3VPN ed EVPN, sul livello di silicio compatibile con SRv6. |
| Livello di aggregazione sotto il core |
|
Alimenta il core con un uplink 400G. Il design di aggregazione è di competenza del Ethernet metropolitana dedicata. |
Il router a tabella completa con TCAM esterno è citato come la piattaforma che NWP Services ha distribuito. Consultate ogni piattaforma convalidata nell' elenco di compatibilità hardware, 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. Dimensionate l'edge di peering su un router che mantiene oggi la tabella BGP internet completa in hardware, o un ampio percorso TCAM esterno quando avete bisogno di margine per far crescere la tabella.
- Capacità e buffering del core. Dimensionate 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 o SRv6. Eseguite SR-MPLS come core predefinito, e SRv6 affiancato dove la vostra 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.
- Edgecore o UfiSpace. Ogni ruolo è validato su hardware Edgecore e UfiSpace con la stessa immagine OcNOS-SP, così potete standardizzarvi su un unico fornitore o combinarli senza cambiare il software.
- Un unico contratto. IP Infusion convalida e supporta ogni ruolo come un unico router, e l'hardware e il software si aggiornano su cicli indipendenti.
Configura un cluster di route-reflector.
Scalate 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.
! 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-clientCosa fa ogni riga
router bgp 200entra in BGP per l'autonomous system condiviso dai router core e di peering.- Le tre righe
neighbor ... remote-as 200formano le sessioni iBGP. 6.6.6.6 è un semplice peer iBGP, quindi non riceve la rigaroute-reflector-clientriportata sotto. route-reflector-clientdesigna ogni client per address family, qui IPv4 unicast, e lo stesso schema si applica a VPNv4, VPNv6 e L2VPN EVPN.- Per reflector ridondanti, aggiungi un'identità di cluster condivisa con
bgp cluster-idnella modalitàrouter bgpun passaggio separato non mostrato in questo esempio minimo, così i client vedono un unico cluster. I client non richiedono alcuna configurazione specifica per il reflector.
I comandi seguono la guida di configurazione Layer 3 di OcNOS-SP, documentation.ipinfusion.com.
Migrate 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.
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 così si inserisce nel core senza riprogettazione. Targo ha migrato in questo modo, interoperando con le apparecchiature Cisco, MikroTik e Ubiquiti già installate.
Annuncia i prefix-SID per i nodi legacy
Un server di mapping SR annuncia i prefix-SID per conto dei nodi solo LDP, così segment routing e LDP inoltrano su un unico dominio durante la conversione. L'interworking tra LDP e SR, con graceful restart di LDP e RSVP-TE, aggiunge SR-MPLS senza un passaggio flag-day.
Convertite P, poi PE, poi peering
Convertite 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. Consultate la OcNOS-SP rispetto a Cisco per il confronto di funzionalità e licenze.
Core e peering router aperto rispetto a un core proprietario.
Un router aperto mantiene la tabella di peering completa ed esegue il core SR-MPLS con la stessa capacità di un apparato Cisco o Juniper, consentendo all'operatore di approvvigionarsi di hardware da più di un fornitore con un unico contratto di supporto.
| 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 | ✓ dettagli → | ✓ |
| BGP FlowSpec, RTBH, BGP-LS | ✓ | ✓ |
| SR-MPLS con Flex-Algo e TI-LFA | ✓ dettagli → | ✓ |
| SRv6 (supportato affiancato a SR-MPLS) | ✓ dettagli → | ✓ |
| Route reflection e confederazioni | ✓ | ✓ |
| Approvvigionamento hardware | Merchant silicon aperto da più fornitori | Chassis single-vendor |
| Consegna e supporto | Router completo, un unico contratto di supporto, rinnovo di hardware e software separatamente | In bundle con il fornitore |
| Capacità del core | 14.4 Tbps su Broadcom Jericho2C+, deep buffer | Merchant silicon 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à. Per sostituire un core proprietario, consultate il confronto OcNOS-SP rispetto a Cisco .
Datasheet, solution brief e architettura di riferimento.
Il datasheet OcNOS-SP, il brief di upgrade SR-MPLS e l'architettura di riferimento del core IP aperto da condividere con il vostro team. Modulo rapido, e il PDF si scarica immediatamente.
Datasheet OcNOS-SP
La panoramica OcNOS-SP completa: ruoli, protocolli, timing e l'hardware convalidato, in un unico PDF.
Ottieni il datasheetUpgrade SR-MPLS con OcNOS
Un percorso di migrazione da Cisco IOS-XR e Juniper Junos SR-MPLS a OcNOS su hardware aperto.
Scarica il briefArchitettura di riferimento per un IP core aperto
Un design validato per il core del service provider e l'edge di peering: SR-MPLS dual-plane, peering a tabella completa con RPKI, route reflection e operazioni day-2.
Scarica l'architettura di riferimentoDomande sul core e sull'edge di peering.
Consultate il core e peering router aperto.
Scoprite come IP Infusion fornisce il P, PE e peering router, oppure contattateci per mappare il vostro core e edge di peering sulle piattaforme convalidate e sulle licenze corrette.
Datasheet OcNOS-SP
Modulo breve. Il PDF verrà scaricato subito dopo l'invio.
✓ Il PDF si sta aprendo in una nuova scheda.
Se non si è aperto, usate il link qui sotto.
Upgrade SR-MPLS con OcNOS
Modulo breve. Il PDF verrà scaricato subito dopo l'invio.
✓ Il PDF si sta aprendo in una nuova scheda.
Se non si è aperto, usate il link qui sotto.
Architettura di riferimento per un IP core aperto
Modulo rapido. Il vostro PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del vostro PDF in una nuova scheda…
Se non si è aperto, usate il link qui sotto.
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 →Validazione dell'origine delle rotte RPKI su OcNOS: configurare il ROV al peering edge
Configurare la validazione dell'origine BGP RPKI su OcNOS per scartare le rotte invalid al peering edge
Leggi il post →Segment Routing: 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 →Desiderate essere ricontattati?
Lasciate i vostri dati e un membro del team di IP Infusion sarà lieto di aiutarvi a progettare la vostra rete IP core e di peering. Vi contatteremo solo se lo desiderate.