Use > Discovery Modules > Network Infrastructure > Layer2 Discovery > Layer2 Discovery Flow

Layer2 Discovery Flow

This section describes the possible use cases and the discovery flow of the Layer2 Discovery.

Possible Use Cases

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

  • 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.

ClosedDefault (Legacy) Flow

Overview

This discovery flow is the first one that appeared in UCMDB. 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 according to 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.

Prerequisites

  • The SNMP protocol is defined.
  • Switches related IP address ranges are defined.

Run the discovery

Run the jobs in the following order:

  1. Range IPs by ICMP
  2. Host Connection by SNMP
  3. Host Networking by SNMP
  4. VLANs by SNMP
  5. VLAN ports by SNMP
  6. Layer2 Topology VLAN-based by SNMP – For Switches with VLANs (In the modern world all of them) or
    Layer2 Topology Bridge-based by SNMP – For Non-VLAN based Switch connectivity
  7. Process Layer2 Saved Files

For details on running jobs, refer to "Module/Job-Based Discovery" in the Data Flow Management section of the UCMDB Help.

Limitations

  • It is expected that relationships to virtualization solution boxes are not detected because more than one MAC address will be visible on the interface pointing to, for example, VMware ESX server.
  • If some other dummy device or the one does not support the corresponding SNMP Management Information Bases (MIBs) in the Layer2, the device will not be detected.
  • For a set of devices that have the same MAC addresses on multiple interfaces, the reported topology might fail to reconcile.

ClosedSpecific Switch Discovery Protocol Based Flow

Overview

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.

Prerequisites

  • The SNMP protocol is defined.
  • Switches related IP address ranges are defined.
  • CDP or LLDP is supported by the target devices.

Run the discovery

Run the jobs in the following order:

  1. Range IPs by ICMP
  2. Host Connection by SNMP
  3. Host Networking by SNMP

  4. Layer2 Topology CDP-LLDP based by SNMP

For details on running jobs, refer to "Module/Job-Based Discovery" in the Data Flow Management section of the UCMDB Help.

Limitations

  • Only Switch-to-Switch relationships are reported.
  • The corresponding protocol must be supported by the device.
ClosedVirtual Machine to External Physical Switch Relationship

Overview

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.

Prerequisites

  • The VMware VIM protocol is defined.
  • IP address ranges are defined.
  • CDP or LLDP is supported by the target devices.
  • The SNMP protocol is defined for the Physical Switches.

Run the discovery

Run the jobs in the following order:

  1. Range IPs by ICMP
  2. Host Connection by SNMP (to get the physical switches in the UCMDB)

  3. VMware vCenter Connection by VIM

  4. VMware vCenter Topology by VIM

For details on running jobs, refer to "Module/Job-Based Discovery" in the Data Flow Management section of the UCMDB Help.

Limitation

Must enable the support for CDP or LLDP on both the ESX server and the connected Switch.

Send Help Center feedback