I have a route-map setup on a 3560, as shown below:
ip access-list ext 117
10 deny ip any 192.168.0.0 0.0.255.255 (this is to stop any traffic destined for internal subnets being policy routed)
20 permit ip any any (anything that gets past the deny statement is destined for the outside and should be policy routed)
route-map VLAN17 permit 10
match ip address 117
set ip next-hop 192.168.0.14
ip address 192.168.180.254 255.255.255.0
ip policy route-map VLAN17
The purpose of the route-map is to send traffic destined for the outside world that is recieved on int vlan18 via the next-hop of 192.168.0.14, instead of via an OSPF default route being advertised by another router.
Access-list 117 is denying 192.168.0.0 0.0.255.255 so that traffic destined for any internal network will not get policy routed to 192.168.0.14.
The route-map works as expected, but the performance hit from the route-map is enormous. Using QCheck i get about 15Mbps when testing from a vlan 18 host to a host on another internal subnet (192.168.66.0). All interface involved are Gigabit.
The weird thing is that when i remove the deny statement from acl 117, i get expected results in QCheck (even though it is being policy routed the long way via 192.168.0.14).
Is all i can figure out so far is that the performance hit happens when traffic matches the deny statement in acl 117.
Why would traffic matching the deny statement be causing such problems?
Let me know if you need any more info about my setup.
Unfortunately, it looks like 3560 does not support deny statements for PBR in hardware as per the configuration guide:
Adding the Deny ACE will force the traffic to be punted into the software path - hence the lower throughput and an elevated CPU condition should be seen.
So, for the 3560 and PBR, will need to attempt to build the logic you need using permit statements.
Eugene is right, 3560 does not handle ACE deny in hardware , hence even subsequent permit entry also goes through software forwarding, hence the slow performance.