cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2102
Views
20
Helpful
8
Replies

VRF traffic via MPLS TE tunnel

mheusinger
Level 10
Level 10

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

8 Replies 8

olorunloba
Level 5
Level 5

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.

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

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.

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México

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

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

Getting Started

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: