Static route to send select VPN traffic through MPLS TE tunnel

[seanxwang]

I am working with ME3600 as PE which does not support policy routing. I am trying to use static routes to achieve the same.

The basic setup is standard and works well. MPLS traffic engineering tunnel are set up between PE, as shown here. I’m not showing ospf, rsvp etc since I’m not asking for basic TE setup.

interface Tunnel2

ip unnumbered Loopback1

mpls ip

tunnel destination 10.249.0.11

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng priority 7 7

tunnel mpls traffic-eng bandwidth 100000

tunnel mpls traffic-eng path-option 1 explicit name tunnel_path_2

When I turn on “autoroute announce”, I noticed LSP path is created (as shown in forwarding table below). Ping and everything works. But at this point all the VPN traffic goes through the tunnel.

PErtr1#sh mpls forward

Local Outgoing   Prefix           Bytes tag Outgoing   Next Hop

tag   tag or VC   or Tunnel Id     switched   interface

…

19     Untagged[T] 10.249.0.1/32     0         Tu2       point2point

20     Pop tag [T] 10.249.0.11/32   0         Tu2      point2point

21     Untagged[T] 10.249.0.136/30   0         Tu2       point2point

23     Untagged[T] 10.249.0.144/30   0         Tu2       point2point

My objective is to send select customer traffic through a certain tunnel based on end points (here using the example of from 198.8.232.1 to 199.115.32.1).

To do that, I remove “tunnel mpls traffic-eng autoroute announce”, and replace with

“ip route vrf <customer> 199.115.32.1 255.255.255.255 tunnel2”

Note 199.115.32.1 is a customer end point, so the static is in VRF. This is likely the questionable part, whether it works that way.

Note the tunnel has always been up. At this point the LSP entries pointing to tunnel path are gone, and no new ones are created for the static path. As a result, no ping will get through. It seems traffic gets dropped on tunnel outbound, since there is no tag switching information available to transport the traffic over the other end of tunnel (remote PE).

Is this particular use of static supported? I have seen examples of using static for tunnel, but nothing similar to a VRF specific static to tunnel. Did anybody ever make something like this to work? Again, the requirement is to use TE tunnel for specific VPN endpoints.

Also, could there be platform limitation that limits policy or static routing on TE tunnel? I really appreciate your thoughts and feedback.

[Mohamed Sobair]

Hello,

No, this is not the right config. let me explain why:

a VRF Prefixes is carried between Distinct PEs over MP-BGP, and We still need MP-BGP to carry LAbeled VPNv4 and Labeld VPNv6 Prefixes. a Traffic Engineering tunnel by itself doesnt create an end to end LSP, the LSP is created between the two IBGP loopbacks.

For traffic traversing the TE tunnel, the Label Stack will contain three Labels, the Tunnel Label which is the TOP label,  The IGP label and the VPN label which is the bottom label. thats why we still need the Customer VPN prefixes to be carried over the MP-BGP even though we have a Tunnel, but we can Enforce the Traffic to travers the TUNNEL to reach the Egress LSR which termibnates the LSP.

Now, with the Auto route announce TE tunnel, the Tunnel announces itself to be used for all traffic between ingress and Egress Label Switch routers LSPs , there are multiple ways you can forward traffic through the tunnel, either by using Static routes, Policy based Routing OR Autoroute announce as stated in the books.

However, if you have a TE Tunnel and you would like ONLY Specific VRF to traverse through that Tunnel, you would need to influence the BGP NEXT-HOP and enforce the IGP traffic to use this tunnel to reach the BGP next hop.

FOr example:

You would need to create a new Loopback interface on the Egress PE, and in the Ingress PE you create static route for that Loopback pointing to the Tunnel Interface, so that when BGP try to establish an end to end LSP, it uses the TE tunnel interface to reach the BGP next-hop. 

So your configuration will look like this:

ip vrf Customer

rd 1:1

route-target both 1:1

bgp next-hop (NEW LOOPBACK on the Egree PE) -------------- You need to add this to your VRF

ip route x.x.x.x 255.255.255.255 tunnel2 ----------------------------- You need to add this So that the BGP next-hop is                                                                                       reachable  through the Tunnel (On the INGREE PE)

Hope this Helps.

Mohamed

[trythebest]

I am researching about 6VPE associate TE tunnels.But,In mode: Vrf definiton A....Address-family ipv6 ...not support BGP next-hop command,Mohamad Sobair.How must I do to send select VPNv6 traffic through MPLS TE tunnel.Thanks all for helping:)

[Vaibhava Varma]

Hi Sean

SInce TE Tunnels are used to forward traffic down the TE Tunnel between the Tunnel Headend and Tunnel Tailend for all routes learnt behing those endpoints we can not forward traffic for VPN destinations using vrf specific static routes pointing to the TE Tunnel.

In my understanding assuming a case of vpn traffic forwarded between two PE routers  a complex way to achieve the objective using different TE Tunnel for forwarding different VPN traffics would be to use different loopbacks between the PE routers and create separate MP-iBGP peering between the 2 PE routers on those loopbacks and do route-filtering under the MP-iBGP peering so that we learn the desired routes via the desired TE Tunnel MP-iBGP Next-Hop and the VPN traffic will traverse accordingly through the desired TE Path.Again this is not a scalable and very complex solution but I think can work in smaller requirements.

Regards

Varma

[seanxwang]

Excellent explanation, Mohamed. The three label model made it clear.

The example provided makes sense for directing specific (entire) VRF traffic down a tunnel, based on BGP next hop. For my specific requirement, which is to direct only specific customer endpoint traffic within the VRF down tunnel, I think I need to adjust the general approach.

I have to say I got more out of this forum in a few paragraphs, than numerous documents I have come across.

Thanks,

sean

[seanxwang]

Varma, you definitely understand what I was trying to achieve. Your suggestion to create parallel BGP peering for specific traffic flow makes sense, and is probably the only technically viable way to achieve static redirection.

I also agree the complexity certainly will take the final outcome further away from an elegant solution.

I will revisit the apprach here, and perhaps do some experiments. One alternative, although more suitable as a point solution, may be to use a special unused EXP value to "mark" those traffic, and use CBTS to direct to specific tunnel.

Thanks,

sean

[Vaibhava Varma]

Hi Sean

CBTS would be a very good solution provided we can reserve one EXP specifically for this purpose but I think since we have just 8 EXPs this would be again not a scalable solution.

Regards

Varma

[seanxwang]

Varma, I definitely agree CBTS is far from the ideal solution.

This perhaps highlights the shortcoming of original MPLS header design.

It is desirable to have something like a tag field as extension to MPLS shim header. In CiscoLive there a session about future MPLS directions, there are some RFC groups working on "channels" and MPLS-TP objects which contains something like a tunnel ID. Too early to tell whether that's going to be helpful or even relevant.