Fonctionnalité Unified MPLS, fonctions et exemple de configuration
Contenu
Introduction
Ce document présente Unified Multiprotocol Label Switching (MPLS), une fonctionnalité axée sur l’évolutivité. Il fournit un cadre de solutions technologiques afin d’intégrer un trafic ou des services de bout en bout simples dans une infrastructure segmentée traditionnellement. Il tire parti des avantages d’une infrastructure hiérarchique, qui améliore l’évolutivité, et de la conception simple du réseau.
Conditions préalables
Conditions requises
Aucune spécification déterminée n'est requise pour ce document.
Components Used
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Configuration
Évolution vers les réseaux
Lorsque vous examinez l’historique des services basés sur les paquets du réseau, vous pouvez observer un changement dans la valeur commerciale du réseau. Il y a les améliorations apportées à la connectivité discrète pour rendre les applications aussi fluides que possible et il y a les technologies qui prennent en charge la collaboration mobile. Enfin, les services en nuage sur demande sont introduits grâce aux services d’application afin d’optimiser les outils qu’utilisent les entreprises et d’améliorer le coût de propriété et la stabilité.
Figure 1
Cette amélioration continue de la valeur et des fonctions du réseau se traduit par un besoin omniprésent de simplicité, de facilité de gestion, d’intégration et de stabilité pour les réseaux qui ont été segmentés à la suite d’îlots opérationnels disjoints et de contrôle du trajet de bout en bout. Il faut à présent tout mettre en place au moyen d’une architecture unique, qui est facile à gérer, qui offre une évolutivité de 100 000 nœuds et qui utilise les technologies actuelles de disponibilité élevée et de convergence rapide. Voilà l’apport d’Unified MPLS au tableau, soit le réseau segmenté en un seul plan de contrôle et la visibilité du trajet de bout en bout.
Exigences du réseau moderne
- Augmentation de la demande en bande passante (vidéo)
- Augmentation de la complexité des applications (nuage et virtualisation)
- Augmentation du besoin de convergence (mobilité)
Comment simplifier les opérations de MPLS sur des réseaux de plus en plus importants avec des exigences d’applications plus complexes?
Difficultés de la version traditionnelle de MPLS avec les différentes technologies d’accès
- Complexité afin d’atteindre une convergence de 50 millisecondes avec TE FRR (Traffic Engineering Fast Reroute)
- Recours à des protocoles de routage sophistiqués et à une interaction avec les protocoles de couche 2
- Diviser les grands réseaux en domaines, tandis que les services sont fournis de bout en bout
- Mécanismes courants de résilience et de convergence de bout en bout
- Dépannage et provisionnement de bout en bout dans plusieurs domaines
L’attrait d’Unified MPLS est résumé dans la liste qui suit :
- Réduction du nombre de points opérationnels.
- Dans les plateformes de transport générales, il faut configurer un service sur chaque élément du réseau par des points opérationnels. Le système de gestion doit connaître la topologie.
- Dans Unified MPLS, vu l’intégration des îlots MPLS, le nombre minimal de points opérationnels est obtenu.
- Possibilité de provisionner facilement les services : VPN de couche 3 (L3), VPWS (Virtual Private Wire Service), VPLS (Virtual Private LAN Service), sans les mécanismes commutation-pseudofils (PW-stitching) ou InterAS. Avec l’introduction de MPLS dans l’agrégation, une configuration statique est évitée, ce qui crée des îlots MPLS.
- Fournir le transport MPLS de bout en bout.
- Maintenir les zones des protocoles de passerelle intérieure (IGP) séparées par des petites tables de routage.
- Convergence rapide.
- Dépannage et configuration faciles.
- Capacité d’intégration à toute technologie d’accès.
- Préparation IPv6.
Cisco Unified MPLS
La fonction Unified MPLS se définit par l’ajout de fonctionnalités avec la version classique ou traditionnelle de MPLS et améliore l’évolutivité, la sécurité, la simplicité et la facilité de gestion. Pour pouvoir fournir les services MPLS de bout en bout, les tunnels à commutation par étiquettes (LSP) de bout en bout sont requis. L’objectif est de maintenir les services MPLS (MPLS VPN, MPLS L2VPN) comme ils sont, tout en intégrant une plus grande évolutivité. Pour ce faire, transférez certains préfixes IGP dans le protocole BGP (Border Gateway Protocol) [les préfixes de bouclage des routeurs de périphérie fournisseur (PE)], lequel distribue ensuite les préfixes de bout en bout.
Figure 2
Avant d’aborder le sujet de l’architecture de Cisco Unified MPLS, il est important de comprendre les principales fonctions utilisées pour en faire une réalité.
Caractéristiques et fonctions
Acheminement des informations d’étiquette dans BGP-4 (RFC 3107)
L’emploi d’une méthode évolutive est une condition préalable à l’échange des préfixes entre les segments du réseau. Vous pouvez simplement fusionner les protocoles IGP (OSPF (Open Shortest Path First), IS-IS (Intermediate System-to-Intermediate System) ou EIGRP (Enhanced Interior Gateway Routing Protocol) en un seul domaine. Toutefois, un protocole IGP n’est pas conçu pour transporter 100 000 préfixes. Le protocole à privilégier alors est plutôt BGP. Il s’agit d’un protocole bien éprouvé qui prend en charge Internet avec 100 000 routages et des environnements MPLS-VPN ayant des millions d’entrées. Cisco Unified MPLS utilise BGP-4 avec l’échange d’informations d’étiquettes (RFC3107). Lorsque BGP distribue un routage, il peut également octroyer une étiquette MPLS qui correspond à ce routage. Les informations relatives à la mise en correspondance des étiquettes MPLS destinées au routage sont transportées dans le message de mise à jour BGP qui contient les informations relatives au routage. Si le saut suivant n’est pas modifié, l’étiquette est conservée; autrement, elle sera modifiée. Dans la fonction Unified MPLS, le saut suivant est modifié au niveau des routeurs de frontières de zone (ABR).
Lorsque vous activez RFC 3107 sur les deux routeurs BGP, ces derniers communiquent entre eux pour signaler qu’ils sont en mesure d’envoyer des étiquettes MPLS à l’aide des routeurs. Si les routeurs négocient avec succès leur capacité à envoyer des étiquettes MPLS, les routeurs ajoutent alors des étiquettes MPLS à toutes les mises à jour BGP sortantes.
L’échange d’étiquettes est nécessaire pour conserver les informations du trajet de bout en bout entre les segments. Par conséquent, chaque segment devient suffisamment petit pour être géré par les opérateurs et, en même temps, des informations sur les circuits sont transmises pour la prise en compte des trajets entre deux haut-parleurs IP.
Comment cela fonctionne-t-il?
Figure 3
Dans la figure 3, vous constaterez que trois segments ont le protocole LDP LSP (Label Discovery Protocol Labeled Switches Path) et que LDP n’est pas activé sur le réseau d’accès. L’objectif est de regrouper ces segments de manière à créer un seul chemin MPLS (LSP hiérarchique à BGP interne [iBGP]) entre les nœuds de préagrégation (Pre-Agg). Étant donné que le réseau est un système autonome (AS) BGP unique, toutes les sessions sont donc des sessions iBGP. Chaque segment utilise ses propres chemins IGP (OSPF, IS-IS ou EIGRP) et LDP LSP dans le domaine IGP. Dans Cisco Unified MPLS, les routeurs (ABR) qui se rallient aux segments doivent être des réflecteurs de routage BGP en ligne dotée de la commande « Next-Hop-Self » et RFC 3107 afin d’acheminer une étiquette IPv4+ configurée sur les sessions. Ces haut-parleurs BGP font partie de l’architecture Cisco Unified MPLS, désignés ABR.
Pourquoi les réflecteurs de routage en ligne sont-ils des ABR?
Un des objectifs d’Unified MPLS est l’accès à une infrastructure de bout en bout très évolutive. Ainsi, chaque segment doit demeurer simple pour bien fonctionner. Toutes les homologations sont des iBGP, et c’est pourquoi il faut un maillage complet d’homologues entre tous les haut-parleurs iBGP du réseau. Il en découle un environnement réseau qui s’avère très inapproprié en présence de milliers de haut-parleurs BGP. Si les ABR sont constitués de réflecteurs de routage, le nombre d’homologations iBGP est réduit au nombre de haut-parleurs par segments BGP au lieu du nombre total de haut-parleurs BGP de l’AS.
Pourquoi la commande « Next-Hop-Self »?
Le fonctionnement de BGP repose sur des recherches de routage récursives. Ainsi, l’évolutivité peut être adaptée dans l’IGP sous-jacent qui est utilisé. Pour la recherche récursive, BGP utilise le saut suivant associé à chaque entrée de routage BGP. Par exemple, si un nœud source souhaite envoyer un paquet à un nœud de destination, et si le paquet accède au routeur BGP, ce dernier effectue alors une recherche de routage dans sa table de routage BGP. Il trouve un routage vers le nœud de destination, puis recherche le saut suivant. L’IGP sous-jacent doit connaître le saut suivant. Finalement, le routeur BGP achemine le paquet à partir des informations de l’étiquette MPLS et de l’adresse IP qui sont associées au saut suivant.
Pour que seuls les sauts suivants puissent, dans chaque segment, être détectés par le protocole IGP, le saut suivant joint à l’entrée BGP doit se trouver dans le segment de réseau, et non dans un voisin ou un segment éloigné. Si vous réécrivez le saut suivant BGP avec la commande « Next-Hop-Self », assurez-vous que celui-ci se trouve dans le segment local.
Rassemblez tout
Figure 4
La figure 4 illustre comment fonctionne l’échange de l’étiquette et du préfixe VPN L3 « A » et comment la pile d’étiquettes MPLS est créée pour obtenir les informations du trajet de bout en bout du flux de trafic entre les deux PE.
Le réseau est divisé en trois domaines IGP/LDP indépendants. La taille réduite des tables de routage et de transfert sur les routeurs confère une meilleure stabilité et une convergence accélérée. LDP sert à créer des LSP intradomaines au sein de domaines. Les étiquettes RFC 3107 BGP IPv4+ sont utilisées comme protocole de distribution d’étiquettes interdomaines afin de créer des LSP BGP hiérarchiques dans les domaines. BGP 3107 ajoute une étiquette à la pile d’étiquettes de transfert dans l’architecture d’Unified MPLS.
Intradomaine – LDP LSP
Interdomaine – LSP BGP hiérarchique
Figure 5
Le préfixe VPN « A » est annoncé par PE31 à PE11 avec l’étiquette de service 30 L3VPN et le saut suivant en tant que boucle avec retour PE31 grâce au protocole BGP LSP hiérarchique interdomaine de bout en bout. Examinez maintenant le trajet d’acheminement du préfixe VPN « A » de PE11 à PE31.
- Sur PE11, le préfixe « A » est connu grâce à une session BGP avec PE31 en tant que saut suivant PE31, et PE31 est accessible de façon récursive par P1 avec l’étiquette BGP 100. PE11 a reçu les informations d’étiquette IPv4+ de P1 en tant que mises à jour BGP, car la fonction est activée avec RFC 3107 afin que soient bel et bien envoyées les informations de l’étiquette IPv4+.
- P1 est accessible à partir de PE11 grâce au protocole LDP LSP intradomaine et il ajoute une autre étiquette LDP sur l’étiquette BGP. Enfin, le paquet sort du nœud PE11 avec trois étiquettes. C’est-à-dire, l’étiquette de service 30 L3VPN, l’étiquette BGP 100 et l’étiquette LDP IGP 200.
- L’étiquette LDP supérieure continue d’être permutée dans le LDP LSP intradomaine, et le paquet atteint P1 avec deux étiquettes après la fonction PHP (Penultimate Hop Popping).
- P1 est configuré en tant que réflecteur de routage en ligne (RR) avec la commande « Next-Hop-Self » et joint deux domaines IGP ou LDP LSP.
- Sur P1, le saut suivant pour PE31 est désormais P2, et la mise à jour est reçue par BGP avec l’étiquette IPv4+ (RFC 3107). L’étiquette BGP est permutée avec une nouvelle étiquette, car le saut suivant est modifié et l’étiquette IGP est poussée dans le haut de l’écran.
- Le paquet sort du nœud P1 avec trois étiquettes, et l’étiquette de service 30 reste la même. Précisons ici l’étiquette de service 30 L3VPN, l’étiquette BGP 101 et l’étiquette LDP 201.
- L’étiquette LDP supérieure est permutée dans le LDP LSP intradomaine, et le paquet atteint P2 avec deux étiquettes après la fonction PHP.
- Sur P2, le saut suivant pour PE31 est de nouveau modifié et devient accessible par IGP. L’étiquette BGP est alors supprimée, car une étiquette BGP implicite nulle est reçue de PE31 pour PHP.
- À son départ, le paquet possède deux étiquettes. C’est-à-dire, l’étiquette de service 30 L3VPN et l’étiquette LDP 110.
- Sur PE31, le paquet arrive avec une étiquette après la fonction PHP de l’étiquette LDP et repose sur l’étiquette de service 30. Le paquet qui n’a aucune étiquette est transmis à la destination CE31 sous le routage et le transfert virtuels (VRF).
Lorsque vous examinez la pile d’étiquettes MPLS, vous pouvez constater, dans l’environnement de commutation MPLS, la commutation du paquet entre un périphérique source et un périphérique de destination en fonction de l’échange antérieur du préfixe et de l’étiquette.
Figure 6
Convergence de préfixes indépendants BGP (BGP PIC)
Il s’agit d’une technologie Cisco qui est utilisée dans les scénarios d’échec BGP. Le réseau converge sans perdre les secondes traditionnelles dans la reconvergence BGP. Si BGP PIC est utilisé, la plupart des scénarios de panne peuvent être réduits à une reconvergence inférieure à 100 ms.
Comment procède-t-on?
En règle générale, lorsque le protocole BGP détecte une panne, il recalcule chaque entrée BGP pour trouver le trajet le plus approprié. S’il y a une table de routage dotée de milliers d’entrées, cette opération peut prendre un certain temps. En outre, ce routeur BGP doit distribuer les nouveaux trajets les plus appropriés à chacun de ses voisins afin d’informer ces derniers de la nouvelle topologie du réseau et des meilleurs trajets déterminés. À la dernière étape, chaque haut-parleur BGP du destinataire doit calculer le meilleur trajet pour trouver les nouveaux trajets les plus appropriés.
Chaque fois que le premier haut-parleur BGP détecte un problème, il amorce le calcul du trajet le plus approprié jusqu’à ce que tous les haut-parleurs BGP voisins aient effectué leur recalcul; le flux de trafic risque alors d’être abandonné.
Figure 7
Le protocole BGP PIC pour IP et la fonction MPLS VPN améliorent la convergence BGP après une panne de réseau. Cette convergence s’applique à la fois aux pannes centrales et aux pannes de périphérie, et peut être utilisée dans les réseaux IP et MPLS. Le protocole BGP PIC pour IP et la fonction MPLS VPN créent et enregistrent un trajet de sauvegarde ou de remplacement dans la base d’informations de routage (RIB), la base d’informations de transfert (FIB) et la fonction Cisco Express Forwarding (CEF) de sorte que lorsqu’une panne est détectée, le trajet de sauvegarde ou de remplacement puisse prendre immédiatement le relais, permettant un basculement rapide.
Une seule réécriture des informations du saut suivant contribue à restaurer le flux de trafic. En outre, la convergence BGP du réseau se produit en arrière-plan, mais les flux de trafic ne sont plus perturbés. Cette réécriture survient en 50 ms. Avec cette technologie, la convergence du réseau passe alors de quelques secondes à 50 ms, plus la convergence IGP.
BGP Add-Path [ajouter-chemin BGP]
Le protocole BGP Add-Path constitue une amélioration de communication des entrées BGP entre les haut-parleurs BGP. Si un haut-parleur BGP comprend plusieurs entrées vers une destination donnée, ce haut-parleur envoie alors uniquement l’entrée qui correspond au trajet le plus approprié vers ses voisins. Ainsi, aucune disposition n’est prise pour permettre l’annonce de plusieurs trajets vers la même destination.
Le protocole BGP Add-Path est une fonction BGP qui permet plus que le trajet le plus approprié, et qui autorise plusieurs trajets vers la même destination, sans pourtant que les nouveaux trajets remplacent implicitement les précédents. Cette extension à BGP est particulièrement importante afin de favoriser le protocole BGP PIC, lorsque des réflecteurs de routage BGP sont employés, de sorte que les différents haut-parleurs BGP dans un AS ont accès à un plus grand nombre de trajets BGP, comme le trajet le plus approprié conforme au réflecteur de routage.
Solutions sans boucle et rLFA pour la convergence rapide IGP
Les opérations visant à atteindre une restauration de 50 ms après une panne de liaison ou de nœud peuvent être simplifiées considérablement grâce à l’introduction d’une nouvelle technologie, appelée « solutions sans boucle » ou LFA (Loop-Free Alternates). Les LFA améliorent les protocoles de routage à état de lien (IS-IS et OSPF) pour trouver des trajets de routage alternatifs sans boucle. Les LFA permettent à chaque routeur de cibler et d’utiliser un chemin de sauvegarde prédéterminé en cas de panne de contiguïté (nœud de réseau ou de lien). Pour fournir une restauration de 50 ms en cas de panne de lien ou de nœud, la fonction MPLS TE FRR peut être déployée. Il faut toutefois qu’un autre protocole soit ajouté (protocole de réservation de ressources ou RSVP) pour la configuration et la gestion des tunnels TE. Bien que cela puisse être nécessaire pour la gestion de la bande passante, l’opération de protection et de restauration ne requiert pas la gestion de la bande passante. Or, la surcharge associée à l’ajout de RSVP TE est considérée comme élevée pour une simple protection des liens et des nœuds.
Les LFA peuvent procurer une technique simple et facile, sans le déploiement de la fonction RSVP TE dans de tels scénarios. En raison de ces techniques, les routeurs interconnectés d’aujourd’hui, qui se trouvent dans les réseaux à grande échelle, peuvent fournir une restauration de 50 ms en cas de panne de lien et de nœud, sans toutefois exiger que l’opérateur procède à une configuration.
Figure 8
LFA-FRR est un mécanisme de protection locale pour le trafic en monodiffusion dans IP, MPLS, Ethernet sur MPLS (EoMPLS), le multiplexage inversé sur ATM (IMA) sur MPLS, le service d’émulation de circuit sur le réseau de commutation par paquets (CESoPSN) sur MPLS, et le multiplexage temporel (structure-agnostique) sur les réseaux MPLS. Toutefois, certaines topologies (comme celle en anneau) nécessitent une protection qui n’est pas garantie par la fonction LFA-FRR seule. La fonction LFA-FRR à distance se montre utile dans de telles situations.
Cette fonction prolonge le comportement de base de la version standard de LFA-FRR à n’importe quelle topologie. Elle achemine le trafic autour d’un nœud défaillant vers une fonction LFA qui se trouve à une distance de plus d’un saut. À la figure 9, si le lien entre C1 et C2 ne parvient pas à atteindre A1, donc C2 envoie le paquet sur une session LDP dirigée vers C5, qui offre l’accessibilité à A1.
Figure 9
Pour la fonction LFA-FRR à distance, un nœud calcule de façon dynamique son nœud LFA. Une fois que le nœud de rechange a été déterminé (lequel n’est pas connecté directement), le nœud établit automatiquement une session LDP (Label Distribution Protocol) vers ce nœud de rechange. La session LDP dirigée échange les étiquettes pour la correction d’erreur directe (FEC).
En cas de panne du lien, le nœud utilise l’empilage des étiquettes pour acheminer le trafic au nœud LFA distant et transférer ainsi le trafic vers la destination. Tous les échanges d’étiquettes et la tunnellisation vers le nœud LFA distant sont dynamiques, et le provisionnement n’est pas nécessaire. L’ensemble du mécanisme d’échange d’étiquettes et de tunnellisation est dynamique et ne comprend pas le provisionnement manuel.
Pour les LSP intradomaines, la fonction LFA FRR à distance est utilisée pour le trafic MPLS en monodiffusion dans les topologies en anneau. La fonction LFA FRR à distance calcule à l’avance un chemin de sauvegarde pour chaque préfixe de la table de routage IGP, permettant ainsi au nœud de passer rapidement au chemin de secours en cas de panne. Les délais de récupération sont alors de 50 ms.
Exemple d’architecture de Cisco Unified MPLS
Lorsque l’ensemble des fonctions et des outils précédents sont réunis dans un même environnement réseau, l’environnement réseau Cisco Unified MPLS est alors créé. Voici l’exemple d’architecture pour les grands fournisseurs de services.
Figure 10
- Le noyau et l’agrégation sont organisés en domaines IGP/LDP distincts.
- LSP hiérarchiques interdomaines basés sur RFC 3107, étiquettes BGP IPv4+ élargies à la préagrégation.
- LSP intradomaines basés sur LDP.
- Les LSP interdomaines du noyau et de l’agrégation se prolongent dans les réseaux d’accès grâce à la distribution du protocole de passerelle intérieure des réseaux d’accès radio (RAN IGP) dans l’iBGP interdomaine, tout en répartissant les préfixes iBGP étiquetés (passerelle MPC [Mobile Packet Core]) dans le protocole RAN IGP (par les communautés BGP).
Exemple de configuration Unified MPLS
Voici un exemple simplifié d’Unified MPLS.
Principal routeur de frontière de zone – Cisco IOS® XR
Préagrégation et routeurs de passerelle pour site cellulaire – Cisco IOS
Figure 11
| 200:200 | Communauté MPC |
| 300:300 | Communauté d’agrégation |
| Domaine IGP principal | ISIS de niveau 2 |
| Domaine d’IGP d’agrégation | ISIS de niveau 1 |
| Accès au domaine IGP | Zones OSPF 0 |
Configuration principale du routeur de frontière de zone
Figure 12
! IGP Configuration
router isis core-agg
net 49.0100.1010.0001.0001.00
address-family ipv4 unicast
metric-style wide
propagate level 1 into level 2 route-policy drop-all ! Disable L1 to L2 redistribution
!
interface Loopback0
ipv4 address 10.10.10.1 255.255.255.255
passive
!
interface TenGigE0/0/0/0
!
interface TenGigE0/0/0/1
circuit-type level-2-only ! Core facing ISIS L2 Link
!
interface TenGigE0/0/0/2
circuit-type level-1 ! Aggregation facingis ISIS L1 Link
!
route-policy drop-all
drop
end-policy
! BGP Configuration
router bgp 100
ibgp policy out enforce-modifications
bgp router-id 10.10.10.1
address-family ipv4 unicast
allocate-label all ! Send labels with BGP routes
!
session-group infra
remote-as 100
cluster-id 1001
update-source Loopback0
!
neighbor-group agg
use session-group infra
address-family ipv4 labeled-unicast
route-reflector-client
route-policy BGP_Egress_Filter out ! BGP Community based Egress filtering
next-hop-self
!
neighbor-group mpc
use session-group infra
address-family ipv4 labeled-unicast
route-reflector-client
next-hop-self
!
neighbor-group core
use session-group infra
address-family ipv4 labeled-unicast
next-hop-self
community-set Allowed-Comm
200:200,
300:300,
!
route-policy BGP_Egress_Filter
if community matches-any Allowed-Comm then
pass
Configuration de préagrégation
Figure 13
interface Loopback0
ipv4 address 10.10.9.9 255.255.255.255
!
interface Loopback1
ipv4 address 10.10.99.9 255.255.255.255
! Pre-Agg IGP Configuration
router isis core-agg
net 49.0100.1010.0001.9007.00
is-type level-1 ! ISIS L1 router
metric-style wide
passive-interface Loopback0 ! Core-agg IGP loopback0
!RAN Access IGP Configuration
router ospf 1
router-id 10.10.99.9
redistribute bgp 100 subnets route-map BGP_to_RAN ! iBGP to RAN IGP redistribution
network 10.9.9.2 0.0.0.1 area 0
network 10.9.9.4 0.0.0.1 area 0
network 10.10.99.9 0.0.0.0 area 0
distribute-list route-map Redist_from_BGP in ! Inbound filtering to prefer
labeled BGP learnt prefixes
ip community-list standard MPC_Comm permit 200:200
!
route-map BGP_to_RAN permit 10 ! Only redistribute prefixes
marked with MPC community
match community MPC_Comm
set tag 1000
route-map Redist_from_BGP deny 10
match tag 1000
!
route-map Redist_from_BGP permit 20
! BGP Configuration
router bgp 100
ibgp policy out enforce-modifications
bgp router-id 10.10.9.10
bgp cluster-id 909
neighbor csr peer-group
neighbor csr remote-as 100
neighbor csr update-source Loopback100 ! Cell Site - Routers RAN IGP
loopback100 as source
neighbor abr peer-group
neighbor abr remote-as 100
neighbor abr update-source Loopback0 ! Core POP ABRs - core-agg IGP
loopback0 as source
neighbor 10.10.10.1 peer-group abr
neighbor 10.10.10.2 peer-group abr
neighbor 10.10.13.1 peer-group csr
!
address-family ipv4
bgp redistribute-internal
network 10.10.9.10 mask 255.255.255.255 route-map AGG_Comm ! Advertise with
Aggregation Community (300:300)
redistribute ospf 1 ! Redistribute RAN IGP prefixes
neighbor abr send-community
neighbor abr next-hop-self
neighbor abr send-label ! Send labels with BGP routes
neighbor 10.10.10.1 activate
neighbor 10.10.10.2 activate
exit-address-family
!
route-map AGG_Comm permit 10
set community 300:300
Configuration de la passerelle pour site cellulaire (CSG)
Figure 14
interface Loopback0
ip address 10.10.13.2 255.255.255.255
! IGP Configuration
router ospf 1
router-id 10.10.13.2
network 10.9.10.0 0.0.0.1 area 0
network 10.13.0.0 0.0.255.255 area 0
network 10.10.13.3 0.0.0.0 area 0
Configuration MTG
Figure 15
Interface lookback0
ip address 10.10.11.1 255.255.255.255
! IGP Configuration
router isis core-agg
is-type level-2-only ! ISIS L2 router
net 49.0100.1010.0001.1001.00
address-family ipv4 unicast
metric-style wide
! BGP Configuration
router bgp 100
ibgp policy out enforce-modifications
bgp router-id 10.10.11.1
address-family ipv4 unicast
network 10.10.11.1/32 route-policy MPC_Comm ! Advertise Loopback-0 with MPC Community
allocate-label all ! Send labels with BGP routes
!
session-group infra
remote-as 100
update-source Loopback0
!
neighbor-group abr
use session-group infra
address-family ipv4 labeled-unicast
next-hop-self
!
neighbor 10.10.6.1
use neighbor-group abr
!
neighbor 10.10.12.1
use neighbor-group abr
community-set MPC_Comm
200:200
end-set
!
route-policy MPC_Comm
set community MPC_Comm
end-policy
Vérification
Le préfixe de bouclage de la passerelle MPG (Mobile Packet Gateway) est 10.10.11.1/32, et donc le préfixe devient intéressant. Jetez maintenant un œil à la façon dont les paquets sont transférés de CSG vers MPG.
Le routeur CSG connaît le préfixe MPC 10.10.11.1 de la préagrégation avec l’étiquette de routage 1000. Ce préfixe peut être transmis sous forme de paquet portant l’étiquette LDP sortante 31 (LDP LSP intradomaine). La communauté MPC 200:200 a été mise en correspondance avec la balise de routage 1000 dans le nœud de préagrégation, tandis que la redistribution est en OSPF.
Sortie de nœud CSG
CSG#sh mpls forwarding-table 10.10.11.1 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
34 31 10.10.11.1/32 0 Vl40 10.13.1.0
MAC/Encaps=14/18, MRU=1500, Label Stack{31}
Sorties de nœud de préagrégation
Dans le nœud de préagrégation, le préfixe MPC est redistribué de BGP au processus OSPF du RAN avec un filtre axé sur la communauté, et le processus OSPF est quant à lui redistribué dans le protocole BGP. Cette redistribution contrôlée est nécessaire pour établir l’accessibilité de l’IP de bout en bout; au même moment, chaque segment dispose d’un routage minimal requis.
Le préfixe 10.10.11.1/32 est connu grâce au protocole BGP hiérarchique 100, auquel est jointe la communauté MPC 200:200. L’étiquette 16020 BGP 3107 reçue du routeur ABR (Area Border Router) principal et l’étiquette LDP 22 sont ajoutées dans le haut aux fins de transfert intradomaine après la recherche récursive du saut suivant.
Pre-AGG1#sh ip route 10.10.11.1
Routing entry for 10.10.11.1/32
Known via "bgp 100", distance 200, metric 0, type internal
Redistributing via ospf 1
Advertised by ospf 1 subnets tag 1000 route-map BGP_TO_RAN
Routing Descriptor Blocks:
* 10.10.10.2, from 10.10.10.2, 1d17h ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: 16020
Pre-AGG1#sh bgp ipv4 unicast 10.10.11.1
BGP routing table entry for 10.10.11.1/32, version 116586
Paths: (2 available, best #2, table default)
Not advertised to any peer
Local
<SNIP>
Local
10.10.10.2 (metric 30) from 10.10.10.2 (10.10.10.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: 200:200
Originator: 10.10.11.1, Cluster list: 0.0.3.233, 0.0.2.89
mpls labels in/out nolabel/16020
Pre-AGG1#sh bgp ipv4 unicast labels
Network Next Hop In label/Out label
10.10.11.1/32 10.10.10.1 nolabel/16021
10.10.10.2 nolabel/16020
Pre-AGG1#sh mpls forwarding-table 10.10.10.2 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
79 22 10.10.10.2/32 76109369 Vl10 10.9.9.1
MAC/Encaps=14/18, MRU=1500, Label Stack{22}
Pre-AGG#sh mpls forwarding-table 10.10.11.1 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
530 16020 10.10.11.1/32 20924900800 Vl10 10.9.9.1
MAC/Encaps=14/22, MRU=1496, Label Stack{22 16020}
Principales sorties de nœud d’ABR
Le préfixe 10.10.11.1 est connu grâce à l’IGP intradomaine (ISIS-L2) et conformément au tableau de transfert MPLS. Celui-ci est accessible par LDP LSP.
ABR-Core2#sh ip route 10.10.11.1
Routing entry for 10.10.11.1/32
Known via "isis core-agg", distance 115, metric 20, type level-2
Installed Sep 12 21:13:03.673 for 2w3d
Routing Descriptor Blocks
10.10.1.0, from 10.10.11.1, via TenGigE0/0/0/0, Backup
Route metric is 0
10.10.2.3, from 10.10.11.1, via TenGigE0/0/0/3, Protected
Route metric is 20
No advertising protos.
Pour la distribution des préfixes entre les zones segmentées, le protocole BGP portant l’étiquette (RFC 3107) est utilisé. Il faut conserver dans les zones segmentées du protocole IGP les boucles avec retour des PE et les adresses liées à l’infrastructure centrale.
Les routeurs BGP qui relient les différentes zones sont les ABR qui agissent comme réflecteurs de routage BGP. Ces périphériques utilisent la commande Next-Hop-Self pour éviter de regrouper tous les sauts suivants du système autonome dans le protocole IGP, au lieu des adresses IP des PE et de l’infrastructure centrale. La détection des boucles a lieu selon les ID des grappes BGP.
Concernant la résilience du réseau, la BGP PIC dotée de la fonction BGP Add-Path doit être utilisé avec BGP, et LFA avec IGP. Ces fonctions ne sont pas illustrées dans l’exemple précédent.
Dépannage
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.
Commentaires