Only 1 MPLS TE tunnel between directly connected routers.Routes some traffic and some not???

[Vadym Belyayev]

Hello,

I have a rare issue, which I cannot explain.

I have a simple scenario

LAN1===4500===OSPF===R1_6500======OSPF======R2_6500======tunnel mpls TE with autoroute=======R3_2900====1900===LAN2

1. I enable an MPLS TE tunnel between R2 6500 router and 2900 router

2. Everything is ok until I enable autoroute on R3 2900 router. Lan1 cannot reach printers in Lan2 via web. ICMP WORKS IN ALL CASES!!, however, the ICMP packets (172 bytes) generated by Solarwinds network browser discover only 30% of network Lan2..

Once you disable autoroute on 2900, it works normally..

3. I have implicit null label on 2900 and on R2 6500 (if I enable autoroute on both tunnels), CEF seems to be ok, OSPF also, routes are present, however, some traffic simply does not pass through

4. I fixed it building  a second tunnel from 2900 to R1 6500 and it works ok, but I cannot understand what makes it behave this way?

[Akash Agrawal]

Hi Vadym,

Is issue still persisting? If yes, it is first important to check direction of packet drop which you can do with below steps

1. Put forward and reverse both via secondary ISP on R1, and check if all applications working

2. Put forward via secondary ISP and reverse via R1,R2,R3 path, and check if all applications working

3. Put forward via R1,R2,R3 path and reverse via secondary ISP, and check if all applications working

share result of above steps.

Now since some applications between two LAN working fine, i would not suspect any issue with routing or programming but there could be some feature applied which may affect IP traffic and transparent to MPLS traffic.

Are all applications working fine when there is no TE configuration and forward/reverse going via R1-R2-R3 path? When we are enabling TE between R2 and R3 (2900) with auto route announce, LSP is getting broken on R2. It would be worth to try enabling LDP session over Tunnel to have LSP intact end to end. You need to configure "mpls ip" under tunnel on both R2 and R3 and "mpls ldp discovery targeted-hello" on both the routers.

Regards,

Akash

[Vadym Belyayev]

Hello Akash,

Yes, the issue is still there.

I will try the scenarios you posted and let you know.

[Vadym Belyayev]

Akash,

I enabled mpls ip on both R2 and R3 (tunnel 104) and it started working..

I also enabled mpls targeted hello ACCEPT on R3 only.. because I did not know if this was the command that you wanted.. but anyway it works with LDP.

Why do I need to enable targeted-hello and why do you think the LSP is broken if we do not use LDP?

[Akash Agrawal · Accepted solution]

Hi Vadym, 

Perfect :)

Why do I need to enable targeted-hello

[Akash]

Nondirectly Connected MPLS LDP Sessions

If the LSR is more than one hop from its neighbor, it is non-directly connected to its neighbor. For these nondirectly connected neighbors, the LSR sends out a targeted Hello message as a UDP packet, but as a unicast message specifically addressed to that LSR. The nondirectly connected LSR responds to the Hello message and the two routers begin to establish an LDP session. This is called extended discovery.

The default behavior of an LSR is to ignore requests from other LSRs that send targeted Hello messages. You can configure an LSR to respond to requests for targeted Hello messages by issuing the mpls ldp discovery targeted-hello accept command.

 why do you think the LSP is broken if we do not use LDP

[Akash]  If LDP is not enabled over tunnel, R2 will not advertise any label to R3 over tunnel interface and R3 will send unlabeled traffic to R2 [only rsvp label which is implicit null] , and ip lookup will happen on R2 so this is not end to end LSP. If ip loopup is happening on core router, i would say LSP is broken here. But if LDP is enabled over tunnel, R2 will advertise local label to R3 over targeted LDP session. L3 will send labeled packet [implicit null for RSVP, IGP label advertised by R2] to R2 and R2 will do label swapping and send traffic to R1. All the path label switching and LSP is intact.

If it would have been L3vpn scenario, traffic would have been blackholed on core router where tunnel is getting terminated. In your case all core routers are having routes to destination hence reachability is there but LSP still broken.

Regards,

Akash

[Vadym Belyayev]

Akash, thank you very much for your help. If you dont mind, can I ask you a couple of more questions?

1. I heard that RSVP requires full mesh of tunnels to work correctly, do you think this is related to what I read? Maybe it has to do with the label assignment mechanism? Because if I create another LSP from R3 to R1 going through R2, cef has a lable, since it is a 1 hop tunnel!
2. What tools do you use to confirm that the LSP path is broken? Just logic?
4. Is the condition of "only MPLS lookup to occur along all the LSP path using labels" for it to function properly?

[Akash Agrawal]

yes if tunnel is PE-to-PE then LDP over tunnel is not required. If you are terminating tunnel to any core router wihout enabling LDP on it then it would result in LSP break. It is like one core network link is running with out LDP.

To check LSP you can use "ping mpls ipv4 <destination>" , "trace mpls ipv4 <destination>" . If you dont have access to network to use these tools then with logics only.

It is not manadatory that only label lookup has to happen all the way and especially in your case, core router has routes to destination so even after LSP break, end to end reachability is there. but possibly as i mentioned before, there could be some feature applied on core interfaces which affects ip packet and transparent to MPLS packets.

[Vadym Belyayev]

Akash, thanks

I do not use this terminology and do not have P o Pe, I have a MAN network and everything belongs to MAN, there is no client equipment. So sometimes it results for me a bit difficult to understand, since there are no borders as they would exist in an ISP network.

I will study traceroute mpls, I think it is very useful. I am studying all possible scenarios of LDP/RSVP one over another in different situations, so thanks a lot for the info.

I found this source which resulted very useful

http://www.exzaktec.com/2009/10/ldp-rsvp-te-both/

it says:

There is another option in using both LDP and RSVP-TE, and that is to use each in a specific part of the network.  The worry here is that we need end-to-end LSPs, and if LDP is turned on in only pieces of the network, LSPs will only work to those endpoints where we have a continuous labeling function.  If the LSP is broken, any services carried over that LSP will fail to reach the destination.