Issues reducing DFM polling parameters - recommendations needed.

Answered Question
Apr 10th, 2007

Hi,

We have about 400 switches (L2 / L3) consisting of a traditional Cisco model (Core, Distribution, Access). Core and Distribution consist of 6500's with a mixture of Sup1/2/720's. The bulk of the switching kit exists at the access layer consisting of approximately 380 Cisco 2950's.

A single Layer 2 vlan has been cofnigured across all devices (legacy) for management. CiscoWorks LMS2.6 (with all latest patches / updates) sits on this VLAN and does what it does.

I have been investigating the possibility of using DFM as more of a real time alerting tool and have began reducing the Polling Parameters for Reachability and Environment.

After reducing the reachability poll to 30 secs, and environment to 180 secs, I have observed intermittent network outages on the management VLAN which lasts for a maximum of 1 minute. Is DFM polling too much and somehow causing a saturation on the VLAN ?

The problems have only started since I began reducing the polling timers. Changing them back to default eliminates the issue.

I am expecting too much from DFM ? Was it never intended to operate as a realtime polling tool ? and finally, does Cisco (or anyone else) have any recommendations for polling parameters ?

Thanks in advance.

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 9 years 9 months ago

I would say you're expecting too much from DFM. It was not designed to be a real-time agressive polling tool. To compensate for this, is does handle some device traps to provide a more instantaneous look at potential device health problems (see http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/dfm/dfm206/ug/trapfwd.htm for a list of traps DFM can handle).

However, I don't think you're saturating the VLAN. It is more likely the device is throttling the SNMP. I think leaving environment polling at 180 seconds is fine. I would bump up the reachability polling to at 90 seconds, then rely on traps for other problems with reachability.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
kyawzawhtut Tue, 04/10/2007 - 01:07

Hi

So far, I don't come across any recommendation for polling parameters as it is based on your network performance.

In general, polling engine itself has limitation. You need to adjust the polling frequency if you start receiving fault alarms especially "operationally down" event.

I don't think there is such NMS in the world where you can do realtime polling as it is not necessary at all in my opinion.

You can twist the setting in such a way that poll more frequent to critical devices and less frequest to non-critical devices by grouping critical devices in DFM.

HTH.

Cheers

Kyaw

Correct Answer
Joe Clarke Tue, 04/10/2007 - 05:07

I would say you're expecting too much from DFM. It was not designed to be a real-time agressive polling tool. To compensate for this, is does handle some device traps to provide a more instantaneous look at potential device health problems (see http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/dfm/dfm206/ug/trapfwd.htm for a list of traps DFM can handle).

However, I don't think you're saturating the VLAN. It is more likely the device is throttling the SNMP. I think leaving environment polling at 180 seconds is fine. I would bump up the reachability polling to at 90 seconds, then rely on traps for other problems with reachability.

Actions

This Discussion