Cisco IOS-XR BGP with MPLS Designs
Available Languages
Contents
Introduction
This document describes a few scenarios that have a special behavior and configuration for the combination of Multiprotocol Label Switching (MPLS) and Border Gateway Protocol (BGP) in Cisco IOS®-XR.
1. A Static Route is Needed for Inter-AS MPLS VPN Options B & C
This image shows an Inter-AS Option B setup.
Image 1.
The Provider Edge (PE) router PE1 has a route for the VRF prefix 10.200.1.2/32, but it is unresolved.
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 does not have a route for 10.3.1.4/32. It does have a route for 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.
There must be a static route on the Autonomous System Border Route (ASBR) for the next-hop. You have to configure this static route on each ASBR and redistribute it into the Interior Gateway Protocol (IGP).
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
!
!
router ospf 1
redistribute static
The route is now resolved.
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 installs an outgoing label of POP towards ASBR2 for the VPNv4/6 prefixes:
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
Even with next-hop-self on the ASBR towards the iBGP neighbors, the label forwarding between the ASBRs will be broken, if the static route is not configured on the ASBR.
With next-hop-self on ASBR1 towards PE1 and no static route:
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
Notice that the outgoing interface is missing on the Outgoing Interface column. The static route is needed on ASBRs for Inter-AS Option B and C.
2. Retain the Route-Targets on the ASBRs for Inter-AS Option B
A command is needed to ensure that the ASBR stores/keeps the vpnv4/6 routes and then advertises them. Without this command, the ASBR does not store the routes if there is no local VRF configured on the ASBR that imports any of the Route-Targets of the routes, or if it is not a route reflector (RR) for address family vpnv4/6.
router bgp 1
address-family ipv4 unicast
!
address-family vpnv4 unicast
retain route-target all
!
3. IPv4 Labelled-Unicast Addresses are not Advertised by ASBR
IPv4 labelled-unicast is needed in Inter-AS Option C or Seamless MPLS (Unified MPLS) networks. This is because vpnv4/6 prefixes are labelled by default, but this is not the case for IPv4 (IPv6) unicast. If this is not the case, then the Label Switched Path (LSP) end-to-end is interrupted and the traffic flow end-to-end fails.
Look at image 2, it shows an Inter-AS Option C setup.
Image 2.
The P1 and P2 routers are also the Route Reflectors in their Autonomous System (AS) for vpnv4.
The Labeled Unicast (LU) is used to transport the loopback prefixes from one AS into the other.
ASBR1 has this address family configured, but there are no routes in it:
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
The reason is that the ASBR must have the following command so that it can allocate a Multi-Protocol Label Switching (MPLS) label for each route and then advertise the routes.
RP/0/0/CPU0:ASBR1#show run router bgp
router bgp 1
address-family ipv4 unicast
redistribute ospf 1
allocate-label all
!
The result of this command is:
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
So, in short:
- Label allocation must be configured (on all ASBRs and PE routers)
- Address family ipv4 labeled-unicast must be configured for the BGP neighbor
4. A Dummy iBGP Neighbor is Needed for eBGP-eBGP (back-to-back eBGP) Vpnv4
Look at image 3.
Image 3.
There are three ASBRs in a row. The ASBR3 runs eBGP vpnv4 unicast to ASBR1 and 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
There is an issue with advertising the vpnv4 routes from ASBR3: ASBR3 does not advertise the external vpnv4 routes out.
The solution is to configure a dummy iBGP neighbor on ASBR3 and enable next-hop-self: The dummy iBGP neighbor does not need to be up.
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
!
!
!
The result is that the vpnv4 route is now advertised:
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. Inter-AS Option C - The BGP Label is Preferred over the LDP Label
Refer to this image in order to see a setup with the two ASBRs connected over multiple links. In order to make this work, the eBGP ipv4 LU session between the ASBRs must be multi-hop as there are parallel links between them.
Image 4.
This is Inter-AS option C. Routers P1 and P2 are also the Route-Reflectors for vpnv4.
There is IPv4 labelled unicast between the PE routers and ASBRs. The ASBRs are directly connected over multiple links.
On the ASBR, you see:
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
There is no Label Distribution Protocol (LDP) needed between the ASBRs. BGP will take care of the MPLS forwarding on the links between the ASBRs.
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
So far so good. The issue is with the scenario as shown in this image.
Image 5.
This is Inter-AS option C. Routers P1 and P2 are also the Route-Reflectors for vpnv4.
There is IPv4 labelled unicast between the PE routers and ASBRs. ASBR1 and ASBR2 are not directly connected. They are connected multi-hop, through a network running an IGP and LDP. In image 5, this intermediate network is represented by the router ASBR3, which runs an IGP and LDP with ASBR1 and ASBR2.
With eBGP multi-hop on the ASBRs, there is a problem. The BGP session between the RRs in each AS does not even come up.
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}
In order to get from P1, the RR in AS 1, to P2, the RR in AS 2, the outgoing label is 24007. On ASBR1, this label is swapped with label 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}
The label 24000 is the label received on ASBR1 by BGP LU from 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
However, the ASBR router in between does not run BGP, and hence cannot forward packets it receives with this label, as it did not assign label 24000. The label that should be used to get the packets to 10.100.1.5, is the label from 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.
This recurses to next-hop 10.100.1.4, the loopback of ASBR2.
The label received from ASBR3 by LDP should be used, but it is not.
The label stack added is {ImplNull 24000} instead of {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 should be imposing the LDP label 24002 it received from the ASBR3 router. In order to disable the BGP MPLS forwarding, you add the mpls keyword to the eBGP multi-hop command.
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 now has the correct label rewrite:
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}
From the command reference:
Use of the mpls option in the ebgp-multihop command prevents BGP from enabling MPLS on the peering interface and also prevents allocation of Implicit-NULL rewrite labels for next-hop addresses learned from the peer. This is useful in some scenarios in which MPLS forwarding labels to the nexthops have already been learned via BGP labelled-unicast or LDP.
In other words, in IOS-XR, when BGP offers to allocate a label to the LFIB, it will take precedence over LDP. The scenario of Inter-AS Option C with multiple hops between the ASBR routers is such a scenario.
6. Inter-AS Option B - The BGP label is Preferred over the LDP Label
Image 6.
This is Inter-AS Option B. However, there are multiple parallel links between the two ASBRs. There is RFC3107 (exchanging IPv4 routes and MPLS labels) between the ASBRs, instead of using an IGP and LDP.
In order to bring up the eBGP multihop session between the loopback interfaces of ASBR1 and ASBR2, eBGP LU is needed between the two ASBRs. There are two links between the ASBRs, so there are two eBGP LU sessions needed. The command allocate-label is needed for the address family 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
!
!
The static routes from section 1 are still needed:
router static
address-family ipv4 unicast
10.3.1.4/32 GigabitEthernet0/0/0/1
10.3.2.4/32 GigabitEthernet0/0/0/2
!
!
The eBGP vpnv4 session between the ASBRs:
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
!
!
Notice that the mpls keyword is not needed here, as in section 5. Also, that the iBGP LU sessions between PE and ASBRs are not needed if next-hop-self is configured for the iBGP vpnv4 sessions. The label advertised by ASBR2 for 10.100.1.4/32 is label 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
When there is another path between the ASBRs, and that path uses IGP + LDP or MPLS TE, then the mpls keyword is needed for the eBGP multihop command.
Image 7.
A BGP route-policy on ASBR1 towards P3 is used to set the weight very high so that prefixes from P3 are preferred over the ones from ASBR2 directly.
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 should now use label 24001 as an outgoing label for 10.100.1.4/32. It does not:
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}
The solution is the same as in section 5: use the mpls keyword for the eBGP multihop command.
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 now uses label 24001 as an outgoing label for 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 pushes this extra-label. A traceroute in the Virtual Routing and Forwarding (VRF) from PE1 to PE2 shows the extra labels pushed.
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 and LDP was used between ASBR1 and P3 and ASBR2 and P3. The same issue and solution are there when MPLS Traffic Engineering (TE) is used between these routers.
There is no LDP from ASBR1 to P3, but there is MPLS TE.
Without the mpls keyword on the eBGP multihop command, the same issue is back:
Packets forwarded to 10.100.1.4 do not get the BGP LU label 24000 pushed.
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}
Whereas with the mpls keyword, the label 24000 is present:
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}
With the mpls keyword the rewrite looks like this:
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
Without the mpls keyword, the rewrite looks like this:
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
This label 14012 is not used for traffic from VRF to VRF, or PE to PE, but if encountered, it might be an indication that the Label Forwarding Instance Base (LFIB) entry is or was wrong.
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
Toggling the keyword mpls on the eBGP multihop command could cause the syslog message for BGP label collision:
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]
This message is for the local label 24012.
The check is done to ensure an active label owned by BGP is not assigned again by BGP for anything else. This check is only for per-prefix labels.
This message is a symptom and not the cause of any issue of this article.
7. Multihop BGP session over VPN (or 6PE or EVPN) Underlay
If there is an eBGP multi-hop session, then the route for the next-hop address cannot be learned through a vpnv4/6 or 6PE (IPv6 over MPLS) or Ethernet Virtual Private Network (EVPN) route, unless the router has the Cisco IOS®-XR 6.3.2 or later release. Refer to this image.
Image 8.
Possible failure scenarios:
- eBGP multi-hop session from PE1 (inside a VRF) to PE2 (inside a VRF)
- eBGP multi-hop session from PE1 (inside a VRF) to CE2
This applies:
The eBGP multi-hop session is configured under the VRF section under router BGP on the PE router.
The eBGP multi-hop session from PE1 (inside the VRF) to PE2 (inside the VRF), or the eBGP multi-hop session is from PE1 (inside the VRF) to CE2, are only supported starting with Cisco IOS®-XR 6.3.2.
The eBGP peer address is reachable over the underlay which consists of either vnpv4. vpnv6, 6PE, or EVPN.
In Cisco IOS® releases prior to 6.3.2, the eBGP session will be idle.
For example, the eBGP multi-hop session PE1 to PE2 in VRF one is configured.
The relevant configuration for the eBGP multi-hop session from PE1 to PE2 on 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
!
!
!
!
The eBGP session remains Idle:
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)
The route for the eBGP peer address is present in the VRF one routing table:
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.
The underlying cause of the issue is that the route for the peering address is an imported route:
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
This is supported after Cisco IOS®-XR 6.3.2.
8. Redistribution of BGP into LDP
This is what Unified or Seamless MPLS is and how it is configured with IOS-XR: Unified MPLS with IOS-XR
With regular Unified MPLS there is BGP LU between all PE and ABR routers as shown in the image.
Image 9.
Image 10.
In this example, there is an IGP area/level without BGP LU. On the left, the aggregation area is actually Open Shortest Path First (OSPF) process 1, which does not have redistribution with OSPF process 2 in the core. In the part of the network with OSPF 1, there is no BGP LU between PE and Area Border Router (ABR) routers.
Image 11.
The BGP LU prefixes are redistributed into the IGP OSPF 1 on ABR1 as shown in the image.
Image 12.
You need BGP to allocate the label for the received iBGP LU prefixes. However, this label is not automatically advertised by LDP in the label binding for the redistributed prefix. The IOS(-XE) does this by default.
Note that the ABR is redistributing internal BGP routes into the IGP in the left area. This means that the command bgp redistribute-internal is needed under 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
The ABR assigns a local label to the received iBGP LU routes when local label allocation is enabled.
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
The route-policy select-to-allocate can be used to specify which received BGP LU prefixes are assigned a local label.
route-policy select-to-allocate
if destination in (10.100.1.7/32) then
pass
else
drop
endif
end-policy
!
The loopback prefix of PE2 is seen on ABR1 with a local label, but LDP does not see this local label:
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
This means that the LSP from PE1 to PE2 is interrupted:
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
The LSP is interrupted at P2 because it did not get a remote label via LDP from ABR1. ABR1 does not have the locally assigned label for the prefix 10.100.1.7/32 in LDP.
There is a configuration needed on the ABR to redistribute BGP into LDP on the router where the BGP route is redistributed into the IGP.
ABR1 does not advertise an LDP label binding for the prefix 10.100.1.7/32 to the P2 router.
In order for ABR1 to advertise the LDP label binding for the redistributed iBGP prefixes, ABR1 must have the following configuration (AS number must be configured).
mpls ldp
mldp
address-family ipv4
!
!
router-id 10.100.1.3
address-family ipv4
redistribute
bgp
as 1
!
!
!
You can have LDP filter the advertisements. For example, you can configure a filter like this:
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
You specify the LDP router-ID in the access list.
With this example, the ABR only advertises LDP bindings for the redistributed iBGP routes to the LDP neighbor P2 (and not to P1), since 10.100.1.2 is the LDP router ID of P2.
The LSP from PE1 to PE2 is now uninterrupted:
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.
The BGP assigned label (24006) advertised by LDP into the left aggregation area is now used for the traffic from PE1 to PE2.
Note that only one MPLS label is used in the left aggregation area. Two labels would be used if this is a regular Unified MPLS.
At this point, you cannot filter which of the redistributed LU iBGP routes into LDP, receive a local label and which do not. As soon as the redistribution of iBGP LU routes into LDP is enabled, they all get a local label.
PE2 also advertises prefix 10.100.1.99/32 in BGP LU. This prefix is not redistributed by ABR1 into OSPF 1. However, as soon as the redistribution of iBGP LU routes into LDP was turned on, the prefix 10.100.1.99/32 also got a local label.
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. MPLS Activate Interface Command
Example 1. IGP but no LDP
The mpls activate command is needed if there is an IGP taking care of the internal routing, but there is no LDP to advertise the label bindings. If every hop runs BGP, BGP LU can be used to advertise prefixes and labels. When it is iBGP across a link, that link needs to be enabled under router BGP with the command mpls activate. Refer to this image.
Image 14.
R1 and R2 run an IGP and iBGP LU between them. R1 and R2 are directly connected. R2 has an eBGP LU session to R3.
R3 advertises the prefix 10.100.100.3/2 to R2 over an eBGP LU session. R2 advertises this prefix to R1 over an iBGP LU session.
The goal is to have an uninterrupted LSP from R1 to R3. Is it there?
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
There is no label for this prefix at the first hop.
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 *
So, there is no label. This is not a surprise, because MPLS is not enabled on the interface to R2:
RP/0/0/CPU0:R1#show mpls interfaces
RP/0/0/CPU0:R1#
The LU prefix advertised by R3 is however present on 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
You configure the mpls active command on R1 for the interface to 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 is now enabled on the outgoing interface.
RP/0/0/CPU0:R1#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 No No No Yes
The traceroute now shows that the LSP is uninterrupted.
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
Example 2. Confederation
This example illustrates that the mpls activate command is needed on eBGP (inter-AS) confederation links when you use BGP LU (RFC 3107) and are not using LDP.
The network in this image is a confederation 65000 with sub-autonomous systems 65501, 65502, 65503, and 65504.
Image 15.
The idea is to have an MPLS LSP from R1 to R8 (10.0.0.8/32 is advertised by R8 in BGP LU) by using BGP LU in both autonomous systems.
There is regular eBGP LU between R7 and R8. There is confed iBGP between R2 and R4 and between R5 and R6. There is confed eBGP between R1 and R2, R4 and R5, and between R6 and R7. There is next-hop-self on every eBGP session.
The static route to the next-hop of the eBGP peer (typical for inter-AS BGP sessions) is needed because there is eBGP between the sub-autonomous systems inside the confederation.
Will this be enough to make connectivity between R1 and R8? This means that the goal is to have an uninterrupted LSP from R1 to R8.
Check this.
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 * * *
The traceroute does not return any hops/labels and would continue if there were no TTL limit provided on the command. The routers likely answer the traceroute, but the packets might not make it back to R1. Do mpls traceroute which is a safer bet.
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
You see that the issue is on R4. The outgoing interface is missing in the 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
The entry in CEF is not resolved:
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 is not enabled on the GE0/0/0/1 interface:
RP/0/0/CPU0:R4#show mpls interfaces
Interface LDP Tunnel Static Enabled
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0 Yes No No Yes
The issue is solved with the command to activate MPLS for BGP on the link between R4 and R5. R4 and R5 have an eBGP confederation session across this link. In reality, this is an iBGP session within the confederation 65000. As a result of this, the command to activate MPLS is needed to make sure the prefix on R4 is resolved to the next hop R5. In other regular networks, there would be LDP taking care of this, but here there is no LDP between R4 and R5 because it is an eBGP session inside the confederation.
Add the mpls activate command for the interface ge 0/0/0/1 on 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
The traceroute now reveals an uninterrupted LSP from R1 to 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
There is now an outgoing interface in the LFIB for this entry:
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
The outgoing label is present on R4 for the prefix and CEF shows the prefix as resolved:
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}
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)