Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
830
Views
0
Helpful
4
Replies

SNMP log message flood

Go to solution
clive.hodgetts
Level 1
Level 1

‎09-28-2022 04:19 AM

We have recently noted a flood of SNMP related logs which a snapshot are shown below (full logs attached). As shown, they were all logged in a short space of time. There was no issues on the network reported at the time and no other switches of the same type and/or being monitored using SNMP have reported this same issue. This hasn't occurred since but just would like anyone's feedback on what these log messages might mean, is there something we need to change to prevent these type of messages being logged and is there anything to be concerned with if these logs reappear or can we just ignore them. As mentioned, at the time of the messages being written, before or after, there have been no reported network issues and I have checked several SNMP monitored switches within the same network and none have logged these particular messages. I can raise a TAC case but would only do so it advised on this forum or I don't receive any advice or feedback from here. As a note, we are utilising Solwarwinds to monitor the switched network

Aug 12 10:36:19.213: SW1: SNMP: Response, reqid 52211, errstat 0, erridx 0
ifDescr.156 = Port-channel2
ifAdminStatus.156 = 1
ifOperStatus.156 = 1
ifLastChange.156 = 1810212253
ifName.156 = Po2
Aug 12 10:36:19.213: SW1: SNMP: Queuing packet to 137.223.74.229
Aug 12 10:36:19.213: SW1: SNMP: V2 Trap, reqid 1025597, errstat 0, erridx 0
sysUpTime.0 = 3461857513
snmpTrapOID.0 = snmpTraps.5
lsystem.5.0 = 10.156.77.137
ciscoMgmt.412.1.1.1.0 = 1
ciscoMgmt.412.1.1.2.0 = 10.156.77.137
Aug 12 10:36:19.213: SW1: SNMP: Queuing packet to 137.223.74.235
Aug 12 10:36:19.213: SW1: SNMP: V2 Trap, reqid 1025598, errstat 0, erridx 0
sysUpTime.0 = 3461857513
snmpTrapOID.0 = snmpTraps.5
lsystem.5.0 = 10.156.77.137
ciscoMgmt.412.1.1.1.0 = 1
ciscoMgmt.412.1.1.2.0 = 10.156.77.137
Aug 12 10:36:19.213: SW1: SNMP: Report, reqid 53144, errstat 0, erridx 0
snmpUsmMIB.1.1.4.0 = 113791505
Aug 12 10:36:19.213: SW1: SNMP: Get-bulk request, reqid 651, nonrptr 0, maxreps 20
entPhysicalEntry.11.7304 = NULL TYPE/VALUE
Aug 12 10:36:19.217: SW1: SNMP: Packet sent via UDP to 192.168.1.100
Aug 12 10:36:19.217: SW1: SNMP: Packet sent via UDP to 192.168.1.100
Aug 12 10:36:19.217: SW1: SNMP: Packet sent via UDP to 192.168.1.100
Aug 12 10:36:19.217: SW1: SNMP: Packet sent via UDP to 192.168.1.100
Aug 12 10:36:19.237: SW1: SNMP: Response, reqid 651, errstat 0, erridx 0
entPhysicalEntry.11.7305 =
entPhysicalEntry.11.7312 = FIW205303KK-B
entPhysicalEntry.11.7324 = FIW205302CW-A
entPhysicalEntry.11.7348 = AVD1927AF3F
entPhysicalEntry.11.7349 =
entPhysicalEntry.11.7350 =
entPhysicalEntry.11.7351 =
entPhysicalEntry.11.7352 =
entPhysicalEntry.11.7353 =
entPhysicalEntry.11.7408 = OPA14070331
entPhysicalEntry.11.7420 = FNS14050WW0
entPhysicalEntry.11.7432 = AVD2228K8LJ
entPhysicalEntry.11.7433 =
entPhysicalEntry.11.7434 =
entPhysicalEntry.11.7435 =
entPhysicalEntry.11.7436 =
entPhysicalEntry.11.7437 =
entPhysicalEntry.11.7444 = AVD2115K57A
entPhysicalEntry.11.7445 =
entPhysicalEntry.11.7446 =
Aug 12 10:36:19.241: SW1: SNMP: Report, reqid 53365, errstat 0, erridx 0
snmpUsmMIB.1.1.4.0 = 113791506
Aug 12 10:36:19.241: SW1: SNMP: Get request, reqid 53366, errstat 0, erridx 0
ifDescr.117 = NULL TYPE/VALUE
ifAdminStatus.117 = NULL TYPE/VALUE
ifOperStatus.117 = NULL TYPE/VALUE
ifLastChange.117 = NULL TYPE/VALUE
ifName.117 = NULL TYPE/VALUE
Aug 12 10:36:19.241: SW1: SNMP: Response, reqid 53366, errstat 0, erridx 0
ifDescr.117 = TenGigabitEthernet2/2/10
ifAdminStatus.117 = 1
ifOperStatus.117 = 1
ifLastChange.117 = 1810234300
ifName.117 = Te2/2/10
Aug 12 10:36:19.241: SW1: SNMP: Get request, reqid 53367, errstat 0, erridx 0
ifDescr.51 = NULL TYPE/VALUE
ifAdminStatus.51 = NULL TYPE/VALUE
ifOperStatus.51 = NULL TYPE/VALUE
ifLastChange.51 = NULL TYPE/VALUE
ifName.51 = NULL TYPE/VALUE
Aug 12 10:36:19.241: SW1: SNMP: Response, reqid 53367, errstat 0, erridx 0
ifDescr.51 = TenGigabitEthernet1/5/2
ifAdminStatus.51 = 1
ifOperStatus.51 = 1
ifLastChange.51 = 2112770694
ifName.51 = Te1/5/2
Aug 12 10:36:19.241: SW1: SNMP: Report, reqid 53368, errstat 0, erridx 0
snmpUsmMIB.1.1.4.0 = 113791507
Aug 12 10:36:19.245: SW1: SNMP: Report, reqid 53490, errstat 0, erridx 0
snmpUsmMIB.1.1.4.0 = 113791508
Aug 12 10:36:19.245: SW1: SNMP: Report, reqid 53491, errstat 0, erridx 0
snmpUsmMIB.1.1.4.0 = 113791509
Aug 12 10:36:19.245: SW1: SNMP: Report, reqid 53549, errstat 0, erridx 0
snmpUsmMIB.1.1.4.0 = 113791510
Aug 12 10:36:19.245: SW1: SNMP: Get request, reqid 53550, errstat 0, erridx 0
ifDescr.270 = NULL TYPE/VALUE
ifAdminStatus.270 = NULL TYPE/VALUE
ifOperStatus.270 = NULL TYPE/VALUE
ifLastChange.270 = NULL TYPE/VALUE
ifName.270 = NULL TYPE/VALUE
Aug 12 10:36:19.245: SW1: SNMP: Response, reqid 53550, errstat 0, erridx 0
ifDescr.270 = TenGigabitEthernet1/4/12
ifAdminStatus.270 = 1
ifOperStatus.270 = 1
ifLastChange.270 = 1810098252
ifName.270 = Te1/4/12
Aug 12 10:36:19.245: SW1: SNMP: Queuing packet to 137.223.74.229
Aug 12 10:36:19.245: SW1: SNMP: V2 Trap, reqid 1025599, errstat 0, erridx 0
sysUpTime.0 = 3461857516
snmpTrapOID.0 = snmpTraps.5
lsystem.5.0 = 10.156.77.137
ciscoMgmt.412.1.1.1.0 = 1
ciscoMgmt.412.1.1.2.0 = 10.156.77.137

 

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
clive.hodgetts
Level 1
Level 1

‎09-29-2022 02:36 AM

Thanks everyone for the replies. As you might have figured out, the logs were now standard logs but were generated because a debug for SNMP was configured at some point which I wasn't aware of. Consequently these messages were logged to the buffer which only got picked up at a later date after the debug had been switched off. Lesson learned though.....ensure you are always aware of who might be running debugs on the network!! Thanks again

View solution in original post

0 Helpful
4 Replies 4

Go to solution
marce1000
VIP
VIP

‎09-28-2022 05:11 AM

 

  - What device type and or model are you getting these traps from ? Anyway check regular logs on the device too.

 M.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !
0 Helpful

Go to solution
clive.hodgetts
Level 1
Level 1
In response to marce1000

‎09-28-2022 05:47 AM

Good Afternoon M.

The platform is a Catalyst 6880. The logs are taken from the regular log buffer (show log)

0 Helpful

Go to solution
marce1000
VIP
VIP
In response to clive.hodgetts

‎09-28-2022 09:31 AM

 

 - Verifying some of the serial numbers involved against : https://cway.cisco.com/sncheck/ , I could see that these related to an SFP(s) and optical module(s) , you may check interface counters of fiber interfaces and look for errors e.g. You could also consider using latest advisory software version on the 6800 , if applicable : https://software.cisco.com/download/home/284855056/type/280805680/release/15.5.1-SY8 , check if the errors would then go away.

 M.



-- ' 'Good body every evening' ' this sentence was once spotted on a logo at the entrance of a Weight Watchers Club !
0 Helpful

Go to solution
clive.hodgetts
Level 1
Level 1

‎09-29-2022 02:36 AM

Thanks everyone for the replies. As you might have figured out, the logs were now standard logs but were generated because a debug for SNMP was configured at some point which I wasn't aware of. Consequently these messages were logged to the buffer which only got picked up at a later date after the debug had been switched off. Lesson learned though.....ensure you are always aware of who might be running debugs on the network!! Thanks again

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents