Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit l'objectif de la commutation multiprotocole par étiquette unifiée (MPLS) et fournit un exemple de configuration dans Cisco IOS® XR.
Aucune exigence spécifique n'est associée à ce document.
Ce document est spécifique à Cisco IOS XR, mais il n'est pas limité à une version logicielle ou matérielle spécifique.
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.
Le but du protocole Unified MPLS est d’évoluer. Afin de faire évoluer un réseau MPLS, où il existe différents types de plates-formes et de services dans des parties du réseau, il est logique de diviser le réseau en différentes zones. Une conception typique introduit une hiérarchie articulée autour d’une zone centrale, avec une zone d’agrégation sur le côté. Afin d'évoluer, il peut y avoir différents protocoles IGP (Interior Gateway Protocol) dans le coeur par rapport à l'agrégation. Afin d’évoluer, vous ne pouvez pas distribuer les préfixes IGP d’un IGP à l’autre. Si vous ne distribuez pas les préfixes IGP d’un IGP à l’autre, les chemins commutés par étiquette (LSP) de bout en bout sont impossibles.
Afin de fournir les services MPLS de bout en bout, vous devez disposer du LSP de bout en bout. 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.
Remarque : consultez Méthodes conseillées pour la recherche de commandes (clients enregistrés uniquement) afin d'obtenir plus d'informations sur la recherche de commandes.
La Figure 1 présente un réseau avec trois zones différentes : une zone principale et deux zones d'agrégation sur le côté. Chaque zone exécute son propre IGP, sans redistribution d’un à l’autre sur le routeur de frontière de zone (ABR). L’utilisation de BGP est nécessaire pour fournir un LSP MPLS de bout en bout. BGP annonce les boucles avec retour des routeurs PE avec une étiquette sur tout le domaine et fournit un LSP de bout en bout. BGP est déployé entre les PE et les ABR avec RFC 3107 (BGP Labeled Unicast), ce qui signifie que BGP envoie le préfixe et l'étiquette IPv4 (Address Family Identifier (AFI) 1 et Subsequent Address Family Identifier (SAFI) 4).
Figure 1
Comme la zone centrale et les zones d’agrégation du réseau sont intégrées et que des LSP de bout en bout sont fournis, la solution MPLS unifiée est également appelée « MPLS transparent ».
Les nouvelles technologies ou les nouveaux protocoles ne sont pas utilisés ici; seuls MPLS, LDP (Label Distribution Protocol), IGP et BGP le sont. Comme vous ne voulez pas distribuer entre deux parties du réseau les préfixes des boucles avec retour des routeurs PE, vous devez transporter les préfixes dans BGP. Le protocole iBGP (Internal Border Gateway Protocol) est utilisé dans un réseau, de sorte que l’adresse de saut suivant des préfixes correspond aux préfixes des boucles avec retour des routeurs PE, ce qu’IGP ne connaît pas dans les autres parties du réseau. Or, l’adresse de saut suivant ne peut pas être utilisée pour récupérer un préfixe IGP. L’astuce, c’est de faire sorte que les réflecteurs de routage des routeurs ABR définissent le saut suivant sur eux-mêmes, et c’est également le cas pour les préfixes iBGP réfléchis.
Seuls les RR ont besoin d'un logiciel pour prendre en charge cette architecture. Étant donné que les réflecteurs de routage annoncent les préfixes BGP avec le saut suivant défini sur eux-mêmes, ils attribuent une étiquette MPLS locale à ces préfixes. Ainsi, dans le plan de données, les paquets transférés sur ces LSP de bout en bout disposent d’une étiquette MPLS supplémentaire dans la pile d’étiquettes. Les réflecteurs de routage se trouvent sur le chemin de transmission.
Remarque : sur cette architecture, tout service MPLS est fourni. Par exemple, le service MPLS VPN ou MPLS L2VPN est fourni entre les routeurs PE. Dans le plan de données, la différence pour ces paquets, c’est qu’ils ont maintenant trois étiquettes dans la pile d’étiquettes, alors qu’ils en avaient seulement deux lorsque le protocole Unified MPLS n’était pas utilisé.
Deux scénarios sont possibles :
Dans les deux scénarios, l’ABR règle le saut suivant sur « self » pour les préfixes (reflétés par BGP) qu’annonce l’ABR à partir de la zone d’agrégation du réseau dans la zone centrale. Autrement, l’ABR doit redistribuer les préfixes des boucles avec retour des PE, de l’IGP d’agrégation vers l’IGP central. Or, si cela est fait, il n’y a pas d’évolutivité possible.
Différentes configurations peuvent être appliquées pour définir le saut suivant sur self pour les routes de monodiffusion étiquetées iBGP réfléchies sur les ABR.
Ces solutions ne fonctionnent pas pour activer la RFC 3107 dans Cisco IOS XR :
Exemple :
router bgp 1
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
next-hop-self
!
Exemple :
router bgp 1
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
route-policy nhs-ibgp-3107 out
!
route-policy nhs-ibgp-3107
set next-hop self
end-policy
Exemple :
router bgp 1
neighbor 10.100.1.1
address-family ipv4 labeled-unicast
route-policy nhs-ibgp-3107-peer out
!!% Could not find entry in list: Policy [nhs-ibgp-3107-peer]
uses 'set-to-peer-address next-hop'. 'set' is not a valid
operator for the 'next-hop' attribute at the bgp neighbor-out-dflt attach point.
!
!
!
route-policy nhs-ibgp-3107-peer
set next-hop peer-address
end-policy
Exemple :
router bgp 1
ibgp policy out enforce-modifications
!
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
route-policy nhs-ibgp-3107 out
!
!
route-policy nhs-ibgp-3107-peer
set next-hop 10.100.1.3
end-policy
Ces solutions fonctionnent.
Assurez-vous que la stratégie ibgp est appliquée aux modifications !
Exemple :
router bgp 1
ibgp policy out enforce-modifications
!
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
next-hop-self
!
!
Exemple :
router bgp 1
ibgp policy out enforce-modifications
!
neighbor 1.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
route-policy nhs-ibgp-3107 out
!
!
route-policy nhs-ibgp-3107
set next-hop self
end-policy
Exemple :
router bgp 1
ibgp policy out enforce-modifications
!
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
route-policy nhs-ibgp-3107 out
next-hop-self
!
!
!
route-policy nhs-ibgp-3107
set next-hop self
end-policy
Exemple :
router bgp 1
ibgp policy out enforce-modifications
!
neighbor 10.100.1.1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
route-policy nhs-ibgp-3107 out
next-hop-self
!
!
!
route-policy nhs-ibgp-3107
set next-hop 10.100.1.3
end-policy
hostname PE1
!
vrf one <<< MPLS service is MPLS VPN
address-family ipv4 unicast
import route-target
1:1
!
export route-target
1:1
!
!
address-family ipv6 unicast
import route-target
1:1
!
export route-target
1:1
!
!
interface Loopback0
ipv4 address 10.100.1.1 255.255.255.255
!
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.1.1.1 255.255.255.0
!
!
interface GigabitEthernet0/0/0/1 <<< VRF interface to CE1
vrf one
ipv4 address 10.9.1.3 255.255.255.0
!
!
router ospf 1
router-id 10.100.1.1
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
!
router bgp 1
address-family ipv4 unicast
network 10.100.1.1/32 <<< advertise PE loopback in BGP
allocate-label all
!
address-family vpnv4 unicast
!
neighbor 10.100.1.3
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
!
!
neighbor 10.100.1.7 <<< vpnv4 iBGP session to PE2
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
!
!
vrf one
rd 1:1
address-family ipv4 unicast
!
neighbor 10.9.1.2 <<< eBGP session to CE1
remote-as 65001
address-family ipv4 unicast
route-policy pass in
route-policy pass out
!
!
!
!
mpls ldp
mldp
logging notifications
address-family ipv4
!
!
router-id 10.100.1.1
address-family ipv4
!
interface GigabitEthernet0/0/0/0
address-family ipv4
!
!
!
hostname ABR1
!
interface Loopback0
ipv4 address 10.100.1.3 255.255.255.255
!
!
interface GigabitEthernet0/0/0/0
ipv4 address 10.1.3.3 255.255.255.0
!
interface GigabitEthernet0/0/0/1
ipv4 address 10.1.2.3 255.255.255.0
!
route-policy nhs-ibgp-3107
set next-hop 10.100.1.3 <<< set next hop to loopback
end-policy
!
route-policy connected-into-ospf2
if destination in (10.100.1.3/32) then
pass
endif
end-policy
!
router ospf 1
router-id 10.100.1.3
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/1
network point-to-point
!
!
!
router ospf 2
redistribute connected route-policy connected-into-ospf2
area 0
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
!
router bgp 1
ibgp policy out enforce-modifications
address-family ipv4 unicast
allocate-label all
!
neighbor 10.100.1.1 <<< iBGP neighbor PE1
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-reflector-client
route-policy nhs-ibgp-3107 out
next-hop-self
!
!
neighbor 10.100.1.5 <<< iBGP neighbor ABR2
remote-as 1
update-source Loopback0
address-family ipv4 labeled-unicast
route-policy nhs-ibgp-3107 out
next-hop-self
!
!
!
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
interface GigabitEthernet0/0/0/0
address-family ipv4
discovery transport-address interface
!
!
interface GigabitEthernet0/0/0/1
address-family ipv4
!
!
Remarque : allocate-label all ou allocate-label route-policy est nécessaire. Sinon, les routes de monodiffusion étiquetées n'ont pas d'étiquette locale dont elles ont besoin puisque l'ABR est le saut suivant pour les routes reflétées iBGP.
Remarque : la redistribution de l'IGP principal (OSPF 2) dans l'IGP d'agrégation (OSPF 1 ou OSPF 3) ou vice-versa n'est pas effectuée. Cependant, le préfixe de bouclage du RR doit également être connu dans le protocole IGP d'agrégation, de sorte que BGP sur le routeur PE puisse s'appairer avec le bouclage de l'ABR/RR. Pour cela, la redistribution des routes connectées dans l'agrégation IGP est effectuée avec RPL. Les routes connectées redistribuées sont limitées au préfixe de bouclage de l'ABR avec RPL.
Voir la figure 2 pour vérifier le fonctionnement du plan de contrôle:
Figure 2
Voir la figure 3 pour vérifier les annonces des étiquettes MPLS:
Figure 3
Voir la figure 4 pour vérifier le transfert des paquets:
Figure 4
Voici comment les paquets sont transférés de PE1 à PE2. Le préfixe des boucles avec retour de PE2 est 10.100.1.7/32, et donc le préfixe devient intéressant.
RP/0/0/CPU0:PE1#traceroute
Protocol [ipv4]:
Target IP address: 10.100.1.7
Source address: 10.100.1.1
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.100.1.7
1 10.1.1.2 [MPLS: Labels 24000/24005 Exp 0] 439 msec 119 msec 109 msec
2 10.1.2.3 [MPLS: Label 24005 Exp 0] 109 msec 109 msec 109 msec
3 10.1.3.4 [MPLS: Labels 24001/24003 Exp 0] 99 msec 99 msec 149 msec
4 10.1.4.5 [MPLS: Label 24003 Exp 0] 119 msec 119 msec 99 msec
5 10.1.5.6 [MPLS: Label 24001 Exp 0] 109 msec 139 msec 99 msec
6 10.1.6.7 109 msec * 109 msec
L’étiquette 24000 est l’étiquette LDP apprise de P2 pour le préfixe 10.100.1.3/32. L'étiquette 24005 est l'étiquette BGP RFC 3107 apprise pour le préfixe 10.100.1.7/32.
RP/0/0/CPU0:PE1#show route 10.100.1.7/32
Routing entry for 10.100.1.7/32
Known via "bgp 1", distance 200, metric 0, [ei]-bgp, type internal
BIER rid=0x0, flags=0x0, count=0
Installed May 27 02:52:07.184 for 00:08:52
Routing Descriptor Blocks
10.100.1.3, from 10.100.1.3 <<< next-hop is ABR1
Route metric is 0
No advertising protos.
RP/0/0/CPU0:PE1#show cef 10.100.1.7/32
10.100.1.7/32, version 89, internal 0x1000001 0x0 (ptr 0xa1470f74)
[1], 0x0 (0xa1456614), 0xa08 (0xa16181e0)
Updated May 27 02:52:07.203
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.100.1.3, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa16806f4 0x0]
recursion-via-/32
next hop 10.100.1.3 via 24001/0/21
local label 24003
next hop 10.1.1.2/32 Gi0/0/0/0 labels imposed {24000 24005}
RP/0/0/CPU0:PE1#show bgp ipv4 unicast labels
BGP router identifier 10.100.1.1, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 44
BGP main routing table version 44
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
*> 10.100.1.1/32 0.0.0.0 nolabel 3
*>i10.100.1.7/32 10.100.1.3 24005 24003
Processed 2 prefixes, 2 paths
Il y a l'avant-dernier saut (PHP) vers ABR1.
RP/0/0/CPU0:P2#show mpls forwarding labels 24000
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24000 Pop 10.100.1.3/32 Gi0/0/0/1 10.1.2.3 694765
L'étiquette 24005 est remplacée par l'étiquette 24003 sur ABR1.
RP/0/0/CPU0:ABR1#show bgp ipv4 unicast labels
BGP router identifier 10.100.1.3, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 60
BGP main routing table version 60
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
*>i10.100.1.1/32 10.100.1.1 3 24003
*>i10.100.1.7/32 10.100.1.5 24003 24005
Processed 2 prefixes, 2 paths
RP/0/0/CPU0:ABR1#show mpls forwarding labels 24005
Wed May 27 04:08:24.255 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24005 24003 10.100.1.7/32 10.100.1.5 6347
Il y a PHP de P1 à ABR2.
RP/0/0/CPU0:P1#show mpls forwarding labels 24001
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24001 Pop 10.100.1.5/32 Gi0/0/0/1 10.1.4.5 348835
L'étiquette BGP pour la route 10.100.1.7/32 RFC 3107 reçue par ABR2 de PE2 est 3. Il s'agit de l'étiquette null implicite qui indique PHP.
RP/0/0/CPU0:ABR2#show bgp ipv4 unicast labels
BGP router identifier 10.100.1.5, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 47
BGP main routing table version 47
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
*>i10.100.1.1/32 10.100.1.3 24003 24005
*>i10.100.1.7/32 10.100.1.7 3 24003
Processed 2 prefixes, 2 paths
Le libellé 24003 est remplacé par le libellé 24001 sur ABR2.
RP/0/0/CPU0:ABR2#show mpls forwarding labels 24003
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24003 24001 10.100.1.7/32 Gi0/0/0/0 10.1.5.6 403676
Il y a PHP de P3 à PE2.
RP/0/0/CPU0:P3#show mpls forwarding labels 24001
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24001 Pop 10.100.1.7/32 Gi0/0/0/1 10.1.6.7 685191
RP/0/0/CPU0:PE2#show bgp ipv4 unicast labels
BGP router identifier 10.100.1.7, local AS number 1
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 42
BGP main routing table version 42
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
*>i10.100.1.1/32 10.100.1.5 24005 24004
*> 10.100.1.7/32 0.0.0.0 nolabel 3
Processed 2 prefixes, 2 paths
Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
31-Jul-2015 |
Première publication |