VRF table CEF entry shows incorrect label stack

[Sheetal.Jangeed@ecitele.com]

Hi,

I am using a Cisco VIRL (version 6.1.3)

Topology - 

Cisco-1 --- Cisco-2---3rd party-device

I've MPLS LSP between Cisco 1 and Cisco 2 and between Cisco-3rd part device (Cisco 2 is having Multi-instance ISIS)

cisco1 - Cisco 2 has a iBGP-Labeled unicast peering 

Cisco2 and 3rd party device also has iBGP LU peering 

There is a BGP VPNv4 peering between Cisco1 and 3rd party device 

VRF 'RED' exist on Cisco1 and Cisco 2

I see that on the Cisco 1, the routes advertised by 3rd party device are installed in the VRF 'RED' routing table but in the Cisc1' CEF table I see only the VPN label for the routes advertised by 3rd party device 

I believe the CEF table should also have the IGP label (LDP/SR label to reach the 3rd party device advertised by Cisco 2)

RP/0/0/CPU0:XR_v4_26#sh cef vrf RED 199.199.199.199 detail
Wed Apr 24 14:31:12.246 UTC
199.199.199.199/32, version 17, internal 0x1000001 0x0 (ptr 0xa125a474) [1], 0x0 (0x0), 0x208 (0xa1569208)
Updated Apr 24 07:15:07.078
Prefix Len 32, traffic index 0, precedence n/a, priority 3
gateway array (0xa113b794) reference count 3, flags 0x403a, source rib (7), 0 backups
[1 type 1 flags 0x148441 (0xa158344c) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 3 Apr 24 14:31:10.126
LDI Update time Apr 24 07:15:07.078
via 11.11.11.11/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0e2f294 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
unresolved
labels imposed {524288}

Load distribution: 0 (refcount 1)

Hash OK Interface Address
0 Y Unknown drop
RP/0/0/CPU0:XR_v4_26#

Can anyone please help me in understanding the issue here or may be I am missing something 

[Harold Ritter]

Hi Sheetal,

The "unresolved" in the output you provided tells me that you do not have a static route for the /32 BGP LU directly connected next-hop from cisco1 to cisco2. This is required on XR as specified in the following document.

• For Cisco IOS-XR over Inter-AS link, there is a different logic as compared to that of Cisco IOS. It is required to configure a static /32 route to ASBR1's interface, so that MPLS label is bound for a /32 prefix. If this is not done then the control plane will come up, but the traffic will not be forwarded.

https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/200523-Configuration-and-Verification-of-Layer.html

Although it mentions that it is required for interAS, it is also required for intraAS.

Regards,

[Sheetal.Jangeed@ecitele.com]

Hi Harold 

Thanks a lot for your reply.

I'll put my point here with a detailed diagram to see if I understood your fix correctly 

I've iBGP LU peering between Cisco 2 (lo0 address 151.92.92.92) and Cisco 1 (lo0 address 151.96.96.96) .

Now, with your suggestion I added a static route for 126.0.0.2/32 on Cisco 1 pointing towards the interface connected to Cisco 2

RP/0/0/CPU0:Cisco_1#sh run router static
Thu Apr 25 07:04:39.383 UTC
router static
address-family ipv4 unicast
126.0.0.2/32 GigabitEthernet0/0/0/1

RP/0/0/CPU0:Cisco_1#sh run router bgp
Thu Apr 25 07:05:39.009 UTC
router bgp 100
address-family ipv4 unicast
!
address-family vpnv4 unicast
additional-paths receive
additional-paths send
!
address-family vpnv6 unicast
additional-paths receive
additional-paths send
!
neighbor 151.92.92.92
remote-as 100
local address 151.96.96.96
address-family ipv4 labeled-unicast
!
address-family vpnv4 unicast
soft-reconfiguration inbound always

I added a similar static route on Cisco 2 (for both, interface connected to Cisco 1 and to R3)

But, somehow I still see the VRF route on Cisco 1 to be 'unresolved'

RP/0/0/CPU0:Cisco_1#sh cef vrf RED 199.199.199.199
Thu Apr 25 07:07:43.400 UTC
199.199.199.199/32, version 23, internal 0x1000001 0x0 (ptr 0xa1259f74) [1], 0x0 (0x0), 0x208 (0xa1569348)
Updated Apr 25 06:16:40.680
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 11.11.11.11/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0e2f294 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
unresolved
labels imposed {524288}

RP/0/0/CPU0:Cisco_1#sh cef vrf RED 199.199.199.199 detail
Thu Apr 25 07:08:11.078 UTC
199.199.199.199/32, version 23, internal 0x1000001 0x0 (ptr 0xa1259f74) [1], 0x0 (0x0), 0x208 (0xa1569348)
Updated Apr 25 06:16:40.680
Prefix Len 32, traffic index 0, precedence n/a, priority 3
gateway array (0xa113c888) reference count 3, flags 0x403a, source rib (7), 0 backups
[1 type 1 flags 0x148441 (0xa1583668) ext 0x0 (0x0)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 3 Apr 25 07:07:59.569
LDI Update time Apr 25 06:16:40.680
via 11.11.11.11/32, 0 dependencies, recursive [flags 0x6000]
path-idx 0 NHID 0x0 [0xa0e2f294 0x0]
recursion-via-/32
next hop VRF - 'default', table - 0xe0000000
unresolved
labels imposed {524288}

Load distribution: 0 (refcount 1)

Hash OK Interface Address
0 Y Unknown drop
RP/0/0/CPU0:XR_v4_26#

[Harold Ritter]

Hi Sheetal,

Thanks for the additional information. Since you use BGP LU as a replacement for LDP/IGP, the session needs to be establish the BGP LU session using the directly connected peer (126.0.0.2) rather than on the loopback address. You also need to enable mpls on the all interfaces using the "mpls activate" command under BGP.

Regards,