10-28-2019 10:03 PM - edited 10-28-2019 10:05 PM
Hello everyone!
Can anyone answer why, after entering the command "show route-map" packet counters show zero matches?
We have other Cisco 3850 switches in production, stand-alone switches and in the stack, but all of them shows zero in counters, but pbr is working correctly.
Versions are:
Everest Version 16.6.5
Everest Version 16.6.6
For example:
tmn-od14-3850-cod#show route-map ODESS_27_INET_KSPD route-map ODESS_27_INET_KSPD, permit, sequence 3 Match clauses: ip address (access-lists): acl-to-check_point Set clauses: ip next-hop 10.172.251.33 Policy routing matches: 0 packets, 0 bytes route-map ODESS_27_INET_KSPD, permit, sequence 5 Match clauses: ip address (access-lists): acl-vks_term-odess27 Set clauses: ip next-hop 10.172.168.18 Policy routing matches: 0 packets, 0 bytes
10-28-2019 11:06 PM
Hi,
This is just a PBR and packets are hitting the access list. Please check:
show access-list acl-to-check_point
10-28-2019 11:25 PM
10-28-2019 11:38 PM
HI,
Have you applied this PBR correctly? Share your configuration with Source and Destination IP address & interfaces.
10-29-2019 05:54 AM
Hello,
you might be hitting the bug below. Check if it works when you remove the 'deny' statements from the access list, so it looks like this:
ip access-list extended acl-to-check_point
permit tcp host 10.45.129.27 eq www any
permit tcp host 10.45.129.27 eq 2071 any
permit tcp host 10.45.129.27 eq 18002 any
permit tcp host 10.45.129.27 eq 19002 any
permit ip host 10.45.129.139 any
permit tcp host 10.145.129.22 eq 2000 any
PBR: policy route map not working | WS-C3850-24T - 03.02.01.SE
CSCui59593
Description
Symptom:
PBR functionality does NOT seem to work the way it should in certain conditions as mentioned below, routing does NOT happen the way PBR is configured.
Conditions:
Policy based routing configured on 3850 switch with permit and deny statements in the route-map or in the access-list tied with route-map.
For eg: If your route-maps for PBR are applied in this way:
route-map VLAN2 deny 45 ------<<<< deny
match ip address 1
route-map VLAN2 permit 50 ------<<<< permit
match ip address 2
set ip next-hop 1.o.0.1
or ACL for PBR:
access-list 113 deny ip 1.1.e.0 0.0.0.255 1.2.e.0 0.0.0.255 ------<<<< deny
access-list 113 permit ip 1.1.e.0 0.0.0.255 any ------<<<< permit
Workaround:
Workaround:
Work this problem around by configuring route-map/acl with below technique:
the access-lists 3 permits the subnets that you want to DBR
(destination based routing with normal IP routing) as there is no set clause.
The access-list 4 should PBR the rest of the traffic to defined next-hop.
route-map VLAN3, permit, sequence 45
Match clauses:
ip address (access-lists): 3 -------<<<< normal routing table
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map VLAN3, permit, sequence 50
Match clauses:
ip address (access-lists): 4 -------<<<< PBR
Set clauses:
ip next-hop 1.o.0.1
this problem is fixed in: IOS-XE: 3.3.0SE and later
10-29-2019 06:04 AM
Hello,
Most likely it's because of hardware switching. If traffic is switched or routed in hardware (ASIC), then there might some limitations in statistics and counters reporting. For ACL statistics it's written explicitly in documentation. I couldn't find it for PBR, but I believe reason is the same.
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