Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

mpls te question


there are two path creation using MPLS TE

1. Explicit Path , 2. Dynamic Path.

If I configure the Explicit path, It depend on the IGP?, Am I configure the RSVP to config

explicit path?

In my throught, When I using Dynamic path, I must enable the IGP what is needed to calculate

Best TE path. Is it alright?


Re: mpls te question

That's correct. Generally TE tunnel is either dynamic or explicitly defined. In dynamic path, you just need to configure tunnel destination's ip address, ignoring in between hops in the paths whereas in explicitly defined path you need to define/mention all the hopes involved in the paths to the destination.

However, if you want to have automatic path calculations and automatic rerouting of IP traffic onto MPLS TE paths, you have to use dynamic tunnel with OSPF or IS-IS. Here link state protocol (IS-IS or OSPF) is used with enhanced link state advertisements to track network capacity and to ensure that the tunnel does not create a routing loop. The actual signaling for dynamic tunnel establishment is based on RSVP, which acts to reserve bandwidth on a link.

Also, in some cases, MPLS-TE tunnel can be configured to use multiple paths (explicit as well as dynamic) from the source to the destination so that it can choose the path it needs in the order of preference.

So now to answer your questions:

You don't require IGP if you are using explicit path. Although I haven't tried configuring explicit path alone in lab/real world, but considering RSVP's function, I guess that you don't require RSVP in the case where you are using explicit path only.

Also you are right when you say that IGP(OSPF or ISIS) is required in order to make dynamic path work as these two protocol(OSPF and IS-IS) have been provided with extensions to enable their use in an MPLS TE environment to propagate information pertaining to resource availability and in dynamic LSP path selection.

To give you real world scenario, in our SP network design, we are using dynamic tunnel with OSPF as IGP and no explicit path at all.



Re: mpls te question


MPLS TE config must be enabled under IGP config irrespective of explicit or dynamic paths. By enabling MPLS TE, will enable RSVP signalling across the routers from source to destination.

Without enabling TE under IGP, RSVP will not distribute the labelling info from destination to source (either in explicit and dynamic)...because in our network with explicit path, TE tunnel comes up only when TE is configured under IGP...

router ospf 200

mpls-trafficeng router-id lo0

mpls trafficeng area 0



Re: mpls te question

Hi, Arun

When I said you don't require IGP incase of explicit path, I should have mentioned feature called 'Verbatim Path Support'(see the link below). With the support of this feature, it is possible to have explicit path in the TE network without configuring link state IGP.When this feature is enabled, the IP explicit path is not checked against the TE topology database.

As per my knowledge, currently this feature is only supported in certain Service Provider images on the platform such as 7200, 7600, Cat6K.



Re: mpls te question

Hi Yagnesh,

The document is very useful...

I would like to confirm.. With this Verbatim Path Support Feature, i can even run TE tunnel betwen two different OSPF area's (Inter-Area TE tunnel) cos we are not going to configure any IGP extensions with MPLS TE with Explicit paths rite.. Only thing is I would upgrade the IOS of my PE to support Verbatim Path Support (as part of OSPF sub-area)...

Thanks in advance..

New Member

Re: mpls te question

Just to correct a small inaccuracy.

You still need RSVP-TE support on the mid-nodes even if you are using verbatim feature. Verbatim feature will cause head-end router perform regular SPF algorithm rather than cSPF. Since head-end will be unable to perform cSPF it will rely on explicit path (verbatim), which will be put it in ERO object in RSVP Path messages, so again RSVP-TE support is still required even if you are using non-link state protocol.

One more comment. Even through cSPF is not performed on a head-end, each mid-node still verifies (locally on the device itself) that outbound interface for RSVP Path message is able to provide bandwidth reservation required, so you still have to configure all RSVP bandwidth commands even when using verbatim feature...


CreatePlease to create content