12-14-2005 08:50 AM
Hi,
is it possible to send VRF traffic down a specific MPLS TE tunnel, which does terminate only on ONE of two PEs?
So f.e. CE1 - PE1 - core1 - core2 PE2 - CE2 and a MPLS TE tunnel from PE1 to core2. Can we send only traffic from CE1 to CE2 down the TE tunnel?
Regards
Martin
12-14-2005 12:36 PM
Yes, it should be possible. Check the following link, it has a similar example.
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a0080125b01.shtml
While the example in the link above used the autoroute feature, you could use static route pointing to the tunnel interface for the BGP next-hops. This will even be required, if you require only a VPN (or a subset of VPNs) to use the TE. You will need to modify the BGP next-hop attribute in the VRF configuration (Have to thank Harold for that tip again), and using the appropriate static route.
Watch out for the following,
1. Enable TDP on the TE tunnels
2. Use consistent masks for the static routes.
3. Forwarding of MPLS VPN traffic is based on the BGP next-hop attribute.
12-14-2005 11:08 PM
Hi,
thank you, I know the link and this is simple. But I do not want all traffic down the TE tunnel (which is the case when the BGP next hop of PE2 is seen through the tunnel) just for a specific VRF.
I did
ip route vrf CE 1.0.0.0 255.0.0.0 tunnel1 192.168.1.2
where 192.168.1.2 is the BGP next hop of PE2. But then cef does only take the tunnel label and the VPN label ... but the LDP label for PE2 bgp next hop is missing.
So without static route it is TL LDPL VPNL with static route it is TL VPNL (where TL=tunnel label, LDPL=LDP label for PE2 from core2, VPNL=VPN label from PE2). This works of course when the tunnel terminates on PE2.
Could this missing LDP label be an IOS bug? It´s a test lab so I just want to find out if I miss something substantial.
The second way to implement would be to use "bgp next-hop loopback99", configure a loopback for each VRF on PE2 and route this statically through the tunnel. But in reality wouldn´t that get a little messy assuming dozends of VRFs on a PE?
Regards
Martin
12-15-2005 03:29 AM
I do not think it is a bug. Because the route was not learnt from BGP, there is no label for the BGP next-hop. There is a VPN label, because the route is a vrf route, and there is TE label because it is pointing to a traffic eingineering tunnel.
I think the solution as you have rightly said is to use the bgp next-hop command within the vrf. Except that, with multiple VRFs, you could use the same loopback address. Hence, you will be required to have one extra loopback on PE2 and one extra static route on PE1 for the traffic engineering tunnel. This does not look messy to me.
Please let us know how it goes.
12-15-2005 05:31 AM
This is normal behavior. You are pushing VRF traffic through the Tunnel, which is why you get the tunnel label but the next hop 192.168.1.2 is not resolvable via the tunnel so no LDP label gets assigned.
One way to do that is to configure the next hop via the tunnel (ip route 192.168.1.2 255.255.255.255 tu1).
If you only want one vrf to use the tunnel then you can assign a different BGP next hop to that specific VRF on the egress PE using the bgp next command as follow:
ip vrf red
rd 1:2
route-target export 1:1
route-target import 1:1
bgp next-hop Loopback2
!
You can then configure a static route for that specific next hop through the tunnel. All the other next hops should take the normal path (LDP path).
Hope this helps,
12-15-2005 06:39 AM
Thank you for the examples, they are working and I have tested them - no problem.
In my setup the CE2 network IS learned via BGP and the VPN label IS applied using the static route!
Harold, why do you write the next hop is not resolvable via the tunnel? There is a targeted LDP session between PE1 and core2 and the Label is in the LIB of PE1. Also the VPN label is learned through BGP and is applied to traffic following a static vrf route - the BGP route is not even in the VRF routing table (AD) - yet the VPN label is applied! If I understand you right, Harold, you would suspect only the tunnel label. But in reality there is also the VPN label applied.
My understanding was, that
ip route vrf CE 1.0.0.0 255.0.0.0 tunnel1
will not work, as LDPL and VPNL are not applied and the packet ends in the global routing on core2 i.e. is dropped. Verified this in the lab.
But with
ip route vrf CE 1.0.0.0 255.0.0.0 tunnel1 192.168.1.2
everything could (should?) work as normal.
Call it a feature request ;-) but all the info is in the PE1. CEF just doesn´t build the proper label stack to give connectivity.
What I would like to see happening by applying the above "ip route" command:
1) tunnel1 -> apply tunnel label learned from RSVP (core1)
2) 192.168.1.2 -> apply LDP label learned through targeted LDP from tunnel endpoint (core2)
3) 1.0.0.0/8 -> apply VPN label learned from BGP (PE2)
result: TL LDPL VPNL applied in CEF and CE connectivity.
Well so to settle the discussion:
Cisco (=Harold) says it is not implemented. So it´s not a bug but a feature ;-)
I say it could be implemented according to my understanding and the above description. Comments?
Regards
Martin
12-15-2005 08:14 AM
Martin,
CEF doesn't resolve 192.168.1.2 via the tunnel , right. (sh ip cef 192.168.1.2).
CEF will consider the LDP label if it comes from the neighbor matching its next hop. In this case 192.168.1.2 doesn't resolve though the tunnel, therefore CEF doesn't consider the LDP label received through the tunnel.
Forcing the vpn prefix to go down the tunnel using a static route doesn't change the above requirement.
Hope this helps,
12-15-2005 08:30 AM
Ooops,
you are right of course ... I was flying high with VPN and TE and didn´t see the basic stuff.
This means PBR and static routing can only be used to force traffic from a VRF down a tunnel when it terminates on both PEs.
Nevertheless ... would be a nice feature and could be done, couldn´t it?
Something like: static route to interface with "normal interface - normal behaviour" and if TE tunnel - use LDP label of tunnel endpoint)
Cheers
Martin
02-21-2006 07:29 AM
Hi Martin,
can You post Your final configuration.
In our test lab there are a issue. In the Routing Table on CE1 You can see all CE2-Routes. A Ping to this routes are not possible.
Mike
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide