cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
725
Views
2
Helpful
32
Replies

How to get ACL hit count on hardware based ACL's?

Good morning all, 

I have created some large ACL's strictly for the task of triggering hit counts for static routes to tell me if the routes are even used any longer (for future cleanup purposes)

I am not getting any hit counts (Cisco 9604R) and have researched this is common for ACL's on L3 switches as they are processed in hardware vs software. 

Is the answer to get the hit counts as simple as adding the log command at the end of each ACE, or is there a better way? (The total ACE count between both ACL's is almost 600, so I would like to avoid blowing my buffer up as well as syslog server with these if I can just simply see the hit count. )

32 Replies 32

"I will research this service policy option you mentioned and see if it can work for me"

If you need further guidance on that, feel free to ask.

As setting up the syntax, manually, would be a real PIA, do you have any scripting experience?  If so, it wouldn't be too difficult to write a script and take your ACL and remap into a service-policy.  Biggest issue would be, service policies have a class limit, which I recall (?) in the later variants is about 1000.  If true your script would need to break the ACL down into two service policies.

But before doing that, if you have any ACE you're sure that will match, you can setup a test policy to see if, in fact, that stats will show a match count using a service policy.  Again, if you need further guidance, can help with that too.

I have no scripting experience, nor am I confortable reinventing the wheel on my core switches if I do not have to. 

Too bad you have no scriptimg experience.  Worthwhile skill to pick up, and this would be a good learning case as it's actual rather trivial.  No one there who could write a script?

Appreciate you don't want to pursue an approach you're unfamiliar with.  So, hopefully you'll find another way or find the log option will work well for you.

Scripting is on my list to learn this year actually for other needs with SDWAN. I know some things, but I am still in the labbing portion and VERY basic of just running SSH commands via ansible scripts. Nothing more sophisticated than that. lol

Well, we all start not knowing.

In this case, again, it's, I believe, a very, very simple script, although it may not seem that way.

For each ACE, you would build the supporting config statements, which would be identical except for naming ACLs and class maps with something like a sequence number.  You would only take as input a text file with your ACEs and output a text file with the config statements to apply.

Again, though, should try a simple (manual) example to confirm this approach will work.

If you would like, this evening I may have the time to manually show what ACEs should produce.

Also, BTW, learning about policy and class maps and service policies good to know if you ever want to use QoS.

I assume you've started with something like:

ip route 192.168.3.0 255.255.255.0 192.168.2.4
ip route 192.168.4.0 255.255.255.0 192.168.2.4
ip route 192.168.5.0 255.255.255.0 192.168.2.4

and turned into something like this:

ip access-list extended StaticRoutes 
 permit ip any 192.168.3.0 0.0.0.255
 permit ip any 192.168.4.0 0.0.0.255
 permit ip any 192.168.5.0 0.0.0.255

The ACEs could be converted to something like this:

interface g0/0/0
 no service-policy input StaticRoutes
no policy-map StaticRoutes
no class-map StaticRoute001
no class-map StaticRoute002
no class-map StaticRoute003
no ip access-list extended StaticRoute001
no ip access-list extended StaticRoute002
no ip access-list extended StaticRoute003

ip access-list extended StaticRoute001
 permit ip any 192.168.3.0 0.0.0.255
ip access-list extended StaticRoute002
 permit ip any 192.168.4.0 0.0.0.255
ip access-list extended StaticRoute003
 permit ip any 192.168.5.0 0.0.0.255

class-map StaticRoute001
 match access-group name StaticRoute001
class-map StaticRoute002
 match access-group name StaticRoute002
class-map StaticRoute003
 match access-group name StaticRoute003

policy-map StaticRoutes
 class StaticRoute001
 class StaticRoute002
 class StaticRoute003

Applied like this:

interface g0/0/0
 service-policy input StaticRoutes

Providing something like this:

Router#sh policy-map interface g0/0/0
 GigabitEthernet0/0/0

  Service-policy input: StaticRoutes

    Class-map: StaticRoute001 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name StaticRoute001

    Class-map: StaticRoute002 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name StaticRoute002

    Class-map: StaticRoute003 (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name StaticRoute003

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any

 

isadorafinch5
Level 1
Level 1

Adding the "log" command at the end of each ACE is indeed one way to get hit counts for hardware-based ACLs. This approach can provide you with the information you need without overwhelming your buffer or syslog server. Alternatively, you can also consider using SNMP polling to gather hit count data. Hope this helps!

If I added the log command, could I apply to outbound traffic and see allows as well? Or just permits and/or just inbound? ******DISREGARD: I tried and you just cannot apply an acl outbound to an interface. Just inbound :(. So I will still need to flip my ACL's if this even works to collect the return route traffic.

SNMP could be an interesting option as well. Can you elaborate on this?

This would be a great solution if the traffic was consistent and small and a 1 time use. Again this is 600+ static routes from the last 20+ years of engineers adding them I am trying to clean up. Just because there is a route to something does not mean they use it daily, even weekly or monthly. We have TONS of vendor connections coming in that these are mostly used for. This is the only way I know to weed them out, but I cannot keep a packet capture running for months and trying to match back to 600+ subnets.

Did yoh review solution I suggest?

The capture usr match and these 600 routes sure have IP you can use in match.

Goodluck in your task 

Have a nice day 

MHM

I am familiar with embedded packet captures and this solution will not do what I need it to do. I would essentially be letting a packet capture run for months on end and parsing through data. 

My goal is to match EACH and EVERY static route over a period of time to determine if they are actively being used anymore or stagnant leftovers from prior regimes. If no matches = nuke that static route, if matches = leave the static route and document what it was for and move on. 

Check route for month? This long period 

Anyway 

If you want to see if the route is use or not (and I am not sure this count will appear in C9000) you can use 

Show ip cef x.x.x.x detail 

Show ip adjunacy x.x.x.x detail 

Both give you packet count and no need acl or EC or anything else.

MHM

I guess I need to be clear this is not a lab environment. This is a production environment of a $50B business with like 1200 sites and 2 data centers just in my BU. Yea, stuff takes time when people have been adding static routes for 25yrs and no one ever cleared them up.
I really do not want to go through every single subnet one by one to see if it has ever been used. I am looking for metrics forward hence why I was hoping it be as easy as just matching ACL hit counts.
Show IP cef just shows me I have a route. The other command does not exist.

Joseph W. Doherty
Hall of Fame
Hall of Fame

BTW, just stumbled across the Optimized ACL Logging feature, on another switch platform.  Don't know if your platform supports, but if it does, would eliminate much concern about CPU impact of ACE logging.

Review Cisco Networking for a $25 gift card