cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7028
Views
0
Helpful
5
Replies

VRF policy based routing

mathias.mahnke
Level 1
Level 1

Hi all,

we are implementing Cisco WAAS (or another cache engine) and need to redirect traffic within one VRF via VRF-aware Policy based Routing (PBR). Mainly everything was configured according the config guide at http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_rte_target_rw_ps6017_TSD_Products_Configuration_Guide_Chapter.html

Current status:

- Local LAN with cat65xx/sup720

- redundant (hsrp) core switches for l3 routing

- IOS 12.2(33)SXI IPSERVICES

- VRF OFFICE with several 3xx VLANs

- VLAN300 (relevant traffic to redirect 172.25.10.0/24)

- VLAN310 (currently the Cisco WAAS at 172.25.13.71)

Config:

ip vrf OFFICE

description 172.25.8.0/21

rd 10:1728

!

interface Vlan300

description Office-Server

ip vrf forwarding OFFICE

ip address 172.25.8.2 255.255.252.0

ip helper-address 172.25.10.9

ip helper-address 172.25.10.34

ip directed-broadcast 111

ip flow ingress

ip policy route-map policy-PBR

standby 45 ip 172.25.8.1

standby 45 priority 110

standby 45 preempt

!

interface Vlan310

description Office-Server-Misc

ip vrf forwarding OFFICE

ip address 172.25.12.2 255.255.252.0

ip helper-address 172.25.10.9

ip helper-address 172.25.10.34

ip flow ingress

standby 50 ip 172.25.12.1

standby 50 priority 110

standby 50 preempt

!

access-list 150 permit tcp 172.25.10.0 0.0.0.255 172.25.80.0 0.0.0.255

!

route-map policy-PBR permit 10

match ip address 150

set vrf OFFICE

set ip vrf OFFICE next-hop 172.25.13.71

We installed a notebook at 172.25.13.71 with wireshark to see redirected traffic. At the moment no (redirected) traffic is hitting there.

Status:

#sh route-map

route-map policy-PBR-RiverbedSTH, permit, sequence 10

Match clauses:

ip address (access-lists): 150

Set clauses:

vrf OFFICE

ip vrf OFFICE next-hop 172.25.13.71

Nexthop tracking current: 172.25.13.71

172.25.13.71, fib_nh:51CF9854,oce:48A1E2B0,status:1

Policy routing matches: 96 packets, 15269 bytes

#sh access-lists

Extended IP access list 150

10 permit tcp 172.25.10.0 0.0.0.255 172.25.80.0 0.0.0.255 (68 matches)

Debug Output:

Mar 5 13:47:59: IP: s=172.25.10.177 (Vlan300), d=172.25.80.36, len 52, FIB policy match

Mar 5 13:47:59: IP: s=172.25.10.177 (Vlan300), d=172.25.80.36, len 52, PBR Counted

Mar 5 13:47:59: IP: s=172.25.10.177 (Vlan300), d=172.25.80.36, len 52, FIB policy routed set vrf

Mar 5 13:47:59: IP: s=172.25.10.177 (Vlan300), d=172.25.80.36, len 52, FIB policy match

Mar 5 13:47:59: IP: s=172.25.10.177 (Vlan300), d=172.25.80.36, len 52, PBR Counted

Mar 5 13:47:59: IP: s=172.25.10.177 (Vlan300), d=172.25.80.36, len 52, FIB policy routed set vrf

All show and debug output looks fine for me, but traffic is not going to 172.25.13.71 so far. Any hints? Any know issues? Anyone using something near it? Do one see any design issue?

Thank you in advance!

Regards

Mathias

5 Replies 5

mathias.mahnke
Level 1
Level 1

Solved with removing the "set vrf OFFICE".

Config is now (in+out traffic matching):

access-list 150 permit tcp host 172.25.10.177 172.25.80.0 0.0.0.255

access-list 150 permit tcp 172.25.80.0 0.0.0.255 host 172.25.10.177

!

route-map policy-PBR permit 10

match ip address 150

set ip vrf OFFICE next-hop 172.25.11.71

!

interface Vlan102

ip policy route-map policy-PBR

!

interface Vlan300

ip policy route-map policy-PBR

Hello Mathias,

I remember a similar thread.

In that case the collegue was noticing different behaviour about hardware support:

a formulation was

set vrf Office

set ip next hop

the other formulation was

set ip vrf office next-hop

one of the two was supported in HW, the other only in SW with evident performance possible problems

if I remember correctly the first was supported in HW the second in SW but I'm not sure.

So I would suggest you to verify in your case when VRF aware PBR is performed in HW

Hope to help

Giuseppe

Thanks for your reply and hint. Tested again both variants. Sadly only the the second ("set ip vrf office next-hop...") will redirect the traffic.

As soon as I add "set vrf office" all counters are raising, but no traffic will hit the pbr destination. For whatever reason...

A second questions that raises up, how can I add a SLA monitor to that pbr route? In a classical PBR (non-vrf) design, we used to work with:

route-map policy-from-branch permit 10

match ip address PBR-from-Branch

set ip next-hop verify-availability 10.7.0.126 1 track 101

!

ip sla 101

icmp-echo 10.7.0.126 source-ip 10.7.0.125

frequency 5

!

ip sla schedule 101 life forever start-time now

The verify-availability feature isn't available with "set ip vrf .." within the route-map. Any other usefull possibility to track the reachability of the route / a WAAS?

Hi:

I encountered the same problem as yours. have you find the solution or work around?

Will be appreciated very much if you can share.

Thanks

Mou Wei

Hi Mou Wei,

we didn't solved this problem and are awaiting new IOS releases to (re)implement this feature on a stable manner.

In the meanwhile we could only use the inline setup, which we choosed and implemented...

Regards

Mathias

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: