03-05-2009 05:18 AM
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
03-05-2009 07:00 AM
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
03-05-2009 07:56 AM
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
03-05-2009 12:44 PM
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?
06-09-2009 11:10 PM
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
06-09-2009 11:51 PM
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
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