ssvsergeyev / zenpacks.zenoss.layer2 Goto Github PK

This ZenPack provides support to model OSI Layer 2 (or data link layer) topology. Than that topology information is used to suppress events from devices connection to which was lost because they are connected to broken devices. Data collection is performed using SNMP.

<gallery widths="250px" heights="127px"> CDPLLDPDiscover.PNG ClientMACs.PNG NeighborSwitches.PNG </gallery>

The features added by this ZenPack can be summarized as follows. They are each detailed further below.

• Discovery and periodic remodeling of Neighbor Switches using CDP/LLDP.
• Monitoring of MAC Address table or Forwarding Table for each network interface of device.
• Creating connections between devices, based on Forwarding table information.
• Event suppression based on network map connectivity.

Layer2 ZenPack adds almost no new components by itself, it just models client mac addresses on interfaces of existing bridge devices.

CDP/LLDP based collector plugin zenoss.snmp.CDPLLDPDiscover performs discovery of switches located nearby a selected device.

ZenPack binds Layer2Info monitoring templates to /Network device class in Zenoss. This results in monitoring Layer 2 MAC forwarding tables for such devices. On a detail view of Interfaces component added Clients MAC addresses sub-panel with a list of MAC addresses. Those are grouped by client device they belong to.

The ZenPack binds Layer2Info monitoring templates to the /Network device class in Zenoss. This activates monitoring of Layer 2 MAC forwarding tables for devices under that class. On the detail view of Interfaces components, the Clients MAC addresses subpanel is added with a list of MAC addresses.

When a device through which zenoss connects to other devices it monitors goes down, a flood of Device is DOWN! events for every device in an affected subnet can be generated. This ZenPack adds a zenevent plugin which suppresses such subsequent events for devices behind device which is down. As a result, a system administator receives only a primary, core error event.

To determine connectivity of device to zenoss instance, this zenpack needs to know where on the network map zenoss instance is located. It is described on Configuration properties of devices class in zZenossGateway zproperty. At zenpack installation it populated with value found in /proc/net/route. If required, you may manually put there id of the zenoss device, or device to which it is connected.

Network map

To inspect interconnections between devices it is possible to use a network map page which is accessed by "Infrastructure" -> "Network Map" tab or "Network Map" menu item of the opened device. It shows connections between devices, interfaces, networks and other entities. In addition, it shows device status (Color of the event with the highest severity for that device).

To display a network map the form on the left side of network map should be filled. "Device ID" field with name or ID of the device starting from which the map will be explored. The depth of the map means how many hops to do when exploring the map. Also, it is possible to select network layers which should be visible on the map. By default all of them will be displayed. To apply changes or create new network map, press "Apply" button at the bottom of the form.

Right mouse click above node opens context menu with options available. 'Pin down' option allows to unpin chosen node. Detailed information about device is available by clicking on 'Device Info' option from context menu. To draw network map in scope of another node please choose 'Put map root here' option from context menu. It is possible to open device or device component by clicking on corresponding target of network map.

Map could be zoomed using mouse wheel, and panned using mouse. If it disappears from the view, it could be bringed back, using "Center" button in the top right corner of the map. There is also zoom level indicator, and color legend.

To update catalog with connections for network map, is used zenmapper daemon. It runs every 5 minutes by default, but this option could be changed by passing desired number of seconds to the --cycletime argument.

Imagine, for example that we want to display on the network map connections of VMware NSX components. They are modelled in NSX zenpack.

We need to create new class, called for example NSXConnectionsProvider, which inherit from BaseConnectionsProvider, like this:

1. our provider will inherit from this:

1. and will yield this:

So, we described how to get connections, now we need to tell zenoss, that this will be connections provider for any NSXManager devices. We do it by registering adapter in our zenpack's configure.zcml:

Another way to include adapters, is to put them in separate file, called for example layer2.zcml:

and than include that file conditionally:

<syntaxhighlight lang="xml"> &lt;include file=&quot;layer2.zcml&amp;#10;&quot; xmlns:zcml=&quot;http://namespaces.zope.org/zcml&amp;#10;&quot; zcml:condition=&quot;installed ZenPacks.zenoss.Layer2.connections_provider&quot;&gt;&lt;/include&gt; </syntaxhighlight>

To test connections that your provider yields, you could run

zenmapper run -v10 -d <name></name>

And then look it up on the network map.

This ZenPack has two separate capabilities. The first is to collect clients connected to switch ports so that event suppression can be done when the switch fails, and the second is to discover neighbor relationships between network devices using the CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discover Protocol).

To enable discovery of clients connected to switch ports you must bind the Layer2Info monitoring template to switch devices. The discovery is done using BRIDGE-MIB forwarding tables, so it's a prerequisite that the switch supports BRIDGE-MIB. It's recommended to only bind the Layer2Info monitoring template to access switch to which monitored servers are connected.

The Layer2Info in this monitoring template has a default cycle time of 12 hours or 43,200 seconds. A 12 hour cycle was chosen because the datasource's function is to model, and the default modeling interval is also 12 hours. Reducing this cycle time is not recommended if the template is going to be bound to a large number of switches. The recommendation is that you should bind the template to no more than 3,600 devices per hub. If you reduced the cycle interval to 6 hours you would cut that number of devices per hub in half to 1,800 devices.

To collect neighbor information from network devices that support CDP or LLDP, you must enable the ``zenoss.snmp.CDPLLDPDiscover`` modeler plugin for the devices.

This ZenPack has the following requirements.

PythonCollector ZenPack

This ZenPack depends on PythonCollector being installed, and having the associated zenpython collector process running.

When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact capability based on Layer 2 data. The following service impact relationships are automatically added. These will be included in any services that contain one or more of the explicitly mentioned entities.

Service Impact Relationships

• Device impacted by upstream switch device.

Please refer the the Zenoss Service Dynamics documentation if you run into any of the following problems:

• ZenPack will not install
• Adding a device fails
• Don't understand how to add a device
• Don't understand how to model a device

If you cannot find the answer in the documentation, then Resource Manager (Service Dynamics) users should contact Zenoss Customer Support. Core users can use the #zenoss IRC channel or the community.zenoss.org forums.

The essential mechanism that separates network switches from network hubs is the MAC forwarding table. Instead of broadcasting incoming link layer frames to all it's interfaces, as hubs do, switches look into the forwarding table to find out which particular interface is connected to the destination device. The switch learns which devices are connected to which interface by looking at the source MAC address of incoming frames. Those MAC addresses are called "client MAC addresses".

Installing this ZenPack will add the following items to your Zenoss system.

Modeler Plugins

• zenoss.snmp.CDPLLDPDiscover

• Layer2Info (in /Network)

• zZenossGateway

• zenmapper

1.1.0

• Fix Network Map - Missing link from Cisco device to subnet on depth 2,3,4 (ZEN-18603)
• Make Impact use new connections catalog instead of macs catalog (ZEN-18636)

1.0.2

• Fix modeling of CDP neighbor switches with IPv6 addresses. (ZEN-17248)
• Avoid community@VLAN context querying for non-Cisco switches. (ZEN-17258)
• Change default cycletime for Layer2Info from 30 minutes to 12 hours. (ZEN-17031)

1.0.1

• Fix device overview links error. (ZEN-14063)
• Remove add/remove from catalog logging. (ZEN-15465)
• Fix usage of incorrect community VLAN suffixes on BRIDGE-MIB queries. (ZEN-16951)
• Fix looping of impact relationships between switches. (ZEN-17020)
• Fix incorrect modeling of neighbor switches and improve modeling time. (ZEN-17023)
• Stop binding Layer2Info template to /Network by default. (ZEN-17035)

1.0.0

• Initial release