What To do about SNMP-3-AUTHFAIL Messages

SNMP-3-AUTHFAIL - community string or ACL - which comes first

Table of Contents

SNMP-3-AUTHFAIL - community string or ACL - which comes firstHave you secured your router with an ACL for SNMP access but are still seeing pages of SNMP-3-AUTHFAIL messages in your logs? In this article we will be dig into this issue and find out exactly what’s going and and why an SNMP-3-AUTHFAIL message might showing up in your logs and also why this message might be misleading.


So here’s the scenario, you have a router within your network that you feel  has been configured to be secured from the bad guys of the world.  You have disabled telnet access, have access control lists (ACLs) in place for SSH to only allow for secured terminal access from a jump-host or known network range.  And finally, since this device needs to be monitored, you enabled SNMP version 3 (v3 is better right?) and established an ACL to block unwanted attempts as well.  All is good.  You’ve done your job and  feel confident that this device is safe .

But what do you do when you review the logs of this device the next day (or next week or month), and find the logs full of SNMP3-AUTHFAIL messages?  You DID put that ACL in place right?  …Of course you did!  So what’s going on?

Per Cisco the SNMP-3-AUTHFAIL  messages indicates:

%SNMP-3-AUTHFAIL : Authentication failure for SNMP req from host [dec].[dec].[dec].[dec]

Explanation    An SNMP request was sent by the host at the address [dec].[dec].[dec].[dec], but the request PDU was not properly authenticated.

Recommended Action    Make sure that the community and user name that are used in the SNMP request from the remote host have been configured on the router

At first this would seem to indicate that the snmp attempts are getting through the ACL and making it to the SNMP engine only to be denied due to an incorrect community string.  Seems logical but first lets review the configuration for SNMP.

Router Configuration for SNMP

Before you configure your router for SNMP access:  Remember that using SNMP is just like any other protocol you would use for access, i.e., telnet, ssh, etc.

With this in mind NEVER use community strings like “PUBLIC”, “PRIVATE”, “CISCO”, “PASSWORD”, etc… you get the point. Brute force attacks will use these obvious words to try to gain access.  Also NEVER use a read-write string unless you absolutely need your management device to change the configuration.

snmp-server location work-address
snmp-server contact yourname
! begin ACL
snmp-server community public RO 5
snmp-server community private RW 6
! log incorrect SNMP Communities
logging snmp-authfail
! access-list for RO
access-list 5 permit
access-list 5 permit
! access-list for RW
access-list 6 permit

Notice in the config above we have enabled SNMP Auth Fail. We want this on so that attempts are written to the logs which will let us KNOW when someone or something is attempting access.

Now that we have verified a known good config, lets get back to the issue at hand and that’s all of those log messages.

Testing SNMP Failures.

The best way to the root of a problem is to test.  Make two separate tests to see what gets entered into the logs.

First test – incorrect community string.

Test access to your device using an incorrect community string.  You should see something like the following in your logs:

Jul 23 20:18:43.254 UTC: %SNMP-3-AUTHFAIL: Authentication failure for SNMP request from host

Next test with the correct community string but change the ACL to block your test machine. You should see the following in the logs:

Jul 23 20:18:43.254 UTC: %SNMP-3-AUTHFAIL: Authentication failure for SNMP request from host

Notice something interesting?? It’s the SAME log message!!!

Both the community string AND the ACL have to match before access to the SNMP engine is granted.  If either is incorrect the router will through an SNMP-3-AUTHFAIL message to the logs.

But here’s the big questions – which comes first the community string or the ACL? (It’s a bit like the old chicken-and-the-egg story).

This is “unverified” but… it seems that the ACL is only referenced *after* the authentication (ie the community string match) is completed.  So, you’ll get authentication failed messages in the logs regardless if the ACL otherwise prohibits the host from accessing the snmp process.  A followup with Cisco TAC should confirm this.

The good news, at least from our limited testing, that the SNMP is working as intended and the router is same and sound. Now if we can just clear up those log messages.. It’s awfully noisy in there!


5/5 - (2 votes)



Senior Network Engineer, technology enthusiast, guitar and bass player. Joe Wilson is the creator of RouterFreak.com as well as other niche websites that can be found around on the Internets.

What do you think about this article?


  1. Hm, to cisco devices an ACL just means a list of IP network ranges, no more, no less.
    Most often, it is applied to an IP interface to control filtering of IP traffic at layer 3.
    But sometimes it is used routing direction for a split-tunnel VPN client, or, as in this case, as a list of allowed client addresses for the SNMP daemon running on the device.
    This kind of filtering applies on layer 4, and is part of the early SNMP processing.
    You could still apply the list to one or more interfaces of the device _in addition_.
    This would e.g. protect against a DoS attack on SNMP port (at least to some degree).
    Also, if the SNMP daemon code was fundementally flawed and eg. allow to bypass all
    auth and client filter processing by sending some crafted packet, the layer 3 ACL would most likely protect you. Without, the SNMP daemon would be subject to pawnage. Do you agree?

    Cheers, Martin

  2. CPU is very high on the switch an di found teh below process is consuming more, could you please help me how to deal with this issue

    sh processes cpu sorted
    CPU utilization for five seconds: 99%/24%; one minute: 99%; five minutes: 99%
    PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
    549 58378196 80238455 727 28.09% 36.87% 39.22% 0 DHCPD Receive
    136 28440 26531 1071 20.75% 6.16% 2.70% 2 SSH Process
    331 1820589321456369927 125 14.68% 19.01% 19.82% 0 IP Input
    19 335024896 708745786 472 4.14% 6.44% 6.71% 0 ARP Input

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About us

RouterFreak is a blog dedicated to professional network engineers. We
focus on network fundamentals, product/service reviews, and career advancements.