Routeurs de cœur IP et de peering ouverts
Le routeur de cœur IP et de peering ouvert transporte la table BGP internet complète pour le transit et le peering, et exécute le cœur SR-MPLS ou SRv6 entre les sites. IP Infusion le fournit complet : matériel ouvert validé, OcNOS-SP préchargé, couvert par un seul contrat.
Des opérateurs exploitant des routeurs de cœur et de peering ouverts.
Des opérateurs exploitent aujourd'hui en production des routeurs de cœur et de peering ouverts sous OcNOS. Quatre sont cités ci-dessous, chacun avec une étude de cas ou une annonce publiée.
« D'un point de vue technique, OcNOS cochait toutes les cases : table BGP complète en matériel, double pile dès le premier jour et un ensemble de fonctionnalités à la hauteur des fournisseurs traditionnels. » Markus Wellauer, Co-CEO, NWP Services GmbH (NWPS)
Le routeur de cœur et de peering dans quatre rôles.
Le même routeur OcNOS-SP couvre chaque rôle du cœur, de sorte que l'opérateur exploite une seule image et un seul contrat de support au lieu d'acheter un boîtier différent pour la bordure, le cœur, le peering et la réflexion de routes.
La même image de routeur exécute les quatre rôles, licenciée et dimensionnée par rôle.
Routeur de cœur
Vous acheminez chaque service entre les sites sur un seul underlay à la capacité la plus élevée que le portfolio offre : l'UfiSpace S9610-36D à 14,4 Tbps, avec un seul cœur SR-MPLS ou SRv6 assurant la transmission.
Un double plan redondant maintient l'acheminement du trafic au cœur pendant qu'une liaison ou un nœud se rétablit, de sorte qu'une défaillance au milieu du réseau ne devient jamais une panne.
Routeur P
Au cœur, le routeur P commute le trafic étiqueté et ne détient aucune route client, de sorte qu'il consacre tout son budget à la capacité et au reroutage rapide plutôt qu'à l'état de route. OcNOS-SP l'exploite avec Flex-Algo, TI-LFA et BFD.
Comme la couche reste uniquement en mode label, vous dimensionnez le cœur sur la seule capacité d'acheminement.
Routeur PE
Le routeur PE est l'endroit où les sites clients rejoignent le cœur de réseau : il impose l'étiquette de transport et détient l'état de service L3VPN et EVPN, de sorte qu'il porte l'échelle VPN que la couche P ne touche jamais.
À partir de là, il remet la périphérie de service à l'agrégation métropolitaine, de sorte que le cœur reste propre et que l'état de service réside à la périphérie où il doit être.
Routeur de peering
Le routeur de peering est votre porte vers les fournisseurs de transit et les points d'échange internet, transportant la table BGP internet complète pour les deux. OcNOS-SP valide chaque route avec RPKI et applique votre politique de routage directement en périphérie.
Les route reflectors maintiennent le plan de contrôle iBGP scalable en arrière-plan à mesure que le nombre de pairs augmente.
Maintenir la table BGP internet complète dans le matériel.
Le routeur de peering transporte la table BGP internet complète pour le transit et le peering gratuit (settlement-free), en double pile IPv4 et IPv6, conservée en matériel sur du silicon marchand. Pour les tables les plus volumineuses, la conception utilise une plateforme dotée d'une grande TCAM externe.
La table complète, double pile, en matériel
Le routeur de peering transporte une table BGP internet complète pour le transit et le peering gratuit (settlement-free), IPv4 et IPv6 dès le premier jour, sur une plateforme dimensionnée avec une grande TCAM externe. Le graceful restart et TI-LFA maintiennent une transmission stable pendant que le plan de contrôle reconverge.
Les route reflectors transportent la table iBGP entre les routeurs de cœur afin que les clients évitent un full mesh, ce qui maintient le plan de contrôle scalable à mesure que le réseau grandit.
Un grand TCAM externe pour les plus grandes tables
Lorsqu'un routeur doit conserver la table globale complète dans un large chemin de transfert matériel, la conception utilise une plateforme avec un TCAM externe. NWP Services fait exactement cela : un UfiSpace S9600-72XC avec TCAM externe OP2, double pile, avec OcNOS-SP qui gère RPKI et la politique de routage.
IP Infusion valide, précharge et prend en charge ce routeur, de sorte que le chemin d'acheminement à table complète est livré comme un seul système pris en charge.
Sécurité du routage et contrôle du trafic à la périphérie internet.
Le routeur de peering valide les routes qu'il accepte, filtre ce qu'il annonce et pousse l'atténuation vers la bordure pendant une attaque. RPKI, BGP FlowSpec, le black-holing déclenché à distance et les communautés BGP donnent à la bordure internet ses contrôles de sécurité de routes.
Rejet des routes invalides RPKI
Le routeur effectue RPKI assure la validation de l'origine des routes et rejette les routes invalides en périphérie, avec un filtrage de préfixes aligné sur les pratiques MANRS, afin que les préfixes détournés ou divulgués soient rejetés avant d'entrer dans la table.
BGP FlowSpec pour l'atténuation DDoS
BGP FlowSpec distribue des filtres de correspondance et d'action sur toute la périphérie, de sorte qu'une attaque volumétrique est rejetée ou limitée en débit dans le chemin de transmission, comme un workflow de routage, sans intervention routeur par routeur. Le workflow de détection et d'atténuation est décrit sur la page Protection DDoS .
Black-holing déclenché à distance
Le routeur met en black-hole une destination attaquée à l'aide du Communauté blackhole RFC 7999, de sorte qu'une seule annonce de route oriente le trafic d'attaque vers un next-hop de rejet sur toute la périphérie de peering.
Communautés BGP pour la politique de peering
Les communautés BGP, y compris les large communities selon la RFC 8092, balisent et classent les routes afin que les politiques de peering, de transit et clients s'appliquent de façon cohérente en périphérie et au sein de l'AS.
Topologie BGP-LS et ingénierie de sortie
BGP-LS exporte la topologie link-state vers un PCE ou un contrôleur, et l'egress peer engineering SR BGP oriente le trafic vers un pair choisi : la sélection de la sortie devient une décision maîtrisée.
Route reflection et confédérations
Les route reflectors selon la RFC 4456 ou les confédérations BGP selon la RFC 5065 font évoluer le plan de contrôle iBGP, de sorte que les routeurs de peering et de cœur partagent la table sans maillage iBGP complet.
Voir le détail des fonctionnalités BGP sur la page technologie BGP →
Un cœur SR-MPLS à double plan, avec SRv6 en parallèle.
Le routeur de cœur exécute IS-IS avec les extensions de segment-routing comme IGP par défaut, de sorte qu'un seul chemin à commutation d'étiquettes transporte chaque service. Flexible Algorithm construit un plan à faible latence à côté du plan par défaut sur la même topologie, et TI-LFA offre un reroutage rapide en moins de 50 ms.
IS-IS avec SR, SRGB planifié
IS-IS SR est l'IGP par défaut, et chaque nœud partage un seul SRGB afin qu'un prefix-SID corresponde au même label partout. La plage SRGB par défaut est 16000 à 23999.
Plan à faible latence Flex-Algo
Flexible Algorithm selon la RFC 9350 construit un second plan de transmission, optimisé pour une faible latence, à côté du plan par défaut du plus court chemin sur la même topologie physique, sans overlay.
TI-LFA en moins de 50 ms
TI-LFA précalcule un chemin de secours sans boucle pour chaque destination, de sorte que le cœur contourne une panne de liaison ou de nœud en moins de 50 ms pendant qu'IS-IS reconverge.
SR-TE avec un PCE
SR-TE policies orientent le trafic sur des chemins explicites calculés par un PCE stateful via PCEP, y compris l'orientation de la sortie en périphérie de peering vers un point de sortie choisi.
Planification du SRGB, conformément au guide de configuration segment-routing d'OcNOS-SP : un index de prefix-SID de 1000 sur une loopback correspond au label 17000 lorsque la base SRGB est 16000. Utiliser un SRGB identique sur chaque nœud conserve le même label pour un préfixe sur tous les nœuds, ce qui simplifie l'exploitation.
Quel routeur validé pour quel rôle.
IP Infusion fournit le routeur de cœur et de peering sur 40+ plateformes validées d'Edgecore et UfiSpace, chacune qualifiée en laboratoire par stepping d'ASIC avec OcNOS-SP préchargé. Le cœur se dimensionne selon la capacité de transmission et la mise en buffer ; la périphérie à table complète selon le chemin de transmission qui contient la table.
| Rôle | Routeurs validés | Pourquoi cela convient au rôle |
|---|---|---|
| Cœur / routeur P |
|
Capacité de niveau cœur de 7,2 Tbps et plus, avec des ports 400G pour terminer les liaisons montantes des PE et une mémoire tampon profonde. La couche P ne porte aucune route client ; elle se dimensionne donc sur la capacité d'acheminement. |
| Périphérie de peering à table complète |
|
Un chemin d'acheminement à TCAM externe contient la table BGP Internet complète en matériel, avec une mémoire tampon profonde pour les micro-rafales en bordure Internet. NWP Services exploite le S9600-72XC dans ce rôle. |
| Périphérie de service (PE) |
|
Liaisons montantes 400G vers le cœur, au niveau service edge de 2,4 à 4,8 Tbps. Impose le label de transport et porte l'état L3VPN et EVPN, avec SRv6 pris en charge aux côtés de SR-MPLS sur ce niveau de silicium. |
| Périphérie de service compacte |
|
Liaisons montantes 400G à 2,4 Tbps et moins, pour les petits sites PE qui ont besoin du transport SR-MPLS et des services L3VPN et EVPN, sur le niveau de silicium compatible SRv6. |
| Niveau d'agrégation sous le cœur |
|
Alimente le cœur avec une liaison montante 400G. La conception d'agrégation est traitée sur la Ethernet métro . |
Le routeur à table complète avec TCAM externe est cité comme la plateforme déployée par NWP Services. Voir toutes les plateformes validées dans la liste de compatibilité matérielle, et faites correspondre les fonctionnalités au matériel dans la matrice de fonctionnalités.
Comment dimensionner le routeur de cœur et de peering
- Table complète maintenant ou marge de croissance. Dimensionnez la bordure de peering sur un routeur qui détient aujourd'hui la table BGP internet complète en matériel, ou sur une option à grand TCAM externe lorsque vous avez besoin de marge pour agrandir la table.
- Capacité et bufferisation du cœur. Dimensionnez le cœur de réseau selon la capacité de transfert et la mise en tampon profonde pour les microrafales de la bordure internet, et non selon l'état des routes, puisque la couche P ne détient aucune route client.
- Cœur en boîtier unique ou en cluster. Concevez le cœur comme une paire redondante afin que TI-LFA dispose d'un chemin de secours. Le plan redondant achemine le trafic à travers une panne.
- SR-MPLS ou SRv6. Exécutez SR-MPLS comme cœur par défaut, et SRv6 en parallèle là où votre stratégie de transport l'exige, selon la disponibilité par plateforme et version.
- Réflexion de routes. Placez des route reflectors pour faire passer iBGP à l'échelle : en inline sur les routeurs de cœur pour un réseau plus petit, ou des reflectors dédiés à mesure que le nombre de pairs augmente.
- Peering direct ou route server. Établissez un peering direct avec les réseaux à fort volume pour le contrôle, et utilisez un route server d'IXP pour la longue traîne des pairs settlement-free.
- Edgecore ou UfiSpace. Chaque rôle est validé sur du matériel Edgecore et UfiSpace avec la même image OcNOS-SP, ce qui vous permet de vous standardiser sur un seul fournisseur ou de les combiner sans changer le logiciel.
- Un seul contrat. IP Infusion valide et prend en charge chaque rôle comme un seul routeur, et le matériel et le logiciel se renouvellent sur des cycles indépendants.
Configurer un cluster de route reflectors.
Vous faites évoluer iBGP sans full mesh en dirigeant les clients vers les reflectors et en laissant les reflectors échanger les routes entre eux. La configuration OcNOS-SP ci-dessous fait exactement cela : trois voisins iBGP, deux d'entre eux désignés route-reflector-clients dans la famille d'adresses IPv4 unicast.
! Reflector: reflect routes between iBGP clients
configure terminal
routeur 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-clientCe que fait chaque ligne
router bgp 200ouvre la configuration BGP pour le système autonome que partagent les routeurs de cœur et de peering.- Les trois lignes
neighbor ... remote-as 200établissent les sessions iBGP. 6.6.6.6 est un pair iBGP simple : il ne reçoit donc pas la ligneroute-reflector-clientci-dessous. route-reflector-clientdésigne chaque client par famille d'adresses, ici IPv4 unicast, et le même principe s'applique à VPNv4, VPNv6 et L2VPN EVPN.- Pour des reflectors redondants, ajoutez une identité de cluster partagée avec la
bgp cluster-id(commande) en moderouter bgp, une étape distincte non illustrée dans cet exemple minimal, afin que les clients voient un seul cluster. Les clients ne nécessitent aucune configuration propre au reflector.
Les commandes suivent le guide de configuration de couche 3 d'OcNOS-SP, documentation.ipinfusion.com.
Migrez le cœur un rôle à la fois.
Les routeurs de cœur ouverts interopèrent avec un réseau Cisco, Juniper ou Nokia installé, ce qui vous permet de migrer nœud par nœud. Le segment routing s'exécute aux côtés de LDP et RSVP-TE, de sorte que le transport existant et le nouveau coexistent durant la transition.
Établir un peering avec le réseau déjà installé
Un nouveau routeur ouvert forme des adjacences IS-IS, OSPF et BGP avec le réseau installé Cisco, Juniper et Nokia (nœuds existants), de sorte qu'il rejoint le cœur sans refonte. Targo a migré de cette façon, en interopérant avec ses équipements Cisco, MikroTik et Ubiquiti installés.
Annoncer les prefix-SID pour les nœuds hérités
Un serveur de mappage SR annonce les prefix-SID pour le compte des nœuds LDP uniquement, de sorte que le segment routing et LDP transmettent sur un même domaine pendant la conversion. L'interfonctionnement LDP et SR, avec le graceful restart LDP et RSVP-TE, ajoute SR-MPLS sans bascule brutale.
Convertir P, puis PE, puis le peering
Convertissez d'abord les routeurs P du cœur, puis la périphérie PE, puis les routeurs de peering, en validant chacun avant qu'il ne porte du trafic de production. Le graceful restart et TI-LFA maintiennent l'acheminement de la table BGP internet complète à travers chaque bascule. IP Infusion prend en charge le routeur à chaque étape.
Une assistance à la traduction CLI de Cisco IOS-XR vers OcNOS est disponible pour accélérer la conversion de configuration. Consultez le OcNOS-SP face à Cisco : comparatif détaillé des fonctionnalités et des licences.
Routeur de cœur et de peering ouvert face à un cœur propriétaire.
Un routeur ouvert détient la table de peering complète et exploite le cœur SR-MPLS avec la même capacité qu'un équipement Cisco ou Juniper, tout en permettant à l'opérateur de s'approvisionner en matériel auprès de plusieurs fournisseurs sous un seul contrat de support.
| Capacité cœur / peering | Routeur ouvert (OcNOS-SP) | Châssis propriétaire (Cisco / Juniper / Nokia) |
|---|---|---|
| Table BGP internet complète (transit et peering) | ✓ | ✓ |
| Rejet des routes invalides RPKI, filtrage aligné sur MANRS | ✓ détails → | ✓ |
| BGP FlowSpec, RTBH, BGP-LS | ✓ | ✓ |
| SR-MPLS avec Flex-Algo et TI-LFA | ✓ détails → | ✓ |
| SRv6 (pris en charge en parallèle de SR-MPLS) | ✓ détails → | ✓ |
| Route reflection et confédérations | ✓ | ✓ |
| Approvisionnement matériel | Silicon marchand ouvert de plusieurs fournisseurs | Châssis à fournisseur unique |
| Livraison et support | Routeur complet, un seul contrat de support, renouvellement séparé du matériel et du logiciel | Solution groupée fournisseur |
| Capacité du cœur | 14,4 Tbps sur un Broadcom Jericho2C+, buffer profond | Silicon marchand et personnalisé |
Cisco, IOS-XR, Cisco 8000, Juniper, Junos, Nokia et SR OS sont des marques de leurs propriétaires respectifs. IP Infusion n'est pas affilié à ces fournisseurs et ne les approuve pas ; la comparaison reflète les capacités d'OcNOS-SP vérifiables dans la matrice de fonctionnalités. Pour remplacer un cœur propriétaire, consultez le comparatif OcNOS-SP face à Cisco .
Fiche technique, note de solution et architecture de référence.
La fiche technique OcNOS-SP, la fiche de mise à niveau SR-MPLS et l'architecture de référence du cœur IP ouvert à partager avec votre équipe. Formulaire rapide, et le PDF se télécharge immédiatement.
Datasheet OcNOS-SP
La vue d'ensemble complète OcNOS-SP : rôles, protocoles, synchronisation et matériel validé, dans un seul PDF.
Obtenir la fiche techniqueMise à niveau SR-MPLS avec OcNOS
Un chemin de migration depuis Cisco IOS-XR et Juniper Junos SR-MPLS vers OcNOS sur matériel ouvert.
Obtenir le briefArchitecture de référence de cœur IP ouvert
Une conception validée pour le cœur opérateur et la périphérie de peering : SR-MPLS double plan, peering à table complète avec RPKI, réflexion de routes et exploitation day-2.
Obtenir l'architecture de référenceQuestions sur le cœur et la périphérie de peering.
Voir le routeur de cœur et de peering ouvert.
Découvrez comment IP Infusion fournit le routeur P, PE et de peering, ou contactez-nous pour associer votre cœur de réseau et votre bordure de peering aux bonnes plateformes validées et aux bonnes licences.
Datasheet OcNOS-SP
Formulaire court. votre PDF se télécharge immédiatement après l'envoi.
✓ Ouverture de votre PDF dans un nouvel onglet.
S'il ne s'est pas ouvert, utilisez le lien ci-dessous.
Mise à niveau SR-MPLS avec OcNOS
Formulaire court. votre PDF se télécharge immédiatement après l'envoi.
✓ Ouverture de votre PDF dans un nouvel onglet.
S'il ne s'est pas ouvert, utilisez le lien ci-dessous.
Architecture de référence de cœur IP ouvert
Formulaire rapide. Votre PDF s'ouvre dans un nouvel onglet immédiatement après l'envoi.
✓ Ouverture de votre PDF dans un nouvel onglet…
S'il ne s'est pas ouvert, utilisez le lien ci-dessous.
À lire aussi sur le blog
Pourquoi les opérateurs déploient l'open networking : 5 facteurs
Analyse de rentabilité côté opérateur pour faire migrer les réseaux de cœur et de peering SP vers des routeurs ouverts et désagrégés
Lire l'article →Validation de l'origine des routes RPKI sur OcNOS : configurer le ROV en périphérie de peering
Configurer la validation d'origine BGP RPKI sur OcNOS pour rejeter les routes invalid en périphérie de peering
Lire l'article →Segment Routing : SR-MPLS et SRv6 dans le cœur
Transport SR-MPLS et SRv6 pour le cœur IP, l'underlay derrière les rôles P et PE
Lire l'article →Souhaitez-vous que nous vous contactions ?
Laissez-nous vos coordonnées : un membre de l'équipe IP Infusion se fera un plaisir de vous aider à concevoir votre cœur de réseau IP et votre réseau de peering. Nous ne vous contacterons que si vous le souhaitez.