SNMP configuration issue from Nagios XI

[raamardhani7]

Hi Team,

I am trying to configure poll up/down (icmp) and also T1 interface utilization (snmp) for the WAN link (xx.xx.xx.xx)

./check_tcp -H xx.xx.xx.xx -p 161
connect to address xx.xx.xx.xx and port 161: Connection refused

Could someone help me with this please..

[raamardhani7]

snmpwalk -v 3 -u userID -l authPriv -a sha -A USER333333 -x aes -X USER333334 xx.xx.xx.xx
Timeout: No Response from xx.xx.xx.xx

[jolson]

./check_tcp -H xx.xx.xx.xx -p 161
connect to address xx.xx.xx.xx and port 161: Connection refused

This tells me that either your SNMP agent is listening on UDP or a firewall rule/ACL is blocking access to the TCP port here. You may have to do some testing on your end to figure out which is likely.

snmpwalk -v 3 -u userID -l authPriv -a sha -A USER333333 -x aes -X USER333334 xx.xx.xx.xx

Are you certain that the above command is correct? You might double-check your SNMP configuration on the remote device you're attempting to check.

[raamardhani7]

./check_tcp -H xx.xx.xx.xx -p 161
connect to address xx.xx.xx.xx and port 161: Connection refused

This tells me that either your SNMP agent is listening on UDP or a firewall rule/ACL is blocking access to the TCP port here. You may have to do some testing on your end to figure out which is likely.

snmpwalk -v 3 -u userID -l authPriv -a sha -A USER333333 -x aes -X USER333334 xx.xx.xx.xx

Are you certain that the above command is correct? You might double-check your SNMP configuration on the remote device you're attempting to check.

Hi Jolson,

You are correct, it is listening to UDP 161.

Below are the details I can paste from the Nagios XI server:

# ./check_tcp -H xx.xx.xx.xx -p 161
connect to address xx.xx.xx.xx and port 161: Connection refused
You have new mail in /var/spool/mail/root
# telnet xx.xx.xx.xx 161
Trying xx.xx.xx.xx...
telnet: connect to address xx.xx.xx.xx: Connection refused
# nmap xx.xx.xx.xx -p 161

Starting Nmap 5.51 ( http://nmap.org ) at 2015-08-10 01:07 CDT
Nmap scan report for xx.xx.xx.xx
Host is up (0.00039s latency).
PORT STATE SERVICE
161/tcp closed snmp

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
# iptables -nL | grep 161
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:161

netstat -an | grep -i 161

There is no output for this command.

Please let me know if I can share any other information. Thanks.

[Box293]

SNMP is UDP which makes it hard to test if a remote device is accepting UDP requests, which makes using check_tcp hard.

An SNMP Walk is the best test there is.

Is Nagios and the device in the same subnet? If not, do the router(s)/firewall(s) that separate them allow UDP 161 traffic?

[raamardhani7]

SNMP is UDP which makes it hard to test if a remote device is accepting UDP requests, which makes using check_tcp hard.

An SNMP Walk is the best test there is.

Is Nagios and the device in the same subnet? If not, do the router(s)/firewall(s) that separate them allow UDP 161 traffic?

Hi,

Both are in different subnets and there is no firewall issues is the information I received from the client.

I am using snmpwalk command as advised, but finding challanges, as the password is having ! wild characters in it.
EX: D*ABC!EF$!Ghi&J

And I have created a argument in resource.cfg
$USER333333$=D*ABC!EF$!Ghi&J

And trying with snmpwalk, and still facing the issue. Any insights please on this.??

[jdalrymple]

If you're using snmpwalk and it's failing that means there is some fundamental communications issue. It could be firewall related, it could be permissions related, it's truly hard to say what the cause is because as Box293 pointed out - troubleshooting stateless UDP is not an easy process. The best thing to do at this point would be to debug it from the service end. Is this a Cisco device? If so you can use the debug snmp packets and debug snmp requests commands to identify the problem.

[raamardhani7]

If you're using snmpwalk and it's failing that means there is some fundamental communications issue. It could be firewall related, it could be permissions related, it's truly hard to say what the cause is because as Box293 pointed out - troubleshooting stateless UDP is not an easy process. The best thing to do at this point would be to debug it from the service end. Is this a Cisco device? If so you can use the debug snmp packets and debug snmp requests commands to identify the problem.

Hi..

It's a FORTINET device, will try debugging it from service end. will give a shot. thanks.

[hsmith]

Let us know what you come up with.

Thank you.

[raamardhani7]

Hi Team,

I have checked with the client for the firewall issues, they said they are not having any blocking of UDP 161 and 162 for SNMP and SNMPtraps.

password is having exclamatory mark ! in it and whenever snmpwalk command is coming across ! it is terminating.

snmpwalk -v 3 -u username -l authPriv -a sha -A A*ABC!FM$!Tue&A -x aes -X P*QRS!FM$!Tue&P xx.xx.xx.xx

-bash: !FM$!Tue: event not found.

I defined arguments in resource.cfg.
$USER3333$=A*
ABC!FM$!Tue&A
$USER4444$=P*QRS!FM$!Tue&P

snmpwalk -v 3 -u fslsnmpusr -l authPriv -a sha $USER3333$ -x aes -X $USER4444$ xx.xx.xx.xx
No log handling enabled - turning on stderr logging
Error: passphrase chosen is below the length requirements of the USM (min=8).
snmpwalk: (The supplied password length is too short.)
Error generating a key (Ku) from the supplied privacy pass phrase.

snmpwalk -v 3 -u fslsnmpusr -l authPriv -a sha USER3333 -x aes -X USER4444 xx.xx.xx.xx
No log handling enabled - turning on stderr logging
getaddrinfo: USER3333 Name or service not known
snmpwalk: Invalid address (USER3333)

Can someone help me here.. I suspect the issue is with the special characters in the password.