Cisco IOS-XR BGP avec conceptions MPLS
Contenu
Introduction
Ce document décrit quelques scénarios qui ont un comportement et une configuration spéciaux pour la combinaison de la commutation multiprotocole par étiquette (MPLS) et du protocole BGP (Border Gateway Protocol) dans Cisco IOS®-XR.
1. Une route statique est nécessaire pour les options VPN MPLS inter-AS B & C
Cette image montre une configuration de l'option B Inter-AS.
Image 1.
Le routeur PE (Provider Edge) PE1 dispose d'une route pour le préfixe VRF 10.200.1.2/32, mais elle n'est pas résolue.
RP/0/0/CPU0:PE1#show cef vrf one 10.200.1.2
10.200.1.2/32, version 3, internal 0x5000001 0x0 (ptr 0xa140be74) [1], 0x0 (0x0), 0x208 (0xa14a7118)
Updated Apr 7 14:36:45.628
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.3.1.4/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0d87468 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
unresolved
labels imposed {24004}
PE1 n’a pas de route pour 10.3.1.4/32. Il possède une route pour 10.3.1.0/24.
RP/0/0/CPU0:PE1#show route 10.3.1.4
Routing entry for 10.3.1.0/24
Known via "ospf 1", distance 110, metric 3, type intra area
Installed Apr 7 14:07:01.140 for 00:32:48
Routing Descriptor Blocks
10.1.1.2, from 10.100.1.3, via GigabitEthernet0/0/0/0
Route metric is 3
No advertising protos.
Il doit y avoir une route statique sur la route ASBR (Autonomous System Border Route) pour le tronçon suivant. Vous devez configurer cette route statique sur chaque ASBR et la redistribuer dans le protocole IGP (Interior Gateway Protocol).
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
!
!
router ospf 1
redistribute static
La route est maintenant résolue.
RP/0/0/CPU0:PE1#show cef vrf one 10.200.1.2
10.200.1.2/32, version 3, internal 0x5000001 0x0 (ptr 0xa140be74) [1], 0x0 (0x0), 0x208 (0xa14a7118)
Updated Apr 7 14:36:45.628
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.3.1.4/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa150f9f4 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
next hop 10.3.1.4/32 via 24005/0/21
next hop 10.1.1.2/32 Gi0/0/0/0 labels imposed {24003 24004}
ASBR1 installe une étiquette sortante de POP vers ASBR2 pour les préfixes VPNv4/6 :
RP/0/0/CPU0:ASBR1#show mpls forwarding prefix 10.3.1.4/32
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24005 Pop 10.3.1.4/32 Gi0/0/0/1 10.3.1.4 2506
Même avec le saut suivant sur l'ASBR vers les voisins iBGP, le transfert d'étiquette entre les ASBR sera interrompu, si la route statique n'est pas configurée sur l'ASBR.
Avec le saut suivant sur ASBR1 vers PE1 et sans route statique :
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24006 detail
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24006 24004 2:2:10.200.1.2/32 10.3.1.4 0
Updated: Apr 7 14:49:58.190
Path Flags: 0x6000 [ ]
Label Stack (Top -> Bottom): { }
MAC/Encaps: 0/0, MTU: 0
Packets Switched: 0
Notez que l'interface sortante est manquante dans la colonne Interface sortante. La route statique est nécessaire sur les ASBR pour les options inter-AS B et C.
2. Conserver les cibles de routage sur les ASBR pour l'option B inter-AS
Une commande est nécessaire pour s'assurer que l'ASBR stocke/conserve les routes vpnv4/6, puis les annonce. Sans cette commande, l'ASBR ne stocke pas les routes s'il n'y a aucun VRF local configuré sur l'ASBR qui importe l'une des cibles de route des routes, ou s'il ne s'agit pas d'un réflecteur de route (RR) pour la famille d'adresses vpnv4/6.
router bgp 1
address-family ipv4 unicast
!
address-family vpnv4 unicast
retain route-target all
!
3. Les adresses de monodiffusion étiquetées IPv4 ne sont pas annoncées par ASBR
La monodiffusion étiquetée IPv4 est nécessaire dans les réseaux Inter-AS Option C ou MPLS transparente (Unified MPLS). En effet, les préfixes vpnv4/6 sont étiquetés par défaut, mais ce n'est pas le cas pour la monodiffusion IPv4 (IPv6). Si ce n'est pas le cas, le chemin LSP (Label Switched Path) de bout en bout est interrompu et le flux de trafic de bout en bout échoue.
Regardez l'image 2, elle montre une configuration de l'option C inter-AS.
Image 2.
Les routeurs P1 et P2 sont également les réflecteurs de route de leur système autonome (AS) pour vpnv4.
L'unité de monodiffusion étiquetée (LU) est utilisée pour transporter les préfixes de bouclage d'un système autonome vers l'autre.
Cette famille d’adresses est configurée pour ASBR1, mais il n’y a aucune route dedans :
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast
RP/0/0/CPU0:ASBR1#
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast summary
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: 41
BGP main routing table version 41
BGP NSR Initial initsync version 2 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 41 41 41 41 41 0
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.3.1.4 0 2 150 151 41 0 0 00:06:29 0
10.100.1.2 0 1 52 52 41 0 0 00:06:42 0
La raison est que l'ASBR doit avoir la commande suivante pour pouvoir allouer une étiquette MPLS (Multi-Protocol Label Switching) pour chaque route, puis annoncer les routes.
RP/0/0/CPU0:ASBR1#show run router bgp
router bgp 1
address-family ipv4 unicast
redistribute ospf 1
allocate-label all
!
Le résultat de cette commande est :
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast
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: 52
BGP main routing table version 52
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 Metric LocPrf Weight Path
*> 10.1.1.0/24 10.1.2.2 2 32768 ?
*> 10.1.2.0/24 0.0.0.0 0 32768 ?
*> 10.2.1.0/24 10.3.1.4 0 0 2 ?
*> 10.2.2.0/24 10.3.1.4 2 0 2 ?
*> 10.3.1.0/24 0.0.0.0 0 32768 ?
* 10.3.1.4 0 0 2 ?
*> 10.100.1.1/32 10.1.2.2 3 32768 ?
*> 10.100.1.2/32 10.1.2.2 2 32768 ?
*> 10.100.1.3/32 0.0.0.0 0 32768 ?
*> 10.100.1.4/32 10.3.1.4 0 0 2 ?
*> 10.100.1.5/32 10.3.1.4 2 0 2 ?
*> 10.100.1.6/32 10.3.1.4 3 0 2 ?
Processed 11 prefixes, 12 paths
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.6/32
BGP routing table entry for 10.100.1.6/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 48 48
Local Label: 24008
Last Modified: Apr 7 16:20:04.509 for 00:00:49
Paths: (1 available, best #1)
Advertised to peers (in unique update groups):
10.100.1.2
Path #1: Received by speaker 0
Advertised to peers (in unique update groups):
10.100.1.2
2
10.3.1.4 from 10.3.1.4 (10.100.1.4)
Received Label 24002
Origin incomplete, metric 3, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 48
Origin-AS validity: not-found
Bref :
- L'allocation d'étiquette doit être configurée (sur tous les routeurs ASBR et PE)
- La famille d'adresses ipv4 labellisée-unicast doit être configurée pour le voisin BGP
4. Un voisin iBGP factice est nécessaire pour eBGP-eBGP (eBGP dos à dos) Vpnv4
Regardez l'image 3.
Image 3.
Il y a trois ASBR dans une ligne. L'ASBR3 exécute la monodiffusion vpnv4 eBGP sur ASBR1 et ASBR2.
RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast
BGP router identifier 10.100.1.7, local AS number 3
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0x0 RD version: 0
BGP main routing table version 3
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 Metric LocPrf Weight Path
Route Distinguisher: 1:1
*> 10.200.1.1/32 10.4.1.3 0 1 ?
Route Distinguisher: 2:2
*> 10.200.1.2/32 10.4.2.4 0 2 ?
Processed 2 prefixes, 2 paths
RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast rd 1:1 10.200.1.1/32
BGP routing table entry for 10.200.1.1/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 2 2
Last Modified: Apr 7 18:45:21.510 for 00:03:30
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
1
10.4.1.3 from 10.4.1.3 (10.100.1.3)
Received Label 24009
Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf
Received Path ID 0, Local Path ID 1, version 2
Extended community: RT:1:1
Il y a un problème avec l'annonce des routes vpnv4 à partir d'ASBR3 : ASBR3 n'annonce pas les routes vpnv4 externes sortantes.
La solution consiste à configurer un voisin iBGP factice sur ASBR3 et à activer le saut suivant : Le voisin iBGP factice n'a pas besoin d'être actif.
router bgp 3
address-family vpnv4 unicast
retain route-target all
!
neighbor 10.4.1.3
remote-as 1 address-family vpnv4 unicast
route-policy PASS in
route-policy PASS out
!
!
neighbor 10.4.2.4
remote-as 2
address-family vpnv4 unicast
route-policy PASS in
route-policy PASS out
!
!
neighbor 10.99.99.99
remote-as 3
description dummy-iBGP neighbor for back-to-back eBGP vpnv4
update-source Loopback0
address-family vpnv4 unicast
next-hop-self
!
!
!
Résultat : la route vpnv4 est maintenant annoncée :
RP/0/0/CPU0:ASBR3#show bgp vpnv4 unicast rd 1:1 10.200.1.1/32
BGP routing table entry for 10.200.1.1/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 12 12
Local Label: 24002
Last Modified: Apr 7 18:58:04.510 for 00:01:46
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.2
1
10.4.1.3 from 10.4.1.3 (10.100.1.3)
Received Label 24009
Origin incomplete, localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf
Received Path ID 0, Local Path ID 1, version 12
Extended community: RT:1:1
5. Option C inter-AS : l'étiquette BGP est préférée à l'étiquette LDP
Reportez-vous à cette image afin de voir une configuration avec les deux ASBR connectés sur plusieurs liaisons. Pour que cela fonctionne, la session eBGP ipv4 LU entre les ASBR doit être multi-sauts car il existe des liens parallèles entre eux.
Image 4.
Il s’agit de l’option inter-AS C. Les routeurs P1 et P2 sont également les réflecteurs de route pour vpnv4.
Il existe une étiquette de monodiffusion IPv4 entre les routeurs PE et les routeurs ASBR. Les routeurs ASBR sont directement connectés via plusieurs liaisons.
Sur l'ASBR, vous voyez :
router bgp 1
…
neighbor 10.100.1.4
remote-as 2
ebgp-multihop 2
update-source Loopback0
address-family ipv4 labeled-unicast
route-policy PASS in
route-policy PASS out
Aucun protocole LDP (Label Distribution Protocol) n'est nécessaire entre les routeurs ASBR. BGP s'occupe du transfert MPLS sur les liaisons entre les ASBR.
RP/0/0/CPU0:ASBR1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
GigabitEthernet0/0/0/1 No No No Yes
GigabitEthernet0/0/0/2 No No No Yes
GigabitEthernet0/0/0/3 No No No Yes
GigabitEthernet0/0/0/4 No No No Yes
Jusqu'à présent. Le problème est lié au scénario illustré dans cette image.
Image 5.
Il s’agit de l’option inter-AS C. Les routeurs P1 et P2 sont également les réflecteurs de route pour vpnv4.
Il existe une étiquette de monodiffusion IPv4 entre les routeurs PE et les routeurs ASBR. ASBR1 et ASBR2 ne sont pas directement connectés. Ils sont connectés à plusieurs sauts, via un réseau exécutant un protocole IGP et un protocole LDP. Dans l'image 5, ce réseau intermédiaire est représenté par le routeur ASBR3, qui exécute un protocole IGP et LDP avec ASBR1 et ASBR2.
Avec le saut multiple eBGP sur les ASBR, il y a un problème. La session BGP entre les RR de chaque AS n'apparaît même pas.
RP/0/0/CPU0:P1#show cef 10.100.1.5
10.100.1.5/32, version 263, internal 0x1000001 0x0 (ptr 0xa13bde74) [1], 0x0 (0xa1389560), 0xa28 (0xa14a72a8)
Updated Apr 8 09:38:02.551
local adjacency 10.1.2.3
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.1.2.3/32, GigabitEthernet0/0/0/1, 5 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0e8b2a4 0x0]
next hop 10.1.2.3/32
local adjacency
local label 24004 labels imposed {24007}
Pour passer de P1, RR dans AS 1, à P2, RR dans AS 2, l'étiquette sortante est 24007. Sur ASBR1, cette étiquette est remplacée par l'étiquette 24000.
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24007
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24007 24000 10.100.1.5/32 10.100.1.4 1404
RP/0/0/CPU0:ASBR1#show cef 10.100.1.5
10.100.1.5/32, version 155, internal 0x5000001 0x0 (ptr 0xa13be174) [1], 0x0 (0xa138965c), 0xa08 (0xa14a72d0)
Updated Apr 8 10:02:38.101
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.100.1.4/32, 5 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa150f874 0x0]
recursion-via-/32
next hop 10.100.1.4/32 via 24004/0/21
local label 24007
next hop 10.4.1.7/32 Gi0/0/0/4 labels imposed {ImplNull 24000}
L'étiquette 24000 est l'étiquette reçue sur ASBR1 par la LU BGP d'ASBR2.
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.5
BGP routing table entry for 10.100.1.5/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 76 76
Local Label: 24007
Last Modified: Apr 8 09:37:57.509 for 00:04:05
Paths: (1 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.1 10.100.1.2
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.1 10.100.1.2
2
10.100.1.4 from 10.100.1.4 (10.100.1.4)
Received Label 24000
Origin incomplete, metric 2, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 76
Origin-AS validity: not-found
Cependant, le routeur ASBR entre les deux n'exécute pas BGP et ne peut donc pas transférer les paquets qu'il reçoit avec cette étiquette, car il n'a pas affecté l'étiquette 24000. L'étiquette qui doit être utilisée pour acheminer les paquets vers 10.100.1.5 est l'étiquette du protocole LDP :
RP/0/0/CPU0:ASBR1#show route 10.100.1.5/32
Routing entry for 10.100.1.5/32
Known via "bgp 1", distance 20, metric 2, [ei]-bgp, labeled unicast (3107)
Tag 2, type external
Installed Apr 8 10:02:38.082 for 01:24:37
Routing Descriptor Blocks
10.100.1.4, from 10.100.1.4, BGP external
Route metric is 2
No advertising protos.
Cela se produit au prochain saut 10.100.1.4, le bouclage d'ASBR2.
L’étiquette reçue d’ASBR3 par le protocole LDP doit être utilisée, mais ce n’est pas le cas.
La pile d'étiquettes ajoutée est {ImplNull 24000} au lieu de {24002 24000}.
RP/0/0/CPU0:ASBR1#show mpls ldp bindings 10.100.1.4/32
10.100.1.4/32, rev 146
Local binding: label: 24004
Remote bindings: (2 peers)
Peer Label
----------------- ---------
10.100.1.2:0 24003
10.100.1.7:0 24002
ASBR1 doit imposer l’étiquette LDP 24002 reçue du routeur ASBR3. Afin de désactiver le transfert MPLS BGP, vous ajoutez le mot clé mpls à la commande eBGP multi-hop.
ASBR1 :
router bgp 1
…
neighbor 10.100.1.4
remote-as 2
ebgp-multihop 2 mpls
update-source Loopback0
address-family ipv4 labeled-unicast
route-policy PASS in
route-policy PASS out
!
ASBR1 a maintenant la réécriture d'étiquette correcte :
RP/0/0/CPU0:ASBR1#show cef 10.100.1.5
10.100.1.5/32, version 155, internal 0x5000001 0x0 (ptr 0xa13be174) [1], 0x0 (0xa138965c), 0xa08 (0xa14a72d0)
Updated Apr 8 10:02:38.102
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.100.1.4/32, 5 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa150f874 0x0]
recursion-via-/32
next hop 10.100.1.4/32 via 24004/0/21
local label 24007
next hop 10.4.1.7/32 Gi0/0/0/4 labels imposed {24002 24000}
À partir de la référence de commande :
L'utilisation de l'option mpls dans la commande ebgp-multihop empêche BGP d'activer MPLS sur l'interface d'appairage et empêche également l'allocation d'étiquettes de réécriture Implicit-NULL pour les adresses de tronçon suivant apprises de l'homologue. Ceci est utile dans certains scénarios dans lesquels des étiquettes de transfert MPLS vers les commutateurs voisins ont déjà été apprises via BGP étiqueté monodiffusion ou LDP.
En d'autres termes, dans IOS-XR, lorsque BGP propose d'allouer une étiquette à la LFIB, elle aura préséance sur le protocole LDP. Le scénario de l'option C Inter-AS avec plusieurs sauts entre les routeurs ASBR est un tel scénario.
6. Option inter-AS B : l'étiquette BGP est préférée à l'étiquette LDP
Image 6.
Il s'agit de l'option inter-AS B. Cependant, il existe plusieurs liaisons parallèles entre les deux ASBR. Il existe un RFC3107 (échange de routes IPv4 et d'étiquettes MPLS) entre les ASBR, au lieu d'utiliser un protocole IGP et LDP.
Afin d'activer la session à sauts multiples eBGP entre les interfaces de bouclage d'ASBR1 et d'ASBR2, la LU eBGP est nécessaire entre les deux ASBR. Il existe deux liaisons entre les ASBR, de sorte que deux sessions LU eBGP sont nécessaires. La commande allolabel est nécessaire pour la famille d'adresses IPv4.
router bgp 65001
address-family ipv4 unicast
network 10.100.1.3/32
allocate-label all
!
neighbor 10.3.1.4
remote-as 65002
address-family ipv4 labeled-unicast
route-policy pass in
route-policy pass out
!
!
neighbor 10.3.2.4
remote-as 65002
address-family ipv4 labeled-unicast
route-policy pass in
route-policy pass out
!
!
Les routes statiques de la section 1 sont toujours nécessaires :
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
10.3.2.4/32 GigabitEthernet0/0/0/2
!
!
La session vpnv4 eBGP entre les routeurs ASBR :
router bgp 65001
address-family ipv4 unicast
network 10.100.1.3/32
allocate-label all
!
address-family vpnv4 unicast
retain route-target all
!
neighbor 10.100.1.4
remote-as 65002
ebgp-multihop 255
update-source Loopback0
address-family vpnv4 unicast
route-policy pass in
route-policy pass out
!
!
Notez que le mot clé mpls n'est pas nécessaire ici, comme dans la section 5. En outre, les sessions LU iBGP entre PE et ASBR ne sont pas nécessaires si le saut suivant auto est configuré pour les sessions vpnv4 iBGP. L'étiquette annoncée par ASBR2 pour 10.100.1.4/32 est l'étiquette 3 :
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.4/32
Fri Jun 2 11:50:16.178 UTC
BGP routing table entry for 10.100.1.4/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 8 8
Local Label: 24005
Last Modified: Jun 2 11:48:39.920 for 00:01:36
Paths: (4 available, best #1)
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
Path #1: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
65002
10.3.1.4 from 10.3.1.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 8
Origin-AS validity: not-found
Path #2: Received by speaker 0
Not advertised to any peer
65002
10.3.2.4 from 10.3.2.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #3: Received by speaker 0
Not advertised to any peer
65003 65002
10.3.3.9 from 10.3.3.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, valid, external, group-best
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #4: Received by speaker 0
Not advertised to any peer
65003 65002
10.3.4.9 from 10.3.4.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Fri Jun 2 11:51:06.994 UTC
10.100.1.4/32, version 254, internal 0x1000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13896ec), 0xa20 (0xa14a70f0)
Updated Jun 2 11:48:39.634
local adjacency 10.3.1.4
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.3.1.4/32, GigabitEthernet0/0/0/1, 5 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0e8b1fc 0xa0e8b34c]
next hop 10.3.1.4/32
local adjacency
local label 24005 labels imposed {ImplNull}
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24005
Fri Jun 2 11:51:20.204 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24005 Pop 10.100.1.4/32 Gi0/0/0/1 10.3.1.4 610
Lorsqu'il existe un autre chemin entre les ASBR et que ce chemin utilise IGP + LDP ou MPLS TE, le mot clé mpls est nécessaire pour la commande eBGP multihop.
Image 7.
Une stratégie de route BGP sur ASBR1 vers P3 est utilisée pour définir le poids très élevé de sorte que les préfixes de P3 soient préférés à ceux d'ASBR2 directement.
RP/0/0/CPU0:ASBR1#show bgp ipv4 labeled-unicast 10.100.1.4/32
Fri Jun 2 11:57:23.789 UTC
BGP routing table entry for 10.100.1.4/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 9 9
Local Label: 24005
Last Modified: Jun 2 11:51:58.920 for 00:05:24
Paths: (4 available, best #3)
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
Path #1: Received by speaker 0
Not advertised to any peer
65002
10.3.1.4 from 10.3.1.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external, group-best
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #2: Received by speaker 0
Not advertised to any peer
65002
10.3.2.4 from 10.3.2.4 (10.100.1.4)
Received Label 3
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
Path #3: Received by speaker 0
Advertised to update-groups (with more than one peer):
0.3
Advertised to peers (in unique update groups):
10.100.1.7
65003 65002
10.3.3.9 from 10.3.3.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, weight 65535, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 9
Origin-AS validity: not-found
Path #4: Received by speaker 0
Not advertised to any peer
65003 65002
10.3.4.9 from 10.3.4.9 (10.100.1.9)
Received Label 24001
Origin IGP, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: not-found
ASBR1 doit maintenant utiliser l'étiquette 24001 comme étiquette sortante pour 10.100.1.4/32. Il ne s'agit pas :
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Fri Jun 2 11:59:46.519 UTC
10.100.1.4/32, version 255, internal 0x1000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13896ec), 0xa20 (0xa14a7140)
Updated Jun 2 11:51:58.741
local adjacency 10.3.3.9
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.3.3.9/32, GigabitEthernet0/0/0/3, 7 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa0e8b544 0xa0e8b5ec]
next hop 10.3.3.9/32
local adjacency
local label 24005 labels imposed {ImplNull}
La solution est la même que dans la section 5 : utilisez le mot clé mpls pour la commande eBGP multihop.
RP/0/0/CPU0:ASBR1# conf t
Fri Jun 2 13:56:45.618 UTC
RP/0/0/CPU0:ASBR1(config)#router bgp 65001
RP/0/0/CPU0:ASBR1(config-bgp)# neighbor 10.100.1.4
RP/0/0/CPU0:ASBR1(config-bgp-nbr)#ebgp-multihop 255 mpls
RP/0/0/CPU0:ASBR1(config-bgp-nbr)#commit
ASBR1 utilise désormais l'étiquette 24001 comme étiquette sortante pour 10.100.1.4/32.
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Fri Jun 2 13:58:13.402 UTC
10.100.1.4/32, version 200, internal 0x5000001 0x0 (ptr 0xa13be474) [1], 0x0 (0xa13895cc), 0xa08 (0xa14a71b8)
Updated Jun 2 13:56:59.378
Prefix Len 32, traffic index 0, precedence n/a, priority 15
via 10.3.3.9/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa15102f4 0x0]
recursion-via-/32
next hop 10.3.3.9/32 via 24014/0/21
local label 24005
next hop 10.3.3.9/32 Gi0/0/0/3 labels imposed {ImplNull 24001}
ASBR1 pousse cette étiquette supplémentaire. Une commande traceroute dans le VRF (Virtual Routing and Forwarding) de PE1 à PE2 affiche les étiquettes supplémentaires poussées.
RP/0/0/CPU0:PE1#trace vrf one 10.99.1.2
Fri Jun 2 13:49:38.959 UTC
Type escape sequence to abort.
Tracing the route to 10.99.1.2
1 10.1.1.5 [MPLS: Labels 24002/24012 Exp 0] 29 msec 39 msec 39 msec
2 10.1.2.3 [MPLS: Label 24012 Exp 0] 29 msec 29 msec 39 msec
3 10.3.1.4 [MPLS: Label 24007 Exp 0] 39 msec 39 msec 39 msec
4 10.2.1.6 [MPLS: Labels 24001/24005 Exp 0] 39 msec 39 msec 29 msec
5 10.2.2.2 39 msec * 239 msec
IGP et LDP ont été utilisés entre ASBR1 et P3 et ASBR2 et P3. Le même problème et la même solution sont présents lorsque l'ingénierie de trafic MPLS (TE) est utilisée entre ces routeurs.
Il n'y a pas de LDP entre ASBR1 et P3, mais il y a MPLS TE.
Sans le mot clé mpls sur la commande eBGP multihop, le même problème est de retour :
Les paquets transférés vers 10.100.1.4 n'obtiennent pas l'étiquette LU BGP 24000 poussée.
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Tue Jun 6 10:36:56.528 UTC
10.100.1.4/32, version 50, internal 0x1000001 0x0 (ptr 0xa12cc1fc) [1], 0x0 (0xa12b18c0), 0xa20 (0xa14a7258)
Updated Jun 6 10:36:32.930
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.3.3.9/32, tunnel-te1, 7 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa15d58f8 0xa15d5840]
next hop 10.3.3.9/32
local adjacency
local label 24012 labels imposed {ImplNull}
Alors qu'avec le mot clé mpls, l'étiquette 24000 est présente :
RP/0/0/CPU0:ASBR1#show cef 10.100.1.4
Tue Jun 6 10:36:03.241 UTC
10.100.1.4/32, version 34, internal 0x5000001 0x0 (ptr 0xa12cc1fc) [1], 0x0 (0xa12b15a8), 0xa08 (0xa14a70f0)
Updated Jun 6 09:39:24.56
Prefix Len 32, traffic index 0, precedence n/a, priority 15
Extensions: context-label:24012
via 10.3.3.9/32, 3 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 0 NHID 0x0 [0xa150fecc 0x0]
recursion-via-/32
next hop 10.3.3.9/32 via 24011/0/21
local label 24012
next hop 10.3.3.9/32 tt1 labels imposed {ImplNull 24000}
Avec le mot clé mpls, la réécriture ressemble à ceci :
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24012
Tue Jun 6 10:43:50.559 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24012 24000 10.100.1.4/32 tt1 10.3.3.9 0
Sans le mot clé mpls, la réécriture ressemble à ceci :
RP/0/0/CPU0:ASBR1#show mpls forwarding labels 24012
Tue Jun 6 10:45:08.734 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24012 Pop 10.100.1.4/32 tt1 10.3.3.9 0
Cette étiquette 14012 n'est pas utilisée pour le trafic de VRF à VRF ou de PE à PE, mais si elle est détectée, cela peut indiquer que l'entrée LFIB (Label Forwarding Instance Base) est ou était erronée.
RP/0/0/CPU0:PE1# trace vrf one 10.99.1.2
Type escape sequence to abort.
Tracing the route to 10.99.1.2
1 10.1.1.5 [MPLS: Labels 24001/24015 Exp 0] 129 msec 229 msec 129 msec
2 10.1.2.3 [MPLS: Label 24015 Exp 0] 219 msec 439 msec 349 msec
3 10.3.3.9 [MPLS: Labels 24000/24011 Exp 0] 169 msec 249 msec 139 msec
4 10.3.5.4 [MPLS: Label 24011 Exp 0] 89 msec 129 msec 109 msec
5 10.2.1.6 [MPLS: Labels 24004/24008 Exp 0] 139 msec 99 msec 139 msec
6 10.2.2.2 129 msec * 219 msec
Si vous basculez le mot clé mpls sur la commande eBGP multihop, le message syslog peut provoquer une collision d'étiquette BGP :
bgp[1051]: %ROUTING-BGP-4-LABEL_COLLISION : Label 24012 collision: prev: [T: 3 RD:0:0:0 PFX/NHID:10.100.1.4/32] curr: [T: 13 RD:0:0:0 PFX/NHID:10.100.1.4/32]
Ce message concerne l'étiquette locale 24012.
La vérification est effectuée pour s'assurer qu'une étiquette active appartenant à BGP n'est pas attribuée à nouveau par BGP pour quoi que ce soit d'autre. Cette vérification concerne uniquement les étiquettes par préfixe.
Ce message est un symptôme et non la cause d'un problème quelconque de cet article.
7. Session BGP à sauts multiples sur sous-couche VPN (ou 6PE ou EVPN)
S'il existe une session eBGP à sauts multiples, la route pour l'adresse de tronçon suivant ne peut pas être apprise via une route vpnv4/6 ou 6PE (IPv6 sur MPLS) ou Ethernet Virtual Private Network (EVPN), à moins que le routeur ne dispose de la version 6.3.2 ou ultérieure de Cisco IOS®-XR. Reportez-vous à cette image.
Image 8.
Scénarios d'échec possibles :
- Session à sauts multiples eBGP de PE1 (à l'intérieur d'un VRF) à PE2 (à l'intérieur d'un VRF)
- Session à sauts multiples eBGP de PE1 (à l'intérieur d'un VRF) à CE2
Ceci s'applique :
La session à sauts multiples eBGP est configurée sous la section VRF sous le routeur BGP sur le routeur PE.
La session à sauts multiples eBGP de PE1 (à l'intérieur du VRF) à PE2 (à l'intérieur du VRF) ou la session à sauts multiples eBGP est de PE1 (à l'intérieur du VRF) à CE2, n'est prise en charge qu'à partir de Cisco IOS®-XR 6.3.2.
L'adresse homologue eBGP est accessible sur la sous-couche qui se compose de vnpv4. vpnv6, 6PE ou EVPN.
Dans les versions de Cisco IOS® antérieures à la version 6.3.2, la session eBGP est inactive.
Par exemple, la session à sauts multiples eBGP PE1 à PE2 dans VRF one est configurée.
Configuration appropriée pour la session à sauts multiples eBGP de PE1 à PE2 sur PE1 :
interface Loopback100
vrf one
ipv4 address 10.2.100.1 255.255.255.255
router bgp 1
address-family vpnv4 unicast
!
neighbor 10.100.1.2
remote-as 1
update-source Loopback0
address-family vpnv4 unicast
!
!
vrf one
rd 1:1
address-family ipv4 unicast
redistribute connected
!
neighbor 10.2.100.2
remote-as 65002
ebgp-multihop 255
local-as 65001
update-source Loopback100
address-family ipv4 unicast
route-policy pass in
route-policy pass out
!
!
!
!
La session eBGP reste inactive :
RP/0/0/CPU0:PE1#show bgp vrf one neighbors
BGP neighbor is 10.2.100.2, vrf one
Remote AS 65002, local AS 65001, external link
Remote router ID 0.0.0.0
BGP state = Idle (No route to multi-hop neighbor)
La route pour l'adresse homologue eBGP est présente dans la table de routage VRF 1 :
RP/0/0/CPU0:PE1# show route vrf one
Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR
A - access/subscriber, a - Application route, (!) - FRR Backup path
Gateway of last resort is not set
L 10.2.100.1/32 is directly connected, 00:23:25, Loopback100
B 10.2.100.2/32 [200/0] via 10.100.1.2 (nexthop in vrf default), 00:19:28
RP/0/0/CPU0:PE1# show route vrf one 10.2.100.2/32
Routing entry for 10.2.100.2/32
Known via "bgp 1", distance 200, metric 0, type internal
Installed May 29 09:07:53.368 for 00:19:36
Routing Descriptor Blocks
10.100.1.2, from 10.100.1.2
Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id: 0xe0000000
Route metric is 0
No advertising protos.
La cause sous-jacente du problème est que la route pour l'adresse d'appairage est une route importée :
RP/0/0/CPU0:PE1# show bgp vpnv4 unicast vrf one 10.2.100.2/32
BGP routing table entry for 10.2.100.2/32, Route Distinguisher: 1:1
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Last Modified: May 29 09:07:53.524 for 00:21:20
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
Local
10.100.1.2 (metric 2) from 10.100.1.2 (10.100.1.2)
Received Label 16001
Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, import-candidate, imported
Received Path ID 0, Local Path ID 1, version 7
Extended community: RT:1:1
Source VRF: one, Source Route Distinguisher: 1:1
Ceci est pris en charge après Cisco IOS®-XR 6.3.2.
8. Redistribution de BGP dans LDP
Voici ce qu'est Unified ou Seamless MPLS et comment il est configuré avec IOS-XR : Unified MPLS avec IOS-XR
Avec le MPLS unifié standard, il y a une LU BGP entre tous les routeurs PE et ABR, comme le montre l'image.
Image 9.
Image 10.
Dans cet exemple, il existe une zone/niveau IGP sans LU BGP. À gauche, la zone d'agrégation est en fait le processus OSPF (Open Shortest Path First) 1, qui n'a pas de redistribution avec le processus OSPF 2 dans le coeur. Dans la partie du réseau avec OSPF 1, il n'y a pas de LU BGP entre les routeurs PE et ABR (Area Border Router).
Image 11.
Les préfixes LU BGP sont redistribués dans l'IGP OSPF 1 sur ABR1, comme l'illustre l'image.
Image 12.
BGP doit allouer l'étiquette pour les préfixes LU iBGP reçus. Cependant, cette étiquette n'est pas automatiquement annoncée par le protocole LDP dans la liaison d'étiquette pour le préfixe redistribué. IOS(-XE) le fait par défaut.
Notez que l'ABR redistribue les routes BGP internes dans l'IGP dans la zone de gauche. Cela signifie que la commande bgp redistribute-internal est nécessaire sous router bgp.
router bgp 1
bgp redistribute-internal
router ospf 1
router-id 10.100.1.3
redistribute bgp 1 metric 10 route-policy select-to-allocate
area 0
interface Loopback0
!
interface GigabitEthernet0/0/0/0
network point-to-point
!
!
!
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
L'ABR attribue une étiquette locale aux routes LU iBGP reçues lorsque l'allocation d'étiquette locale est activée.
router bgp 1
bgp redistribute-internal
ibgp policy out enforce-modifications
address-family ipv4 unicast
redistribute ospf 1 metric 10 route-policy ospf-1-loopbacks-PE
allocate-label route-policy select-to-allocate
La stratégie de route select-to-allocation peut être utilisée pour spécifier quels préfixes LU BGP reçus se voient attribuer une étiquette locale.
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
!
Le préfixe de bouclage de PE2 est affiché sur ABR1 avec une étiquette locale, mais le protocole LDP ne voit pas cette étiquette locale :
RP/0/0/CPU0:ABR1#show bgp ipv4 labeled-unicast 10.100.1.7/32
BGP routing table entry for 10.100.1.7/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 6 6
Local Label: 24006
Last Modified: Sep 5 06:55:47.368 for 06:40:23
Paths: (1 available, best #1)
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.2
Path #1: Received by speaker 0
Advertised IPv4 Labeled-unicast paths to update-groups (with more than one peer):
0.2
Local, (Received from a RR-client)
10.100.1.5 (metric 20) from 10.100.1.5 (10.100.1.7)
Received Label 24003
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 1, version 6
Originator: 10.100.1.7, Cluster list: 10.100.1.5
RP/0/0/CPU0:ABR1#show mpls ldp bindings 10.100.1.7/32
10.100.1.7/32, rev 0 (no route)
No local binding
Remote bindings: (1 peers)
Peer Label
----------------- ---------
10.100.1.2:0 18
Cela signifie que le LSP de PE1 à PE2 est interrompu :
RP/0/0/CPU0:PE1#traceroute 10.100.1.7 source 10.100.1.1
Type escape sequence to abort.
Tracing the route to 10.100.1.7
1 10.1.1.2 [MPLS: Label 18 Exp 0] 9 msec 0 msec 0 msec
2 10.1.2.3 0 msec 0 msec 0 msec <<< no MPLS labels
3 10.1.3.4 [MPLS: Labels 16/24003 Exp 0] 29 msec 19 msec 29 msec
4 10.1.4.5 [MPLS: Label 24003 Exp 0] 9 msec 9 msec 9 msec
5 * * *
6 10.1.6.7 9 msec * 19 msec
Le LSP est interrompu sur P2 car il n'a pas obtenu d'étiquette distante via LDP à partir d'ABR1. ABR1 n'a pas l'étiquette attribuée localement pour le préfixe 10.100.1.7/32 dans le protocole LDP.
Une configuration est nécessaire sur l'ABR pour redistribuer BGP dans LDP sur le routeur où la route BGP est redistribuée dans l'IGP.
ABR1 n’annonce pas de liaison d’étiquette LDP pour le préfixe 10.100.1.7/32 au routeur P2.
Pour qu'ABR1 annonce la liaison d'étiquette LDP pour les préfixes iBGP redistribués, ABR1 doit avoir la configuration suivante (le numéro de système autonome doit être configuré).
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
!
!
!
Le protocole LDP peut filtrer les annonces. Par exemple, vous pouvez configurer un filtre comme suit :
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
advertise-to 1
!
ipv4 access-list 1
10 permit ipv4 host 10.100.1.2 any
Vous spécifiez l’ID de routeur LDP dans la liste d’accès.
Avec cet exemple, l'ABR annonce uniquement des liaisons LDP pour les routes iBGP redistribuées au voisin LDP P2 (et non à P1), puisque 10.100.1.2 est l'ID de routeur LDP de P2.
Le LSP de PE1 à PE2 est maintenant ininterrompu :
RP/0/0/CPU0:PE1#traceroute 10.100.1.7 source 10.100.1.1
Type escape sequence to abort.
Tracing the route to 10.100.1.7
1 10.1.1.2 [MPLS: Label 20 Exp 0] 39 msec 49 msec 29 msec
2 10.1.2.3 [MPLS: Label 24006 Exp 0] 29 msec 49 msec 39 msec
3 10.1.3.4 [MPLS: Labels 16/24003 Exp 0] 29 msec 19 msec 29 msec
4 10.1.4.5 [MPLS: Label 24003 Exp 0] 29 msec 19 msec 29 msec
5 * * *
6 10.1.6.7 19 msec * 19 msec
Image 13.
L'étiquette attribuée par BGP (24006) annoncée par le protocole LDP dans la zone d'agrégation de gauche est maintenant utilisée pour le trafic de PE1 à PE2.
Notez qu'une seule étiquette MPLS est utilisée dans la zone d'agrégation de gauche. Deux étiquettes seraient utilisées s'il s'agit d'un MPLS unifié standard.
À ce stade, vous ne pouvez pas filtrer quelles routes LU iBGP redistribuées dans le protocole LDP, recevoir une étiquette locale et lesquelles ne le sont pas. Dès que la redistribution des routes LU iBGP dans le LDP est activée, elles obtiennent toutes une étiquette locale.
PE2 annonce également le préfixe 10.100.1.99/32 dans la LU BGP. Ce préfixe n'est pas redistribué par ABR1 dans OSPF 1. Cependant, dès que la redistribution des routes LU iBGP dans le LDP a été activée, le préfixe 10.100.1.99/32 a également obtenu une étiquette locale.
RP/0/0/CPU0:ABR1#show mpls ldp bindings 10.100.1.99/32
10.100.1.99/32, rev 24
Local binding: label: 24007
No remote bindings
9. Commande MPLS Activate Interface
Exemple 1. IGP mais pas LDP
La commande mpls activate est nécessaire si un protocole IGP prend en charge le routage interne, mais qu'il n'y a pas de protocole LDP pour annoncer les liaisons d'étiquette. Si chaque saut exécute BGP, la LU BGP peut être utilisée pour annoncer les préfixes et les étiquettes. Lorsque c'est iBGP sur une liaison, cette liaison doit être activée sous le routeur BGP avec la commande mpls activate. Reportez-vous à cette image.
Image 14.
R1 et R2 exécutent une LU IGP et iBGP entre eux. R1 et R2 sont directement connectés. R2 dispose d'une session LU eBGP vers R3.
R3 annonce le préfixe 10.100.100.3/2 à R2 sur une session LU eBGP. R2 annonce ce préfixe à R1 sur une session LU iBGP.
L'objectif est d'avoir un LSP ininterrompu de R1 à R3. Est-ce là ?
RP/0/0/CPU0:R1#trace 10.100.100.3 so 10.100.100.1
Type escape sequence to abort.
Tracing the route to 10.100.100.3
1 100.1.1 !N * !N
Il n'existe aucune étiquette pour ce préfixe au premier saut.
RP/0/0/CPU0:R1#traceroute mpls ipv4 10.100.100.3/32 ttl 5
Tracing MPLS Label Switched Path to 10.100.100.3/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 0.0.0.0 MRU 0 [No Label]
Q 1 *
Donc, il n'y a pas d'étiquette. Ce n'est pas une surprise, car MPLS n'est pas activé sur l'interface de R2 :
RP/0/0/CPU0:R1#show mpls interfaces
RP/0/0/CPU0:R1#
Le préfixe LU annoncé par R3 est toutefois présent sur R1 :
RP/0/0/CPU0:R1#show bgp ipv4 labeled-unicast 10.100.100.3/32
BGP routing table entry for 10.100.100.3/32
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Local Label: 24001
Last Modified: Sep 13 14:27:17.510 for 00:11:39
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65001
10.100.1.2 (metric 2) from 10.100.1.2 (10.100.1.2)
Received Label 24002
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best, labeled-unicast
Received Path ID 0, Local Path ID 1, version 7
Vous configurez la commande mpls active sur R1 pour l'interface à R2 :
router bgp 65000
mpls activate
interface GigabitEthernet0/0/0/0
!
address-family ipv4 unicast
network 10.100.100.1/32
allocate-label all
!
neighbor 10.100.1.2
remote-as 65000
update-source Loopback0
address-family ipv4 labeled-unicast
!
!
!
MPLS est maintenant activé sur l'interface sortante.
RP/0/0/CPU0:R1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No No No Yes
La commande traceroute indique maintenant que le LSP est ininterrompu.
RP/0/0/CPU0:R1#trace 10.100.100.3 so 10.100.100.1
Type escape sequence to abort.
Tracing the route to 10.100.100.3
1 10.1.2.2 [MPLS: Label 24002 Exp 0] 39 msec 9 msec 9 msec
2 10.2.3.3 19 msec * 9 msec
RP/0/0/CPU0:R1#traceroute mpls ipv4 10.100.100.3/32 ttl 5 source 10.100.100.1
Tracing MPLS Label Switched Path to 10.100.100.3/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx labl,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: implicit-null/24002 Exp: 0/0]
L 1 10.1.2.2 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0] 0 ms
! 2 10.2.3.3 10 ms
Exemple 2 . Confédération
Cet exemple montre que la commande mpls activate est nécessaire sur les liaisons de confédération eBGP (inter-AS) lorsque vous utilisez une LU BGP (RFC 3107) et que vous n'utilisez pas LDP.
Le réseau de cette image est une confédération 65000 avec des systèmes subautonomes 65501, 65502, 65503 et 65504.
Image 15.
L'idée est d'avoir un LSP MPLS de R1 à R8 (10.0.0.8/32 est annoncé par R8 dans la LU BGP) en utilisant la LU BGP dans les deux systèmes autonomes.
Il existe une LU eBGP régulière entre R7 et R8. Il existe un iBGP confus entre R2 et R4 et entre R5 et R6. Il existe un eBGP confus entre R1 et R2, R4 et R5, et entre R6 et R7. Il y a le saut suivant sur chaque session eBGP.
La route statique vers le tronçon suivant de l'homologue eBGP (typique pour les sessions BGP inter-AS) est nécessaire car il y a eBGP entre les systèmes sous-autonomes à l'intérieur de la confédération.
Est-ce suffisant pour établir la connectivité entre R1 et R8 ? Cela signifie que l'objectif est d'avoir un LSP ininterrompu de R1 à R8.
Vérifiez ceci.
RP/0/0/CPU0:R1#traceroute 10.0.0.8
Type escape sequence to abort.
Tracing the route to 10.0.0.8
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
La commande traceroute ne renvoie aucun saut/étiquette et continuera si aucune limite de durée de vie n’est spécifiée sur la commande. Les routeurs répondent probablement à la commande traceroute, mais les paquets risquent de ne pas revenir à R1. Faites mpls traceroute qui est un pari plus sûr.
RP/0/0/CPU0:R1#trace mpls ipv4 10.0.0.8/32
Tracing MPLS Label Switched Path to 10.0.0.8/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: implicit-null/24015 Exp: 0/0]
L 1 10.1.2.2 MRU 1500 [Labels: 24003/24014 Exp: 0/0] 10 ms
L 2 10.2.3.3 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms
N 3 10.3.4.4 MRU 0 [No Label] 10 ms
Vous voyez que le problème se trouve sur R4. L'interface sortante est manquante dans la LFIB :
RP/0/0/CPU0:R4#show mpls forwarding prefix 10.0.0.8/32
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24014 24014 10.0.0.8/32 10.4.5.5 5140
L'entrée dans CEF n'est pas résolue :
RP/0/0/CPU0:R4#show cef 10.0.0.8/32
10.0.0.8/32, version 109, drop adjacency, internal 0x5000001 0x0 (ptr 0xa14160e4) [1], 0x0 (0xa13f83c8), 0xa08 (0xa16cd370)
Updated Sep 13 12:43:30.252
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.4.5.5/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0f182d8 0x0]
recursion-via-/32
unresolved
local label 24014
labels imposed {24014}
MPLS n'est pas activé sur l'interface GE0/0/0/1 :
RP/0/0/CPU0:R4#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
Le problème est résolu à l'aide de la commande permettant d'activer MPLS pour BGP sur la liaison entre R4 et R5. R4 et R5 ont une session de confédération eBGP sur cette liaison. En réalité, il s'agit d'une session iBGP au sein de la confédération 65000. Par conséquent, la commande permettant d'activer MPLS est nécessaire pour s'assurer que le préfixe sur R4 est résolu au prochain saut R5. Dans d'autres réseaux réguliers, il y aurait un protocole LDP qui s'en occupe, mais ici il n'y a pas de protocole LDP entre R4 et R5 parce qu'il s'agit d'une session eBGP à l'intérieur de la confédération.
Ajoutez la commande mpls activate pour l'interface ge 0/0/0/1 sur R4 :
router bgp 65502
bgp confederation peers
65501
65503
65504
!
bgp confederation identifier 65000
mpls activate
interface GigabitEthernet0/0/0/1
!
…
RP/0/0/CPU0:R4#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
GigabitEthernet0/0/0/1 No No No Yes
La commande traceroute révèle maintenant un LSP ininterrompu de R1 à R8.
RP/0/0/CPU0:R1#trace mpls ipv4 10.0.0.8/32
Tracing MPLS Label Switched Path to 10.0.0.8/32, timeout is 2 seconds
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.
0 10.1.2.1 MRU 1500 [Labels: implicit-null/24015 Exp: 0/0]
L 1 10.1.2.2 MRU 1500 [Labels: 24003/24014 Exp: 0/0] 10 ms
L 2 10.2.3.3 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms
L 3 10.3.4.4 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 10 ms
L 4 10.4.5.5 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 20 ms
L 5 10.5.6.6 MRU 1500 [Labels: implicit-null/24014 Exp: 0/0] 30 ms
L 6 10.6.7.7 MRU 1500 [Labels: implicit-null/implicit-null Exp: 0/0] 30 ms
! 7 10.7.8.8 30 ms
RP/0/0/CPU0:R1#traceroute 10.0.0.8
Type escape sequence to abort.
Tracing the route to 10.0.0.8
1 10.1.2.2 [MPLS: Label 24015 Exp 0] 69 msec 29 msec 29 msec
2 10.2.3.3 [MPLS: Labels 24003/24014 Exp 0] 49 msec 29 msec 29 msec
3 10.3.4.4 [MPLS: Label 24014 Exp 0] 19 msec 19 msec 19 msec
4 10.4.5.5 [MPLS: Label 24014 Exp 0] 49 msec 19 msec 29 msec
5 10.5.6.6 [MPLS: Label 24014 Exp 0] 19 msec 19 msec 29 msec
6 10.6.7.7 [MPLS: Label 24014 Exp 0] 29 msec 29 msec 29 msec
7 10.7.8.8 29 msec * 29 msec
Il existe maintenant une interface sortante dans LFIB pour cette entrée :
RP/0/0/CPU0:R4#show mpls forwarding prefix 10.0.0.8/32
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24014 24014 10.0.0.8/32 Gi0/0/0/1 10.4.5.5 2890
L'étiquette sortante est présente sur R4 pour le préfixe et CEF affiche le préfixe comme résolu :
RP/0/0/CPU0:R4#show cef 10.0.0.8/32
Updated Sep 13 12:43:30.252
Prefix Len 32, traffic index 0, precedence n/a, priority 4
via 10.4.5.5/32, 3 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa17420e4 0x0]
recursion-via-/32
next hop 10.4.5.5/32 via 24016/0/21
local label 24014
next hop 10.4.5.5/32 Gi0/0/0/1 labels imposed {ImplNull 24014}
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)