P router with LDP and RSVP

[sergeyrar]

Hi,

I have an SP core with LDP and RSVP enabled on all interfaces.

For a FEC for which a label was advertised using LDP and RSVP, which should be used to actually forward traffic on transit P routers?

Is there any defined behavior for this?

This is interesting, since an RSVP tunnel may be up - but the actual routing may not point to exit the tunnel.

So does LDP take over when it is on ?


Thanks,

[icecream-guy]

OT note, if you are running IOS or IOS XE, and have VRF's configured, you might want to check out advisory cisco-sa-2013-09-15-rsvp.

[that1guy15]

If I understand your question, to use the RSVP tunnel routing must direct traffic to that tunnel. If not then yeah LDP will try to direct the traffic.

[sergeyrar]

lol... I figured out that both are installed in FIB.
Which actually makes sense.
Why not install both ... ?
The router receives a label and swaps it according to what he has in FIB and forwards the packet.
He doesn't care if the traffic got there through an RSVP tunnel or via an LDP signaled tunnel

[sergeyrar]

If I understand your question, to use the RSVP tunnel routing must direct traffic to that tunnel. If not then yeah LDP will try to direct the traffic.

Yeah, but this happens at the PE router.. which then installs only what he actually uses to route traffic.

The P router in the middle doesn't even aware of PE router's decision

[wintermute000]

thats an interesting question. As I get further in my SP reading I'll make a note.
I skimmed over all the MPLS-TE stuff in my RS studies


In JUNOS the concept of AD still applies, RSVP > LDP as you'd expect


http://www.juniper.net/techpubs/en_US/junos15.1/topics/reference/general/routing-protocols-default-route-preference-values.html

[srg]

Since MPLS is in essence source routing, the PE will make the decision and the P router will do label switching based on the path chosen by the PE.

[wintermute000]

Yeah he's asking how the pe decides

[sergeyrar]

Yeah, that's interesting too.
But actually I wondered what the P router installs in FIB - later found out that it installs both RSVP and LDP label information for PE's loopback - which makes sense ... since P router doesn't even know how PE decided to route the traffic.

[wintermute000]

Doing some quick reading - MPLS TE is manually specified in Cisco land. Though that's old info (reading the classics - MPLS Fundamentals, VPN Architectures vol 1+2 etc.), I know there's newfangled stuff now like auto TE tunnels.

IIRC my Juniper SP stuff (for shame LOL - but that's what happens when you study it and never apply it in battle for over 12 months... ), both RSVP and LDP enter the inet.3 table and its a straight up AD comparison like normal routing, really nice and clean IMO.


Yeah the P still has no idea, it just looks at the label and sends it onwards.

You going down the SP track as well?

[sergeyrar]

Not yet, maybe I'll do it sometime in the future.

It's my job, I test SP routers... just got some weird shit going on

[wintermute000]

I'm slogging through MPLS Fundamentals chapter 8 (MPLS-TE) and its head spinningly complex..... there doesn't appear to be a quick answer to your question, it depends....

Forwarding Traffic onto MPLS TE Tunnels
Creating a TE tunnel and having it operational is one thing. Making sure that it is used to forward
traffic is another. You can enable the TE tunnel to forward traffic in six ways:
■ Static routing
■ Policy-based routing
■ Autoroute announce
■ Forwarding adjacency
■ Direct mapping of AToM traffic onto TE tunnels
■ Class-based tunnel selection

The above quote also doesn't appear to cover FRR scenarios

[sergeyrar]

 Thanks:-)

My concern was regarding P routers.

Since both LDP and RSVP LSPs are signaled for FEC a.b.c.d/32, a P router will just swap the labels according to the corresponding entry in FIB ( P router doesn't even process the route in RIB )

Moreover, the P router isn't aware of ingress PE's choice of how to actually forward the traffic.

[wintermute000]

Well yes, a P router just flicks the frame onwards according to the label. Whether it learnt it via LDP or RSVP and is actually a TE label is irrelevant.
There are caveats though re: MPLS VPN and certain MPLS-TE topologies, in broad terms you don't want to end up with the P router receiving the bottom VPN label, so design considerations are required