mpls traffic-eng router-id

[yuchenglai]

Hi all,

In a typical service-provider iBGP network, customer BGP routes typically are advertised by the customer facing PE with the next-hop being the the PE's loopback.  That being the case if other PE router want to build TE tunnels, then it makes sense that the TE tunnels are built with tunnel destinations that reflect those next-hop addresses...in this case the loopback addresses of those PE routers. 

However, what I don't quite understand is whether or not the MPLS TE router-id needs to be the same address as the opposite end's TE tunnel destination as well as be the same as the local corresponding iBGP update source loopback address.

Can someone please help?

Best Regards,

David

[ugot2nome · Accepted solution]

Hi David:

In simple terms, the answer is no. You are mixing two concepts here. The primary reason to prefer a loopback IP vs an interface IP as the Tunnel endpoint is if an alternate path exists to reach the destination PE. If a path did exist, and the final IP (as defined in the explicit or dynamic path) belonged to the interface IP, then when the primary path fails the Tunnel will go down as this IP is now unreachable. Had it been a loopback, after IGP converges the alternate path would be used to reach that PE w/o breaking the tunnel parameters. Be cognizant that MPLS will now use a fresh set of labels from the Label Binding Database and put them into the Fowarding Label Database as the Top Label.

This is the same reason why the IBGP is peered using Loopback addresses between Routers. Its primary purpose is to keep the TCP session alive as long as an alternate path exists to reach the far end loopback; something you would expect in an ISP environment.

So, for stability you will end up using some Loopback IP as both the MPLS TE Router-ID and the Tunnel-Endpoint IP. The caveat, is that an alternate path should exist else it defeats the purpose.

I hope this makes sense.

Regards, Brian

[yuchenglai]

Brian,

I understand why the iBGP update-source should be tied to a loopback as well as why the MPLS-TE tunnel destination on PE routers should point to the iBGP update-source loopback address of the other PE routers.

I'm just wondering about the significance of the MPLS-TE router-id having to use the same iBGP update source loopback ip.  Are you implying that the MPLS-TE tunnel destinations have to point to the iBGP update-source loopback ip of the other PE routers?  If so, what happens if you don't?

Thanks for your help.

David 

[yuchenglai]

Hi Brian, just re-read your post again.  I think you have answered my question.  Thank you.

[ugot2nome]

Hi David:

I am glad it makes sense. Just ensure that the Loopback IP used for the MPLS TE Router ID is ALWAYS a /32 address. You are almost guaranteed stuff to not work if the prefix is a /24. This is because although the label does get generated for the /24 prefix, the far end PE expects a label for the /32 prefix and thus will not be able to use the tunnel to put traffic back into.

[Peter Paluch]

Hello,

Particularly in the case of OSPF-supported traffic engineering, it would be actually very interesting to see how things break if the OSPF-TE RID is different to OSPF RID to LDP RID. I personally am not quite sure myself about the OSPF-TE RID - where is it exactly used and how does it fit into the entire picture.

Or better said, why is it even possible to have two OSPF RIDs - one for regular operation, and one for TE.

Best regards,

Peter

[ugot2nome]

The OSPF RID under a routing process is merely cosmetic and does not need to be an actual live IP when on the device when defining it. For the MPLS TE Router ID, an actual Label is generated by LDP for this prefix and will be used when pushing traffic into the Tunnel.

[Peter Paluch]

Hello,

A small correction: with respect to OSPF operation, the OSPF RID is far more than just a cosmetic nuisance. The importance of OSPF RID can not be overstated, as it is the unique identifier of a router in the OSPF routing domain. As all LSAs are signed by their originators and they are linked one to another using their RIDs (with the sole exception of LSA1 pointing to a corresponding LSA2 by the IP address of the corresponding designated router), OSPF RIDs play a crucial role in building and interpreting the link-state database.

However, it is true that from a user's view, the OSPF RID does appear just as a 4B number, nothing more.

Regarding the OSPF-TE RID, you have made a very good point - I'll try to dig it up in RFCs for more details but your explanation sounds appropriate. Thanks for that!

Best regards,

Peter