Forum Discussion
r23_78178
Nimbostratus
NimbostratusSNMP trap problem
Hi,logger -p local0.notice "01070640:5: Node x.x.x.x monitor status down."logger -p local0.notice "01180003:2: License load success
I have a problem with SNMP traps.
I generate them according to sol11127 and try tcpdump according to sol411 but to no avail.
All that increases is the "packets received by filter".
From what i read this field is OS specific so it doesn't help me.
I am using these traps :
logger -p local0.notice "01070728:5: Node x.x.x.x monitor status up."
My tcpdump command looks like this :
tcpdump -vvi eth0 udp port 162
Our SNMP is set without a source so I assume the default mgmt interface is used , but just in case I did one tcpdump with no interface mentioned just the port , same result.
The last trap was confirmed working on a different BIG-IP system by one of my colleagues.
Am I doing something wrong ?
Did I choose some bad trap codes ? Or am I not using proper tcpdump options ?
Please let me know.
nitassEmployee
have you tried interface 0.0?
tcpdump -nni 0.0 port 162
r23_78178Hey nitass,
tried it , this time i get a zero across the board :
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Still , the system no longer prompted me that there is no ip address as it did when i mentioned -eth0 (although the official F5 guide says that you can't use eth0:mgmt and eth0 is the mgmt interface in the tcpdump option)
Should I try some other trap ?- nitassthe first two logger commands work fine in my lab unit i.e. i do see the trap.
restarting snmpd, i.e. bigstart restart snmpd, also generate trap. would you like to try? - r23_78178I could try restarting snmpd , there's no impact right ?
And have tcpdump ready to see a trap when snmpd restarts ? Or try the before logger commands after snmod restart ? - r23_78178Posted By nitass on 07/24/2012 01:54 PM
the first two logger commands work fine in my lab unit i.e. i do see the trap.
restarting snmpd, i.e. bigstart restart snmpd, also generate trap. would you like to try?
Hey nitass,
Tried that , did indeed generate a trap.
However nothing else did - even after restarting snmpd process.
I even tried an emergency level trap :
logger -p local0.emerg "01100048:0: Log disk usage still higher than 80% after logrotate and 24 times log deletion."
Should I assume a problem with my device and contact F5 support or is my configuration off somehow ? - nitassdid you customize snmp setting e.g. /config/user_alert.conf, /etc/alertd/alert.conf?
if so, can you revert it to default and test again?
if no, yes i think you can open a support case.