on 08-09-2010 01:00 PM
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 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
http://chetanress.blogspot.com/2010/08/mpls-traffic-engineering-with-per-vrf.html
Regards
Chetan Kumar Ress
Hy,
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 (10.10.10.10 is th remote router bgp-id on which you peered vpnv4 and 1.1.1.1 is the loopback xy used for tunnel selection):
route-policy PER_VRF_TE
if extcommunity rt match-any (1:1) and next-hop in (10.10.10.10) then
set next-hop 1.1.1.1
endif
pass
end-policy
router bgp 1234
neighbor 10.10.10.10
address-family vpnv4 unicast
route-policy PER_VRF_TE in
Finally add a static route
router static address-family ipv4 unicast
1.1.1.1/32 tunnel-te 101 tag 101
HTH,
Michel.
Hy,
thank you very much for your effort. This is definitely way to go.
regards
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:
--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.
Hy,
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.
regards
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: