asked on

Cisco ACL showing no match, yet traffic must exist

I've got an large ACL that I was looking to optimize. I noticed that the PERMITs to allow SYSLOG UDP to our VERY ACTIVE syslog server had no matches. Now this is the only path to the network with the syslog server and we have about 2 gigs of syslog messages a day being collected, so I'm at a loss why the access-list shows no match. There is NO DOUBT that the traffic is flowing through this router's ACL, the Router showed 66Mbps earlier today and those matches show below. The syslogs are from a variety of networks.

Are there exceptions of why traffic would NOT trigger a match?

Extended IP access list 161
permit udp any any eq 1985
permit udp any eq domain 10.1.61.0 0.0.0.255
permit icmp any 10.1.61.0 0.0.0.255 echo-reply (2 matches)
permit tcp any host 10.1.61.11 established
permit tcp any host 10.1.61.12 established
permit tcp 10.1.8.224 0.0.0.31 host 10.1.61.26 eq telnet
permit tcp 10.1.9.224 0.0.0.31 host 10.1.61.26 eq telnet
permit tcp 10.1.26.0 0.0.0.255 host 10.1.61.26 eq telnet
permit ip 10.1.9.216 0.0.0.7 host 10.1.61.34
permit ip 10.1.26.0 0.0.0.255 10.1.61.0 0.0.0.255 (1174 matches)
[ many lines deleted - all NO MATCHES ]
permit ip 10.1.1.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.16.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.24.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.25.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.36.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.42.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.66.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.69.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.96.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.144.0 0.0.0.255 host 10.1.61.10
permit ip 10.1.160.0 0.0.0.255 host 10.1.61.10
permit ip any host 10.1.61.10
permit ip any host 10.1.61.20
permit ip any host 10.1.61.15 LOG (51019723 matches)
permit ip any host 10.1.61.16 LOG (1175 matches)
permit ip any host 10.1.61.35 LOG (9156 matches)
permit ip any host 10.1.61.36 LOG (1974498805 matches)
permit ip any host 10.1.61.37 LOG (2952 matches)
permit ip 10.1.128.0 0.0.0.127 host 10.1.61.10
permit ip 10.1.128.0 0.0.0.127 host 10.1.61.11
permit udp 10.64.192.0 0.0.31.255 host 10.1.61.100 eq syslog
permit udp 10.68.192.0 0.0.31.255 host 10.1.61.100 eq syslog
permit udp 10.32.192.0 0.0.31.255 host 10.1.61.100 eq syslog
permit udp 10.96.192.0 0.0.31.255 host 10.1.61.100 eq syslog
permit udp 10.1.192.0 0.0.0.255 host 10.1.61.100 eq syslog
permit udp any host 10.1.61.100 eq syslog
permit udp any host 10.1.61.101 eq syslog
deny 53 any any
deny 55 any any
deny 77 any any
deny ip any any (198152 matches)

(IP addresses have een changed to protect the guilty)

Genexen

How are the access-lists applied? I'm guess that the traffic WOULD NOT trigger a match because the access-list is not being applied to the required interface(s) in the required direction (in or out):

IE - if you are applying access-list 161 to e0/1 inbound, and all your snmp (syslog udp) is EXITING e0/1, then you won't get a match.

Genexen

Same answer, with examples:

http://www.networkclue.com/routing/Cisco/access-lists/applying.php

RoyalEF

ASKER

Sorry forgot to be explicit about all the conditions. FYI this is a fully production network and all of this has been working for months to years. It is just a matter of understanding why matches that ARE passing through this routing interface ARENT being counted. The pasted lines above show that the ACL has millions of matched packets so it has definitely been applied and continue to increment.

This is being applied to a routed VLAN interface on the rOuting blade of a 6509. For instance

interface Vlan 61
ip address 10.1.61.2 255.255.255.0
ip access-group 161 out
no ip redirects
standby priority 110 preempt
standby ip 10.1.61.1

RoyalEF

ASKER

10.1.61.10, 100, & 101 are all syslog servers.

Genexen

well, you are using HSRP, with a standby priority of 110, meaning that the OTHER router/switch (at 10.1.61.3 most likely) probably has the DEFAULT standby priority of 100, making it the ACTIVE gateway. In this setup, your virtual HSRP address of 10.1.61.1 is "floating" between this switch (10.1.61.2) and the other switch.

Go to to the other 6509 and check your counters there. You can always do a "show standby int vlan 61" to see which 6509 is the active gateway.

-Marc

Genexen

sorry, forgot to add, the counters may be incrementing/packets matching on the OTHER (active) 6509 and not this (standby) one.

RoyalEF

ASKER

No, the other 6509 has almost no hits for this access-list(BTW, Priority is 120). This is the active router for this subnet. (I was unaware that there was a DEFAULT priority... there are some configuration here were one side has a priority set and the other it was not set--I wasn't sure how that was handled).

RoyalEF

ASKER

I actually thought I had come back and updated this with the answer I found myself. The reason is that the 6509 performs layer 3 switching in hardware and this traffic will never register in the ACL counts. Only exceptions will be handed off to the processor and be counted by the Access-list. Using a "log" option on a ACL statement is one of the ways to trigger such a processor-based exception, but there are others. This is why we see some, but most are missing.

Once you go to layer 3(hardware) switching ACL counts don't mean anything, neither does actvity (byte/packet) counts on routed interfaces. Hardware routed traffic counts shows up on switched trunks and not on routed interfaces counts.

I have no objection to refunding it.

ASKER CERTIFIED SOLUTION

modulo

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial