DFM Alerts

Unanswered Question
Mar 16th, 2007

Hallo,

i have running DFM 2.07. For some devices is the Loopback address a NAT address. That means in DFM is the device 10.1.2.3 and the loopback0 on device is 172.18.40.3. When the device fails comes an alarm in DFM, but the alarm is not cleared when the device is up. All sources for traps and syslog are loopback0. Pinging is ok. No droping on Firewalls.

Can anyone help me ?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Fri, 03/16/2007 - 09:23

This configuration was not tested, but if DFM only sees packets from the device with address of 10.1.2.3, then it should be okay. What kind of alter/event does not clear out of DFM?

koeser Mon, 03/19/2007 - 01:01

Hi,

The alert is:

1. 0000QTC Unresponsive 172.18.40.3 [cirkom02.mydom.de 16-Mar-2007 12:50:14

Event Details are:

Event_Description Unresponsive

Component 138.201.249.5 [cirkom02.mydom.de]

IPStatus TIMEDOUT

InterfaceName IF-cirkom02.debis-sfi.de/6 [Lo0] [172.18.40.3] [Managementinterface]

InterfaceType SOFTWARELOOPBACK

InterfaceOperStatus UP

NetworkNumber 172.18.40.3

InterfaceMode NORMAL

InterfaceAdminStatus UP

Address 172.18.40.3

Where cirkom02.mydom.de is the name of 10.1.2.3

Joe Clarke Mon, 03/19/2007 - 08:51

Ah, I see. What is happening is that DFM polls the ipAddrTable for this device. Since there is no NAT ALG that supports SNMP, the addresses within the response PDUs are untranslated. DFM will then try to ping each of the untranslated addresses. When that fails, DFM generates an unresponsive alert.

There is no way to easily disable this ICMP management in DFM 2.0. There will be a way to do this in DFM 3.0 which will be part of LMS 3.0. In the meantime, if you open a service request with TAC, and reference CSCsb48643, a script can be provided which will facilitate unmanaging these IP addresses.

koeser Tue, 03/20/2007 - 06:30

Thank you. I will do so and open a case with this fact.

Actions

This Discussion