A9K cannot snmp trap.

[Rps-Cheers]

Hello everyone,

I have two A9K devices, they are same config of snmp, but RT1 can trap syslog to snmp server, RT2 cannot trap syslog to snmp server. I guess it will be a software issue. Is there any suggestion to troubleshoot this ?

I want to restart snmpd and syslogd process A9K ,whether it will have service impact ? And whether these commands correct ?

process restart snmpd location 0/RSP0/CPU0
process restart snmpd location 0/RSP1/CPU0

process restart syslogd location 0/RSP0/CPU0
process restart syslogd location 0/RSP1/CPU0

Thx & BR

[smilstea]

show tech syslog and show tech snmp would be helpful along with knowing what version of code is running.

The process restarts may help.

Some pieces of advise, check your snmp trap config or syslog config, whichever you are concerned with (is it syslogs not going to syslog server or snmp traps not going to snmp server?). Make sure the IP address of the server is reachable within the right VRF, make sure the logging level is setup properly and that the traps you want to gather are configured to get sent.

A few useful commands:

RP/0/RSP0/CPU0:ASR9006-L#show logging
Sat Sep 19 18:43:34.988 UTC
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 227236 messages logged
Monitor logging: level debugging, 22 messages logged
Trap logging: level informational, 227124 messages logged
Logging to 66.66.66.66, 0 message lines logged
Logging to 10.127.200.155, 227124 message lines logged
Buffer logging: level debugging, 227314 messages logged

Log Buffer (2097152 bytes):

show snmp traps

Sam

[Rps-Cheers]

HI  Sam

Thanks for your answer.
I checked the configuration of syslog and snmp trap. The two ASR devices have the same configuration, and the other one can work normally. Neither syslog nor snmp of this one can be sent to the server. The syslog server and snmp server are the same device.
The server address can be pinged. The version of the device is relatively low, and the software version is 4.3.4.
I want to know whether "process restart snmpd" and "process restart syslogd" will affect the business operation of the device. When restarting which processes, we need to pay special attention?
Because the version of the device is relatively low, I consider restarting the process. If the process can be restarted, I will restart the process first. If there are still problems, I will collect information such as show snmp.

[smilstea]

Restarting those processes is considered safe. You will notice a momentary drop in SNMP packets, but your next cycle of SNMP polling will be fine, it shouldn't be more than 1s or so of loss. No impact to data plane.

Sam

[Rps-Cheers]

HI Sam

Thanks for you help, but after issue these command:

process restart snmpd location 0/RSP0/CPU0
process restart snmpd location 0/RSP1/CPU0

process restart syslogd location 0/RSP0/CPU0
process restart syslogd location 0/RSP1/CPU0

This problem still exists!

[smilstea]

As you mentioned 4.3.4 is rather old code, in fact it is past last day of support. I would recommend upgrading to a newer version of code such as 5.3.4 if you have trident based cards or something if newer if all typhoon cards.

If you still face the issue after upgrade then I recommend opening a tac case with the two show techs mentioned.

Sam