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

MPLS TE with Per VRF / VPN

Always we can see that in service provider network there will be primary link & Secondary link but only one link will be utilize. Implementing Policy base routing somehow we manipulate the route,

But still it required man force to monitor the link & manipulate the route as per requirement. It becomes very chaotic to do route manipulation every time in service provider network. So the solution is to have a technology where we can use un-equal load balancing or path manipulation as per requirement. So it give us scalability to use or chose any path that we required, may be it can primary path, backup path or both path i.e. un-equal circuit load balancing . So the solution is  MPLS- Traffic Engineering , using MPLS traffic engineering we can manipulate the route as per our requirement where you can use each circuit or you can have route path on-demand.MPLS TE with Per VRF.jpg

MPLS Traffic Engineering (MPLS TE) is a growing implementation in today's service provider networks. MPLS adoption in service provider networks has increased manifold due to its inherent TE capabilities. MPLS TE allows the MPLS-enabled network to replicate and expand upon the TE capabilities of Layer 2 ATM and Frame Relay networks. MPLS uses the reachability information provided by Layer 3 routing protocols and operates like a Layer 2 ATM network. With MPLS, TE capabilities are integrated into Layer 3, which can be implemented for efficient bandwidth utilization between routers in the SP network.

Below link show an example where we have redundant link in service provider network, Without MPLS Traffic engineering we can see that we can only one link will be utilized . But after implementing MPLS Traffic engineering we can use both circuit as per our requirement or on-demand path manipulation per VRF.

Below link contain the complete document for MPLS TE with Per VRF/VPN


Chetan Kumar Ress

Version history
Revision #:
1 of 1
Last update:
‎08-09-2010 01:00 PM
Updated by:
Labels (1)
Everyone's tags (3)
New Member


do you know is there some guideline how to accomplish this MPLS TE  with per VRF/VPN feature in IOS XR. I cannot configure it under VRF, tried also to find it somehow under BGP VRF but without success.

thank you very much

Hello TOM,

you can always use the RPL in XR to match a specific RT (extcommunity) and set the next-hop as a the destination IP Address of your local tunnel.

you create a loopback XY on the remote (tail end)  XR router that should be advertised by the IGP.

you create a route-policy on the head end router to match the RT for your vrf and set the next-hop as the loopback XY. You create a tunnel-te with destination loopback XY.

Sample Config ( is th remote router bgp-id on which you peered vpnv4 and is the loopback xy used for tunnel selection):

route-policy PER_VRF_TE

if extcommunity rt match-any (1:1) and next-hop in ( then

set next-hop




router bgp 1234


address-family vpnv4 unicast

route-policy PER_VRF_TE in

Finally add a static route 

router static address-family ipv4 unicast tunnel-te 101 tag 101



New Member


thank you very much for your effort. This is definitely way to go.


New Member

I have a client that is trying to do per-vrf MPLS-TE in IOS-XR 5.3.3 as per the following link:

In the past one could simply set the BGP Next-hop under the VRF configuraion on a per VRF basis which was really nice. However that option is not available in IOS-XR.

The client can create a route-policy under BGP and set the BGP Next-Hop when advertising the route to the VPNV4 Route Reflector, however that would mean that anytime a new service requires per VRF MPLS TE, the route-policy to the VPNV4 RR may have to be modified.

Is there any way to set the BGP next-hop on a per VRF basis similar to IOS so that when the route is advertised to the VPNV4 RR it advertises it with the modified BGP Next-hop.

I have tried the following without success:

  1. Created an export-policy under the VRF configuraiton and tried to set the next-hop but that was not supported.
  2. Created a route-policy to the next-hop and attached it to a redisribute connected statement under the VRF.

          --This was interesting as it doesn't install the route as the next-hop is not reachable. That is because the next-hop is the global.

          -- I tried creating a loopback in the VRF and setting the next-hop to that loobpack and that causes the route to be installed in the BGP VRF table correctly. However, when advertising it to the VPNV4 RR, it sets the next-hop to itself as update-source loopback 0 is specified.

Please help with any other suggestions.

New Member


it seems there is no such elegant solution, at least I cannot find it and I'm looking for quite some time. I don't understand why they didn't implement it in IOS XR. All sugestions I have seen are going in direction to implement some kind of route-policies which complicates things. Solution is simple by itself, but when you have many TE-tunnels you end up with messy configuration in VPNV4 part.