Re: iBGP routes + MPLS question

Barry Yost · ‎08-22-2017

I'm playing around with MPLS in the lab to get some hands-on time with the technology.

I set up a basic A-B-C router chain with B as the P-router, with A<>C peering via iBGP and learning eBGP routes from two more test routers.

A-B-C use OSPF as the IGP, and B has no BGP whatsoever.

If LDP is down whenever A learns a route, then router C only attempts to forward via IP and not the MPLS path. When LDP is restored, the two routers do not add the LSP into the CEF table.

If I clear eBGP on A or iBGP on either A or C, then when the paths are re-learned, the MPLS path is used. (it shows as a label+next hop+interface in the CEF table).

This is also true if I break LDP and then restore it, w/o any BGP topology changes.

I assume that I'm missing something simple here. Why isn't the label taking over on its own when it becomes available?

Sample output when things are working: (10.1.3.3 is the IP address of router B)

RouterA#show ip cef 10.2.200.200
10.2.200.0/24, version 21, epoch 0, cached adjacency 10.1.3.3
0 packets, 0 bytes
  tag information set, shared
    local tag: 25
    fast tag rewrite with Fa1/0, 10.1.3.3, tags imposed: {19}
  via 10.1.3.3, FastEthernet1/0, 1 dependency
    next hop 10.1.3.3, FastEthernet1/0
    valid cached adjacency
    tag rewrite with Fa1/0, 10.1.3.3, tags imposed: {19}

Here's the output with MPLS broken:

RouterA#show ip cef 10.2.200.200
10.2.200.0/24, version 21, epoch 0, cached adjacency 10.1.3.3
0 packets, 0 bytes
  tag information set, shared
    local tag: 25
  via 10.1.3.3, FastEthernet1/0, 1 dependency
    next hop 10.1.3.3, FastEthernet1/0
    valid cached adjacency
    tag rewrite with Fa1/0, 10.1.3.3, tags imposed: {}

EDIT:

One more detail is that when I restore LDP, the show ip CEF output looks the same as when things are working properly. (except that a new label may have been chosen). Wireshark confirms that router A is transmitting packets w/o the label until I bounce either iBGP between A and C, or else the eBGP source of the route that would follow this path.

cofee · ‎08-22-2017

How long did you wait after LDP sessions are restored? is it possible that you didn't wait long enough before LDP could reconverge and re-build labels?

cofee · ‎08-22-2017

forgot to ask how did you break LDP session?

Barry Yost · ‎08-22-2017

On router B, I issue the command "no mpls ip"
I don't check for the use of MPLS until after both routers A & C show LDP neighbor up.
After waiting about 30 seconds or so, I am able to show mpls ip binding 10.2.200.0 24 and it is in the list with a label. However, even waiting a minute or two doesn't help.

cofee · ‎08-22-2017

I didn't experience this issue in my lab. If you can share the topology and configuaration I can test in the lab.

cofee · ‎08-22-2017

If it's a gns file then you can just send me the gns file.

Barry Yost · ‎08-23-2017

I uploaded the exported file to Dropbox:

https://www.dropbox.com/s/i995bvfzpx7hf9i/mpls%20issue.zip?dl=0

Thanks for taking a look!

lespejel · ‎08-23-2017

I think this could be a bug with your code, because the format I think it's a little old; you can see my config (PE), output for debug mpls ldp bindings after restoring mpls ip, and show mpls forwarding 10.0.0.3 detail (exit PE) where you can see labels and L2 forwarding details.

Version 15.5

R7_ISP(config-if)# do sh run | s bgp|int|ospf

interface Loopback0
ip address 10.0.0.7 255.255.255.255
ip ospf 1 area 0
interface Ethernet0/0
description to R6 Eth 0/2
ip address 10.6.7.7 255.255.255.0
ip ospf 1 area 0
mpls ip

interface Ethernet0/2
description to Customer R9 vrf green
vrf forwarding green
ip address 20.7.9.7 255.255.255.0

interface Ethernet0/3
description to Customer R8 vrf red
vrf forwarding red
ip address 20.7.8.7 255.255.255.0

router ospf 1
router-id 10.0.0.7

router bgp 10
bgp router-id 10.0.0.7
bgp log-neighbor-changes
neighbor 10.0.0.4 remote-as 10
neighbor 10.0.0.4 update-source Loopback0
neighbor 10.0.0.5 remote-as 10
neighbor 10.0.0.5 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.0.4 activate
neighbor 10.0.0.4 send-community both
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 send-community both
maximum-paths 2
exit-address-family
!
address-family ipv4 vrf green
neighbor 20.7.9.9 remote-as 41
neighbor 20.7.9.9 activate
exit-address-family
!
address-family ipv4 vrf red
neighbor 20.7.8.8 remote-as 30
neighbor 20.7.8.8 activate
neighbor 20.7.8.8 as-override
exit-address-family

*Aug 23 09:37:33.471: tib: Assign 10.3.4.0/24 nh 10.6.7.6 real label
*Aug 23 09:37:33.471: tib: found route info for 10.3.4.0/24(0, 10.6.7.6, Et0/0), remote label Unknown
*Aug 23 09:37:33.471: tib: update route info for 10.3.4.0/24(0, 10.6.7.6, Et0/0), with remote label 24 from 10.0.0.6:0
*Aug 23 09:37:33.471: tagcon: announce labels for: 10.3.4.0/24; nh 10.6.7.6, Et0/0, inlabel 706, outlabel 24 (from 10.0.0.6:0), get path labels
*Aug 23 09:37:33.471: tib: 10.0.0.7/32:: learn binding 25 from 10.0.0.6:0
*Aug 23 09:37:33.471: tib: a new binding to be added
*Aug 23 09:37:33.471: tagcon: tibent(10.0.0.7/32): label 25 from 10.0.0.6:0 added
*Aug 23 09:37:33.471: tib: next hop is zero for route 10.0.0.7/32(0, 0.0.0.0, Lo0)
*Aug 23 09:37:33.471: tib: invoke iprm label announcement for 10.0.0.7/32
*Aug 23 09:37:33.471: tib: prefix recurs walk start: 10.0.0.7/32, tableid: 0
*Aug 23 09:37:33.471: tib: get path labels: 10.0.0.7/32(0), nh tableid: 0, Lo0, nh 0.0.0.0
*Aug 23 09:37:33.471: tib: Assign 10.0.0.7/32 nh 0.0.0.0 imp-null label - Connected route, Loopback idb
*Aug 23 09:37:33.471: tib: found route info for 10.0.0.7/32(0, 0.0.0.0, Lo0), remote label Unknown
*Aug 23 09:37:33.471: tib: update route info for 10.0.0.7/32(0, 0.0.0.0, Lo0), with remote label Unknown
*Aug 23 09:37:33.471: tagcon: announce labels for: 10.0.0.7/32; nh 0.0.0.0, Lo0, inlabel imp-null, outlabel unknown (from 0.0.0.0:0), get path labels

R7_ISP#sh mpls forwarding-table 10.0.0.3 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
704 21 10.0.0.3/32 0 Et0/0 10.6.7.6
MAC/Encaps=14/18, MRU=1500, Label Stack{21}
AABBCC000620AABBCC0007008847 00015000 <----layer 2 fwd info
No output feature configured

R7_ISP#sh ip cef 10.0.0.3 internal
10.0.0.3/32, epoch 0, RIB[I], refcnt 6, per-destination sharing
sources: RIB, RR, LTE
feature space:
IPRM: 0x00028000
LFD: 10.0.0.3/32 1 local label
local label info: global/704
contains path extension list
disposition chain 0xA600CB4C
label switch chain 0xA600CB4C
subblocks:
1 RR source [no flags]
non-eos chain 21
ifnums:
Ethernet0/0(3): 10.6.7.6
path list A5ADB6D4, 19 locks, per-destination, flags 0x4D [shble, hvsh, rif, hwcn]
path A5ADBC54, share 1/1, type attached nexthop, for IPv4
MPLS short path extensions: MOI flags = 0x0 label 21
nexthop 10.6.7.6 Ethernet0/0 label 21, IP adj out of Ethernet0/0, addr 10.6.7.6 A41B06E0
output chain:
label 21
TAG adj out of Ethernet0/0, addr 10.6.7.6 A41B05B0

Capture after binding restored, echo request sent

MultiProtocol Label Switching Header, Label: 21, Exp: 0, S: 1, TTL: 255
0000 0000 0000 0001 0101 .... .... .... = MPLS Label: 21
.... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0
.... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1
.... .... .... .... .... .... 1111 1111 = MPLS TTL: 255

CCIE 52804

Barry Yost · ‎08-24-2017

I was wondering if it might be a bug. The IOS in this lab was 12.4(25a) - I've got a npe-g2 image for 15.1(4)M available - I'll try running that in GNS3 to see if it makes any difference.