Layer2 Discovery Flow

Possible Use Cases

In general any Layer2 end-to-end discovery scenario might be a composition of the following items:

Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Discovery of inter-Switch connectivity

Discovery of Host to Switch connectivity

Discovery of Virtual Machine to Physical Switch connectivity

Discovery Flow

In Universal Discovery, a set of Layer2-related jobs must be run in a particular sequence to get the full topology. Though depending on the use case and customer environment, the configuration here might be some shortcuts.

Note These discovery flows are not isolated ones, and it is expected that some or all of them might be used at the same time to reach the final goal – a full traversal of Layer2 Connections.

Default (Legacy) Flow

This discovery flow is the first one that appeared in UCMDB many years ago. It can report both Switch-to-Switch and Switch-to-Server connections. All the information is fetched from the Switch side, so all discovery jobs trigger on switches or routers and the related topology pieces.

The background idea of this discovery flow is to filter out ignored or virtual MAC addresses in reading the ARP caches for a particular interface on the switch, and then to decide if that port or interface is connected to a Switch or to the Server.

The criterion that the port is considered to be connected to the Server is that only one physical MAC address is behind that port; otherwise the port is considered to be a Switch-to-Switch connection port.

If the port or interface is considered to be a Server connectivity port, the Layer2 Connection CI is reported right away; otherwise the data is dumped to the Data Flow Probe File System to make a post-analysis later on in another job and to find the proper second interface on the remote Switch to report a Layer2 Connection CI.
The criterion according to which interfaces on two different switches are considered to have a relationship is as follows:
1. MAC address of Interface A is present in the ARP cache of Interface B
2. MAC address of Interface B is present in the ARP cache of Interface A
3. If rules a and b match for more than two interfaces, the length of the ARP caches is also measured, and the one with the lowest amount of MAC addresses is selected, which means that the interfaces are the closest ones; thus the interfaces are the really connected ones.
Note If a switch port has multiple VLANs assigned, the ARP caches for the very same interface under different VLANs are completely different ones. So "interface" in this topic means the interface instance with the real life limitations and setup.

Specific Switch Discovery Protocol Based Flow

The task of finding out "who is on the other side of the wire" is not a new one in the Network Industry. To have a good answer for that question, a set of specialized protocols have been developed. Some of them are open; others are not.

Currently, Universal Discovery supports Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP) as data sources for obtaining the Layer2 related information. In order to get anything using these protocols, it is mandatory for both sides (both devices on the wire) connected to each other to support and activate the same discovery protocol. Due to that fact these protocols are widely referenced as Switch-to-Switch discovery protocols. In general that is true, but last days it is possible to hear that the support for those protocols are added on the OS level as well (for example, Linux) and it will be reasonable to expect that one day that limitation will go away, but as of now only Switch-to-Switch Layer2 connections are expected to be discovered.

Virtual Machine to External Physical Switch Relationship

Currently, only the VMware solution is well supported if the environment is managed by the vCenter. These types of relationships come out from the VMware related jobs, not from the Layer2 discovery. The key point to report such an external topology piece is that VMware ESX servers have a option to support CDP and LLDP protocols, so the information regarding "who is on the other side of the wire" might be available. By default this option is turned off. If this option is enabled by the administrator in the vCenter UI and in the corresponding API, that information becomes available, so you can discover and report it.

Note

If the support for CPD or LLDP is enabled on the ESX, it is also possible to fetch the ESX interface to Physical Switch interface via the Layer2 Topology CDP-LLDP based by SNMP job, but if no VMware related jobs run, the Virtual Network Topology part will not be available.

Virtual Network Topology is modeled in a different manner than the real one, so do not expect to the same network connectivity picture for virtual machines as for physical machines.