InterAS Option B - ASBR interfaces not being MPLS enabled

[steven.crutchley]

Hi everyone,

I'm labbing inter-AS Option B, and I keep running into a problem whereby the control plane is working (routes are being exchanged correctly between ASNs) but the external interfaces (ASBR to ASBR NNIs) are not enabled with MPLS until I shut/no shut them. 

For example, ASBR1 (in AS 100) is connected to ASBR2 (in AS 200) with Gi0/0/0/2. If I issue `show mpls interfaces` I get the following:

RP/0/RP0/CPU0:ASBR1#show mpls interfaces 
Sat Feb  8 17:43:19.708 UTC
Interface                  LDP      Tunnel   Static   Enabled 
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0     Yes      No       No       Yes
GigabitEthernet0/0/0/4     No       No       No       Yes
GigabitEthernet0/0/0/1     Yes      No       No       Yes
RP/0/RP0/CPU0:ASBR1#

So Gi0/0/0/2 in not MPLS enabled. 

To fix this, I simply do this:

RP/0/RP0/CPU0:ASBR1#conf t
Sat Feb  8 17:45:49.283 UTC
RP/0/RP0/CPU0:ASBR1(config)#interface gigabitEthernet 0/0/0/2
RP/0/RP0/CPU0:ASBR1(config-if)#shut
RP/0/RP0/CPU0:ASBR1(config-if)#commit
Sat Feb  8 17:45:54.972 UTC
RP/0/RP0/CPU0:ASBR1(config-if)#no shut
RP/0/RP0/CPU0:ASBR1(config-if)#commit
Sat Feb  8 17:46:12.747 UTC
LC/0/0/CPU0:Feb  8 17:46:12.856 UTC: ifmgr[324]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/2, changed state to Down 
RP/0/RP0/CPU0:ASBR1(config-if)#LC/0/0/CPU0:Feb  8 17:46:13.480 UTC: ifmgr[324]: %PKT_INFRA-LINK-3-UPDOWN : Interface GigabitEthernet0/0/0/2, changed state to Up 

RP/0/RP0/CPU0:ASBR1(config-if)#
RP/0/RP0/CPU0:ASBR1(config-if)#
RP/0/RP0/CPU0:ASBR1(config-if)#
RP/0/RP0/CPU0:ASBR1(config-if)#
^XRP/0/RP0/CPU0:ASBR1#sh mpls interfaces   
Sat Feb  8 17:46:23.230 UTC
Interface                  LDP      Tunnel   Static   Enabled 
-------------------------- -------- -------- -------- --------
GigabitEthernet0/0/0/0     Yes      No       No       Yes
GigabitEthernet0/0/0/4     No       No       No       Yes
GigabitEthernet0/0/0/2     No       No       No       Yes
GigabitEthernet0/0/0/1     Yes      No       No       Yes
RP/0/RP0/CPU0:ASBR1#

Then all of my traces and pings work ok. 

Has anyone seen anything like this or know why this is happening? 

Could is be the order that I configure things or the OS version that I'm using (xrv9k 7.9.2).

Thanks in advance for any help.

[Harold Ritter]

Hi @steven.crutchley ,

Not something I have come across. Can you please provide the output for the following commands from both asbrs:

show runn interface gi0/0/0/2

show runn router static

Regards,

[steven.crutchley]

This is what I've configured on the NNI to the next ISP:

RP/0/RP0/CPU0:ASBR1#sh run interface gigabitEthernet 0/0/0/2
Sat Feb 15 18:39:36.789 UTC
interface GigabitEthernet0/0/0/2
 description link to ISP2-ASBR1
 ipv4 address 10.1.1.1 255.255.255.0
!

RP/0/RP0/CPU0:ASBR1#sh run router static
Sat Feb 15 18:39:48.026 UTC
router static
 address-family ipv4 unicast
  10.1.1.2/32 GigabitEthernet0/0/0/2
 !
!

RP/0/RP0/CPU0:ASBR1#

The /32 static is all there. 

This is a difficult one to replicate. I've just reconfigured everything from scratch and it has worked ok without the need to shut/unshut. I think it might be something to do with the order in which I apply the commands but I can't figure out the exact sequence that causes it. It's happened several times though. 

[MHM Cisco World]

Sequence is make IGP sync first then apply mpls command with take care of router-id mpls use.

Router-id must reachable before mpls is established.

To solve this issue permanent use mpls igp sync 

MHM

[steven.crutchley]

The interface in question is not running LDP. It is a peering interface to another ASN. Only BGP is running across this link.

[Harold Ritter]

Hi @steven.crutchley ,

I would not worry too much about it. It might just be a bug linked to the virtual platform.

[steven.crutchley]

So, I've figured out that the order in which I apply the config affects whether or not this bug appears. 

If I apply everything at once (static routes to eBGP peers, VPNv4 neighborships etc) the bug appears and the external interfaces are not MPLS enanled.

If apply apply the static routes first, commit and then apply the rest, the bug still occurs.

But if I apply everything except the static routes first, commit and then add the static, the interfaces come up as MPLS enabled and I don't have any problems.

Im still trying to find a way to prevent this behaviour by providing more config, or different config, but it seems like an order of operations thing.

[Harold Ritter]

Hi @steven.crutchley ,

> If apply apply the static routes first, commit and then apply the   > rest, the bug still occurs.

I quickly tried the following with version 24.x and it works.

I would suggest moving to a more recent version.