Routers de core IP y peering abiertos
El router de core IP y peering abierto lleva 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.
Operadores que ejecutan routers de core y peering abiertos.
Cuatro operadores ejecutan hoy routers de core y peering abiertos en producción.
"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, codirector ejecutivo, NWP Services GmbH (NWPS)
El router de core y peering en cuatro roles.
El mismo router OcNOS-SP cubre cada rol de core, por lo que el operador ejecuta una imagen y un contrato de soporte en lugar de comprar una caja distinta para el borde, el core, el peering y la reflexión de rutas.
Abra la vista vectorial para pasar el cursor sobre cada nodo y ver los detalles de rol y protocolo.
La misma imagen de router ejecuta los cuatro roles, licenciada y dimensionada por rol.
Core router
Usted lleva cada servicio entre sitios sobre un underlay a la mayor capacidad que ofrece el portfolio: el UfiSpace S9610-36D at 14.4 Tbps, with a single SR-MPLS or SRv6 core doing the forwarding.
Un doble plano redundante mantiene ese core transportando tráfico mientras un enlace o nodo se recupera, por lo que un fallo en medio de la red nunca se convierte en una interrupción.
P router
En el core, el router P conmuta tráfico etiquetado y no mantiene rutas de cliente, por lo que dedica todo su presupuesto a la capacidad y al reenrutamiento rápido en lugar de al estado de rutas. OcNOS-SP runs it with Flex-Algo, TI-LFA, and BFD.
Como la capa permanece solo de etiquetas, usted escala el core únicamente por capacidad de reenvío.
PE router
El router PE es donde los sitios de cliente se unen al core: impone la etiqueta de transporte y mantiene el estado de servicio L3VPN y EVPN, por lo que lleva la escala de VPN que la capa P nunca toca.
Desde ahí entrega el borde de servicio a la agregación metropolitana, por lo que el core permanece limpio y el estado del servicio vive en el borde donde corresponde.
Peering router
El router de peering es su puerta a los proveedores de tránsito y los intercambios de internet, llevando la tabla BGP completa de internet para ambos. OcNOS-SP validates every route with RPKI and applies your route policy right at the edge.
Los route reflectors mantienen escalable el plano de control iBGP detrás a medida que crece el número de peers.
Mantener la tabla BGP completa de internet en hardware.
El router de peering lleva 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.
La tabla completa, dual-stack, en hardware
El router de peering lleva 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.
Los route reflectors transportan la tabla iBGP entre routers de core para que los clientes eviten una malla completa, lo que mantiene el plano de control escalable a medida que la red crece.
Una TCAM externa grande para las tablas más grandes
Cuando un router necesita mantener la tabla global completa en una ruta de reenvío de hardware grande, el diseño usa una plataforma con una TCAM externa. NWP Services ejecuta exactamente esto: un UfiSpace S9600-72XC with OP2 external TCAM, dual-stack, with OcNOS-SP handling RPKI and route policy.
IP Infusion valida, precarga y da soporte a ese router, por lo que la ruta de reenvío de tabla completa se envía como un solo sistema soportado.
Seguridad de rutas y control de tráfico en el borde de internet.
El router de peering valida las rutas que acepta, filtra lo que anuncia, y envía mitigación al borde durante un ataque. RPKI, BGP FlowSpec, blackholing activado de forma remota y comunidades BGP dan al borde de internet sus controles de seguridad de rutas.
Rechazo de rutas inválidas RPKI
El router realiza 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.
BGP FlowSpec para mitigación de 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.
Blackholing activado de forma remota
El router hace blackhole de un destino atacado usando la Comunidad blackhole RFC 7999, so a single route announcement steers attack traffic to a discard next-hop across the peering edge.
Comunidades BGP para la política de 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.
Topología BGP-LS e ingeniería de egreso
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.
Reflexión de rutas y confederaciones
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.
Consulte el detalle de la función BGP en la BGP technology page →
Un core SR-MPLS de doble plano, con SRv6 junto a él.
El router de core ejecuta IS-IS con extensiones de segment-routing como su IGP por defecto, por lo que una ruta conmutada por etiquetas lleva cada servicio. El Flexible Algorithm construye un plano de baja latencia junto al plano por defecto sobre la misma topología, y TI-LFA da reenrutamiento rápido de menos de 50 ms.
IS-IS con SR, SRGB planificado
IS-IS SR es el IGP por defecto, y cada nodo comparte un SRGB so a prefix-SID maps to the same label everywhere. The default SRGB range is 16000 to 23999.
Plano de baja latencia 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.
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.
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.
Planificación de SRGB, según la guía de configuración de segment-routing de 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.
Qué router validado para qué rol.
IP Infusion entrega el router de core y peering sobre 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.
| Función | Validated router | Silicio y capacidad | Por qué encaja en el rol |
|---|---|---|---|
| Router core / P |  UfiSpace S9610-36D |
Broadcom Jericho2C+ (BCM88850), 14.4 Tbps, 36×400G, deep buffer | Máxima capacidad de reenvío con deep buffering y alimentación y ventiladores redundantes intercambiables en caliente para el core y el borde de internet. |
| Borde de peering de tabla completa |  UfiSpace S9600-72XC + OP2 |
TCAM externa en la ruta de reenvío, dual-stack | Mantiene la tabla BGP completa de internet en una ruta de reenvío de TCAM externa grande. El router que NWP Services desplegó para multihoming de tabla completa. |
| Borde de servicio (PE) |  UfiSpace S9600-56DX |
Broadcom Qumran2C, 4.8 Tbps, 8×400G plus 100G access | Impone la etiqueta de transporte y mantiene el estado L3VPN y EVPN, con uplinks de 400G hacia el core. Admite SRv6 junto con SR-MPLS en el nivel de silicio compatible. |
| Borde de servicio compacto |  UfiSpace S9600-28DX |
Broadcom Qumran2C, 2.4 Tbps, dual-stack | Un borde de servicio compacto para sitios más pequeños que aún necesitan transporte SR-MPLS y servicios L3VPN y EVPN, en el nivel de silicio compatible con SRv6. |
| Nivel de agregación bajo el core | UfiSpace S9600-56DX |
Broadcom Qumran2c, 4.8 Tbps, 8×400G + 48×100G | Alimenta el core con un enlace ascendente de 400G. El diseño de agregación es propiedad de la Ethernet metro page. |
El router de TCAM externa de tabla completa se cita como la plataforma que NWP Services desplegó. Consulte cada plataforma validada en la lista de compatibilidad de hardware, y haga coincidir las funciones con el hardware en la matriz de funciones.
Cómo dimensionar el router de core y peering
- Tabla completa ahora o margen de crecimiento. Dimensione el borde de peering en un router que mantenga hoy la tabla BGP completa de internet en hardware, o una ruta de TCAM externa grande cuando necesite margen para hacer crecer la tabla.
- Capacidad y buffering del core. Dimensione el core por capacidad de reenvío y deep buffering para microbursts de borde de internet, no por estado de rutas, ya que la capa P no mantiene rutas de cliente.
- Core en un solo equipo o en clúster. Diseñe el core como un par redundante para que TI-LFA tenga una ruta de respaldo. El plano redundante transporta el tráfico durante un fallo.
- SR-MPLS or SRv6. Ejecute SR-MPLS como core por defecto, y SRv6 junto a él donde su estrategia de transporte lo requiera, disponibilidad por plataforma y versión.
- Route reflection. Coloque route reflectors para escalar iBGP: en línea en los routers de core para una red más pequeña, o reflectors dedicados a medida que crece el número de peers.
- Peering directo o route server. Haga peering directo con redes de alto volumen para el control y utilice un route server de IXP para la larga cola de pares settlement-free.
- One contract. IP Infusion valida y da soporte a cada rol como un solo router, y el hardware y el software se renuevan en ciclos independientes.
Configurar un clúster de route-reflector.
Usted escala iBGP sin una malla completa apuntando los clientes a los reflectors y dejando que los reflectors pasen rutas entre ellos. La configuración de OcNOS-SP de abajo hace exactamente eso: tres vecinos iBGP, dos de ellos designados route-reflector-clients en la familia de direcciones 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-clientQué hace cada línea
router bgp 200enters BGP for the autonomous system that the core and peering routers share.- The three
neighbor ... remote-as 200lines form the iBGP sessions. 6.6.6.6 is a plain iBGP peer, so it does not get theroute-reflector-clientline below. route-reflector-clientdesignates each client per address family, here IPv4 unicast, and the same pattern applies to VPNv4, VPNv6, and L2VPN EVPN.- Para reflectores redundantes, añada una identidad de clúster compartida con el
bgp cluster-idcommand inrouter bgpmode, 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.
Migre el core un rol cada vez.
Los routers de core abiertos interoperan con una red Cisco, Juniper o Nokia instalada, por lo que usted migra nodo por nodo. El segment routing se ejecuta junto a LDP y RSVP-TE, por lo que el transporte existente y el nuevo coexisten durante la transición.
Hacer peering con la red instalada
Un nuevo router abierto forma adyacencias IS-IS, OSPF y BGP con el Cisco, Juniper y Nokia nodes, so it joins the core without a redesign. Targo migrated this way, interoperating with its installed Cisco, MikroTik, and Ubiquiti equipment.
Anunciar prefix-SID para los nodos heredados
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.
Convertir P, luego PE, luego peering
Convierta primero los routers P del core, luego el borde PE, luego los routers de peering, validando cada uno antes de que transporte tráfico en producción. Graceful restart y TI-LFA mantienen la tabla BGP completa de internet reenviando durante cada cambio. IP Infusion da soporte al router en cada paso.
Hay asistencia disponible para la traducción de CLI de Cisco IOS-XR a OcNOS para acelerar la conversión de configuración. Consulte la OcNOS-SP frente a Cisco comparison for capability and licensing detail.
Router de core y peering abierto frente a un core propietario.
La verdadera pregunta en el core es si un router abierto puede mantener una tabla de peering completa y un core SR-MPLS tan bien como una caja Cisco o Juniper. Puede, y lo hace mientras permite al operador comprar hardware de más de un proveedor y mantener un solo contrato de soporte.
| Capacidad de core / peering | Router abierto (OcNOS-SP) | Chasis propietario (Cisco / Juniper / Nokia) |
|---|---|---|
| Tabla BGP completa de internet (tránsito y peering) | ✓ | ✓ |
| Rechazo de rutas inválidas RPKI, filtrado alineado con MANRS | ✓ details → | ✓ |
| BGP FlowSpec, RTBH, BGP-LS | ✓ | ✓ |
| SR-MPLS con Flex-Algo y TI-LFA | ✓ details → | ✓ |
| SRv6 (soportado junto a SR-MPLS) | ✓ details → | ✓ |
| Reflexión de rutas y confederaciones | ✓ | ✓ |
| Aprovisionamiento de hardware | Silicio merchant abierto de múltiples proveedores | Chasis de un solo proveedor |
| Entrega y soporte | Router completo, un contrato de soporte, renovación de hardware y software por separado | Vendor-bundled |
| Core capacity | 14.4 Tbps en un Broadcom Jericho2C+, deep buffer | Silicio merchant y personalizado |
Cisco, IOS-XR, Cisco 8000, Juniper, Junos, Nokia y SR OS son marcas comerciales de sus respectivos propietarios. IP Infusion no está afiliada a estos proveedores ni los respalda; la comparación refleja las capacidades de OcNOS-SP verificables en la matriz de funciones. To replace a proprietary core, see the OcNOS-SP frente a Cisco comparison.
Datasheet y solution brief.
El datasheet de OcNOS-SP y el brief de actualización a SR-MPLS para compartir con su equipo. Formulario rápido, y el PDF se descarga de inmediato.
Datasheet de OcNOS-SP
La visión general completa de OcNOS-SP: roles, protocolos, temporización y el hardware validado, en un PDF.
Obtener el datasheetActualización SR-MPLS con OcNOS
Una ruta de migración desde SR-MPLS de Cisco IOS-XR y Juniper Junos hacia OcNOS en hardware abierto.
Obtener el briefPreguntas sobre el core y el borde de peering.
Consulte el router de core y peering abierto.
Vea cómo IP Infusion entrega el router P, PE y de peering, o contáctenos para mapear su core y borde de peering a las plataformas validadas y el licenciamiento adecuados.
Datasheet de OcNOS-SP
Formulario breve. su PDF se descargará de inmediato tras el envío.
✓ Opening your PDF in a new tab.
Si no se abrió, use el enlace de abajo.
OcNOS-SP-Datasheet-2026.pdfActualización SR-MPLS con OcNOS
Formulario breve. su PDF se descargará de inmediato tras el envío.
✓ Opening your PDF in a new tab.
Si no se abrió, use el enlace de abajo.
solution-brief-sr-mpls-upgrade-cisco-alternative.pdfRelacionado del blog
Por qué los proveedores de servicios despliegan redes abiertas: 5 impulsores
Caso de negocio del operador para trasladar las redes de core y peering SP a routers abiertos desagregados
Lea la publicación →Segment Routing explicado: SR-MPLS y SRv6 en el core
Transporte SR-MPLS y SRv6 para el core IP, el underlay detrás de los roles P y PE
Lea la publicación →