PBR Issue on Cat 4500..

Unanswered Question
Jan 13th, 2009

Hello Everyone,

I am facing a strange problem on the core switch of my network. I have a Device in VLAN 1 directly connected to the core and fully reachable (IP to which i want to redirect the traffic of VLAN 4. I created access-list 101 and a route-map DSL, applied it to the interface vlan 4 but the traffic is routed through the default gateway. My PC is in Vlan 4 (IP and is connected to a Cat 3750 switch which is trunked to the core. The Traffic just doesn't get forwarded to

I am Attaching the Show Run of the Core Switch and have highlighted the necessary configuration...

Please Help...



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Giuseppe Larosa Tue, 01/13/2009 - 10:16

Hello Rohit,

try to add

ip route 200

to have a floating static route pointing to the intended next-hop

the default route above is not preferred to the one you already have.

Hope to help


Jon Marshall Tue, 01/13/2009 - 10:31


What is the destination IP address you are testing with ?

Are you getting hits on thacl 101 ?


rohitrattan Tue, 01/13/2009 - 11:07

Hello Jon,

I have a DSL link connected to a router, my destination is internet. I ping and as far as hits are concerned in am getting ample hits for all the deny statements but too few hits for the permit statement. Moreover when i do "show route-map DSL" it shows a number of packets policy routed.

access-list 101 deny ip

access-list 101 deny ip

access-list 101 deny ip

access-list 101 deny ip host

access-list 101 deny ip host

access-list 101 deny ip host

access-list 101 deny ip host

access-list 101 permit ip any

(vlan 4 [ /24]

I start a continuous ping from my PC [] to and to some internal Private IP's also. The deny statements clearly produce the hits but i do not know why the last permit statement doesn't show any hits for a while and after a couple of minutes the hits increment by 2 to 5...can it be some kind of an IOS bug...or is there some Hardware/Software limitation on the number of ACL's or PBR statements configured on the switch..



Jon Marshall Tue, 01/13/2009 - 11:28


From the 4500 config guide -

"The Catalyst 4500 switching engine supports matching a "set next-hop" route-map action with a packet on a permit ACL. All other route-map actions, as well as matches of deny ACLs, are supported by a flow switching model. In this model, the first packet on a flow that matches a route-map is delivered to the software for forwarding. Software determines the correct destination for the packet and installs an entry into the TCAM so that future packets on that flow are switched in hardware. The Catalyst 4500 switching engine supports a maximum of 4096 flows."

So yes there are limits to the amount of flows supported with PBR. Your switch configuration has an awful lot of PBR on it so it may be that you are hitting limits somewhere. Are you seeing any messages about TCAM's in the logs ?

Attached is a link to TCAM issues on the 4500 -


may be worth a look.

As for why you are only seeing intermittent increments, this could be to do with how the 4500 processes acl entries.

From the 4500 config guide again -

"Flows that match a deny statement in standard and extended ACLs are dropped in hardware if ICMP unreachable messages are disabled."

"Flows that match a permit statement in standard ACLs are processed in hardware"

"To drop access-list denied packets in hardware on the input interface, you must disable ICMP unreachable messages using the no ip unreachables interface configuration command. The

ip unreachables command is enabled by default."

I don't have access to a 4500 to test but the above suggests permit statements are processed in hardware.

Deny statements are processed in hardware if you have configured "no ip unreachables" on the input interface. If you haven't they are processed in software.

If the 4500 behaves like the 6500 then acls that are processed in hardware do not increment the access-list counters. So a valid test would be to enable "no ip unreachables" on the vlan interface and then see if the deny statements in your acl still increment.



This Discussion