change trap port DFM

[a_jasewicz]

Hi, I have been reading about port 162 conflicts and changing the port which DFM listens on.  I have a situation where I need to change the port, however, in my reading of the threads I am missing something.  Can the DFM listening port be change unilateral or does the netapp sending the traps also have to be notified of the change port?  My situation is that we have the Solarwinds product Storage Profiler, and I would like to test drive  Management Console, which includes DFM.  I loaded DFM on the same server as Storage Profiler; Storage Profiler also is listening on port 162 for traps.  Is it possible to have both products on the same server and have the netapp send traps to both monitoring tools?  If so how is this done?

[adaikkap · Accepted solution]

I dont think port 162 can be shared between DFM adn Storage Profiler. But you can always change the trap listner port on DFM to other than 162, but changing the below option.

snmpTrapListenerPort

162

But this port is only used to receive trap from filers, and to receive the same dfm server need to be configured as trap host in filer using the cli snmp traphost, while doing the same there is no options to specify the port.

Also wiki for snmp says the following.

"The manager(in our case DFM) may send requests from any available source port to port 161 in the agent. The agent response will be sent back to the source port on the manager. The manager receives notifications (Traps and InformRequests) on port 162"

So chainging the trap listner port is just on DFM alone.

But as per the BPG you should not run anyother software on the machine on which DFM is running.

Regards

adai

[a_jasewicz]

Thank you that is sort of what I was thinking about DFM, I should have thought to go to the SNMP wiki.  I do understand about not running another software, its just a pet peeve of mine,  Why should I have to have a separate server for each application; its just more stuff to manage. I along with several others have not had much success at altering port 162 (see posts to this forum related to Trap failures).  I have attempted changing it several times and each time I get the same error. I have tried 1162, 5500, 8500.  Each time I get "Startup of Trap Listener is failed may be due to port <port#> conflict."  It looks as if I will have to spin up another VM.

[adaikkap]

I just did it and I am able to do it with out any issues. Below is the same.

[root@~]# dfm options list | grep -i snmp

hostPingMethod                        echo_snmp

monSNMPRetries                        4

monSNMPTimeout                        5

snmpTrapListenerEnabled               Yes

snmpTrapListenerPort                  162

snmpTrapRcvdMaxPerWindow              250

snmpTrapRcvdWindowSize                5 minutes

[root@ ~]# dfm options set snmpTrapListenerPort=168

Changed SNMP trap listener port to 168.

[root@ ~]#

Mar 06 12:12:49 [dfmserver: INFO]: [5107:0x411d4940]: Options changed.

Mar 06 12:12:49 [dfmserver: INFO]: [5107:0x411d4940]: Stopping snmptraplistener monitoring...

Mar 06 12:12:49 [dfmserver: INFO]: [5107:0x411d4940]: snmp port = 168

Mar 06 12:12:49 [dfmserver: INFO]: [5107:0x411d4940]: Starting snmpTrapListener thread...

Regards

adai

[RBLT_GLOBAL]

I recently copied /etc/syslog.conf.sample to /etc/syslog.conf and added an entry to send syslog to a WhatsUpGold server.  We still need to continue relying on the DFM server for status monitoring.

It seems that since enabling the /etc/syslog.conf file, the alerts appearing in DFM have stopped, except for the occasional one.  I observe this because we are getting critical low NVRAM battery alerts in /etc/messages, but only two such alerts have made it to the DFM web view.

Is there a correlation between enabling /etc/syslog.conf ( and the syslogd restarting ), and the sudden drop in events appearing in DFM ( although still appearing in the local /etc/messages file )? 

I tried renaming the /etc/syslog.conf to /etc/syslog.conf.bak, hoping to trigger another syslogd restart without a /etc/syslog.conf file in place, but I did not see a syslogd restart.

thanks

Rick

[adaikkap]

Hi Rick,

     I dont know if there is any correlation between what you are saying. Is trap alerts that you are talking about ? or Normal event alerts ?

Regards

adai

[RBLT_GLOBAL]

Perhaps my misunderstanding.  At the same time as I updated /etc/syslog.conf, I had also tweaked some volume sizes and DFM deduplication thresholds, so that likely quieted my events on DFM.  I verified by reducing DFM volNearlyFull threshold and generated DFM alerts as before...

I'll press on with obtaining NetApp MIBs to import into WhatsUpGold.  I don't want to replace DFM reports/alerts, only supplement them.

thanks,

Rick