How Error control determines the root-cause of a "No response from device" event

As of Monitor one version FP1.89.343 RC1 an important modification in the way Error control (EC) works is introduced. In previous versions EC did not take the routing or switching nature of devices into account. The routing or switching nature of equipement is determined by a new setting at the Class level. This modification may have consequences for projects that have been created with an older version of Monitor one! Read the information below carefully!

Every time a device stops responding to status requests, EC verifies the status of all devices in the chain (network path) of devices from the ThisStation object to the device that stops responding. If one of the devices in the chain already has the “No response” status, Monitor one assumes this the root-cause of the event. In this case, the device that stops responding gets the blue tick.

If more than just one chain exists (because of network redundancy), Monitor one verifies all possible network paths!

In order to determine all possible network path(s) from the “ThisStation object” to a device, Monitor one needs two pieces of information:

1. Link or connection information (which device is connected to which other device)
2. If a device has more than one connected interface, does this device forward traffic? Does it route or switch packets or is the second interface just used for redundancy reasons and is it "hot-standby"?

Monitor one extracts link or connection information from the network map. It is therefore extremely important to draw network maps as factually as possible. The information whether or not a device forwards traffic comes from the definition of the class each device belongs to (The checkbox This device forwards traffic via routing, switching, bridging or repeating on the Add/Modify a class window). It is obvious that if you fail to set this option correctly, EC will not work as expected!

The list below shows some examples of device classes that forward traffic.

• Routers, switches, hubs and/or repeaters.
• Firewalls
• Modems.
• Wireless Access-points
• Multi-homed Windows servers with running RRAS services (routing enabled)

The list below shows examples of devices with more than one connected interface that do not forward traffic

• Windows servers with more than one interface connected to one ore more switches, from which only one interface is active and the others "hot-standby".
• Servers in a SAN cluster that have an interface connected to the network and another interface connected to a fiber switch in order to access data on a central storage. The latter interface is not used for forwarding traffic but only for accessing the data on the central storage.

Verifying network paths used by Error control

You can verify whether your map is "EC proof" by enabling EC and after that clicking the speedbutton on the Monitor one control panel.

Example 1)

A small company has two offices in different cities connected by internet via ADSL. The Firewall in the main office has a problem and is down. As you can see from the screenshot, EC is enabled (the "ThisStation" object is present on the map) but nevertheless all devices in the remote office have been marked "down" (erroneously)!

In the above case, the problem is caused by not checking the This device forwards traffic…. checkbox for the class the device "InternetCloud" belongs to. As a result, Monitor one "thinks" that it cannot reach the remote office devices at the other end of the WAN link. Monitor one "thinks" that there are no network paths available from the "ThisStation" object to the devices in the remote offices and displays the little "network disconnected" symbols at the bottom left of each device in the remote office. The "InternetCloud" device represents the huge internet routing network in one device!

After checking the This device forwards traffic…… checkbox for the class the "InternetCloud" device belongs to, the network map shows:

Example 2)

The screenshot above shows another interesting example. For reasons of redundancy, a cluster system has two connections to two different switches. Only the first NIC of the cluster is active, the second one is "Hot-standby". By mistake, the Forward setting of the class the device "Cluster1" belongs to is checked. Switch4 is actually down! Because of the forward setting of "Cluster1", Monitor one "thinks" that there is an alternate network path to device "Switch3", gets no reply from device "Switch3" and marks it accordingly.

After clicking the EC verifier speedbutton on the Monitor one control panel, the map shows:

Only TestServer1 has the "No error control information available" indicator (it is not connected!).

After resetting the Forward control (unchecking the checkbox) of the class the device "Cluster1" belongs to, the map shows:

Recommendations

Users that use projects created with an older version of Monitor one are strongly advised to verify the This device forwards traffic... setting at the class level of all classes in use by the project!