cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3153
Views
0
Helpful
9
Replies

MPLS-TE with PBR

william.caban
Level 5
Level 5

Hi,

I'm trying some configurations MPLS-TE with PBR in 7600 with SRC3 code and has not been able to make it work.

I have tried CBTS and regular autoroute tunnels and they work fine but not a regular mpls-te with PBR.

I've been following sample configurations and still not been able to make it work.

The lab has the following setup:

CE1->PE1->P->PE2->CE2

The configuration at PE1 looks like this:

!

interface GigaEthernet2/1

description Connection to CE1

ip vrf forwarding test

ip address 10.1.1.1 255.255.255.252

ip policy route-map PBR_in

!

interface Tunnel105

description MPLS-TE Test

ip unnumbered Loopback0

mpls ip !<-- also have tried without mpls

tunnel destination 172.16.100.22

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng priority 3 3

tunnel mpls traffic-eng bandwidth sub-pool 250

tunnel mpls traffic-eng affinity 0x0 mask 0x0

tunnel mpls traffic-eng path-option 1000 dynamic

no routing dynamic

!

route-map PBR_in permit 10

match ip address CE_Loops

set mpls-label !<-- also have tried without this

set interface Tunnel105 !<-- also have tried set ip next-hop <remote-loop>

!

route-map PBR_in permit 100

!

ip access-list extended CE_Loops

10 permit ip host 1.1.1.1 host 2.2.2.2

20 permit ip host 2.2.2.2 host 1.1.1.1

!

And I can see the counters of Tunnel 105 going up but no response, nor any debugging related to it.

sh int tun 104

...

Tunnel transmit bandwidth 8000 (kbps)

Tunnel receive bandwidth 8000 (kbps)

Last input never, output 00:00:05, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/0 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

0 packets input, 0 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

2364 packets output, 168564 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 unknown protocol drops

0 unknown protocol drops

0 output buffer failures, 0 output buffers swapped out

I have done "debug mpls packet" and but I can't see anything related to labels going on.

What am I missing? Is MPLS-TE with PBR really possible? How does it apply labels to the PBR packets?

William

1 Accepted Solution

Accepted Solutions

Laurent Aubert
Cisco Employee
Cisco Employee

Hi William,

This design is not currently supported. The tunnel interface belongs to the global routing table and the interface on which you applied your PBR belongs to a VRF.

So the VRF doesn't know the existence of your tunnel interface.

PBR with MPLS-TE works if the interface on which you apply the PBR policy belongs to the Global Routing Table as well.

HTH

Laurent.

View solution in original post

9 Replies 9

Laurent Aubert
Cisco Employee
Cisco Employee

Hi William,

This design is not currently supported. The tunnel interface belongs to the global routing table and the interface on which you applied your PBR belongs to a VRF.

So the VRF doesn't know the existence of your tunnel interface.

PBR with MPLS-TE works if the interface on which you apply the PBR policy belongs to the Global Routing Table as well.

HTH

Laurent.

Thanks! I misunderstood the documentation and there is a lot of misleading information in mpls-te books. That is why I was trying to figure out how that could work, specially with the labels and I was trying to test it on the lab.

Thanks again.

_W

Laurent

It means if the SP is using vrf for its offices in that case they won't be able to provide PBR. Any other workaround for the same.

regards

shivlu jain

Hi Shivlu,

To have a dedicated tunnel per VPN:

1- Static routes in the VRF should work by specifying only the tunnel interface as the outgoing interface (no next-hop).

2- Another solution can be to change the BGP NH for each VPN:

- You have two VPNs configured on PE1 and PE2

- You have two TE tunnels T1 and T2 between PE1 and PE2. PE1 is the head-end

- BGP is build over Loopback0 IP addresses as usual

The idea is to create two new loopbacks one PE2 (L1 and L2) and to configure PE2 to use those loopbacks as BGP NH:

ip vrf VPN1

bgp next-hop loopback 1

!

ip vrf VPN2

bgp next-hop loopback 2

!

Now PE1 will receive VPNv4 updates from PE2 with BGP NH set to L1 for VPN1 and L2 for VPN2

on PE1 just add two static route so each loopback will be reachable via two different TE tunnels:

ip route L1/32 T1

ip route L2/32 T2

If you have other PEs with sites connected to these VPNS as well and you are not using TE tunnels, you need to redistribute L1 and L2 into the IGP so those other PEs will have a LSP to PE2 as well.

I agree if PBR could be aware of the interface in the GRT, it would be an easier solution.

Thanks

Laurent.

Hi Laurent

Thanks for explanation.

regards

shivlu jain

Hello,

I understand good the solution number 2 and i didn't know that it was possible to change the next-hop for each VPN.

But my question is about the first solution (static route). If the trafic is forwarded with static route, i think that the trafic won't be forwarded with the MP-iBGP route. So, the VPN label won't be applied. I understand so how the trafic will be put from the vrf to the tunnel but if there isn't VPN label, how the trafic will go from the tunnel to the VRF of the remote PE.

Thanks for helping.

Hi,

You're absolutely right !! ;-)

I wrote this one too fast without thinking enough. I think I had vrf leaking to GRT in mind ..

Thanks for this good catch.

Laurent.

Hi lauubert

If I have previous vrf that do not configured with bgp next-hop command.

The new vrf now configure with bgp next-hop command point to loopback 2 as example.

would it cause the any problem to previous vrf that default not configure with bgp next-hop command ?

ip vrf VPN1

ip vrf VPN2

ip vrf VPN3

bgp next-hop loopback 2

Hi,

By default the PE will use the loopback configured as its BGP source-address as usual so nothing to worry about.

HTH

Laurent.