Notifications

574 views

Description

Required Plugins

  • Prior to try Kingston - Service Mapping + Discovery 
  • From Kingston - Only Discovery 

How It Works

•A business rule called “Service Discovery - Device Complete” defined on table discovery_device_history is launched when the device discovery is complete.


•This business rule calls the java method NetworkPathManager.jsFunction_createPhysicalConnections(String deviceId).

•This method is using several strategies and information from various tables and creates relations of type ‘Connects to::Connected by’ in the CMDB.

•Those relations can be created between 2 devices (server and switch or 2 switches), between a device and a port of another device or between 2 ports of devices.

•The results can be viewed in the dependency view map by applying the ‘Physical Network Connections’ dependency type on the relevant device. Pay attention that when applying this dependency type, we always see a dependency between the devices and not between their ports (even if the ‘Connects to::Connected by’ relation in the CMDB is actually between the ports of the devices).

 

Related Tables 

•In order to create the layer 2 connections, we use the following tables:

–discovery_switch_fwd_table

•The forwarding table of the switches.

–discovery_device_neighbors

•Used in order to find layer 2 connections between switches.

•Contains a field called neighbor_source which can be CDP or LLDP.

–discovery_switch_spanning_tree_table

•Used in order to find layer 2 connections between switches.

–discovery_switch_bridge_port_table

•Used to map between port number in discovery_switch_fwd_table and interface index.

 

•Port tables:

–cmdb_ci_network_adapter

–dscy_switchport

–dscy_router_interface

–cmdb_ci_lb_interface

•All the tables are populated during the horizontal discovery of the device.

 

Layer 2 Connection Strategies  

PhysicalHostConnectionStrategy – Creates layer 2 connections between a discovered server, which is not a network device, and a network device.

VMLayer2ConnectionStrategy - Creates layer 2 connections between a VM and a network device.

NetworkDeviceLayer2ConnectionStrategy - Creates layer 2 connections between a network device and its neighbors.

SpanningTreeLayer2ConnectionStrategy - Creates a layer 2 connection between network device and the parent of the network device in the spanning tree.

JavaScriptLayer2ConnectionStrategy – Calls a java script function with empty implementation. We can add the function implementation on a customer instance in case we want to add another strategy. 

 

PhysicalHostConnectionStrategy 

•Creates layer 2 connections between a discovered server, which is not a network device, and a network device.

•Prerequisites: 

–Horizontal discovery of the server and the network device.

•Step 1: Find the ports of the server.

•Step 2: For each port, try to find if there is a layer 2 connection from the port:

– Get the MAC address of the port.

–Navigate to discovery_switch_fwd_table and search for records with this MAC address (and status field is not ‘self’).

–For each such record, search if there are more records in the forwarding table with the same switch and port but with different MAC addresses.

–Only in case there is only a single MAC on the port in the forwarding table of the switch, create a layer 2 connection (if we have more than one MAC it indicates that there is more than one source address so there is no layer 2 connection between the server and the switch).

•Step 3: Try to find the port of the target switch and create the layer 2 connection

–Navigate to discovery_switch_bridge_port_table and query this table by the switch and the port number from the discovery_switch_fwd_table .

–If a record found, get the interface index of the record.

–Query dscy_switchport by the switch and interface index in order to find the port.

–If not found, Query dscy_router_interface by the switch and interface index in order to find the port.

–In case the port of the switch was found, create a relation of type ‘Connects to::Connected by’ between the port of the server to the port of the switch. Otherwise, create a relation of type ‘Connects to::Connected by’ between the port of the server to the switch itself.

 

VMLayer2ConnectionStrategy 

•Creates layer 2 connections between a VM and a network device.

•Prerequisites:

–vCenter discovery

–Horizontal discovery of the ESX and all the VMs that are on this ESX.

–Horizontal discovery of the network device.

•Step1: Find the ESX of the VM and find all the VMs on this ESX. Get the MAC addresses of the ESX and all the VMs.

•Step 2: Find the ports of the VM. 

•Step 3: For each port, try to find if there is a layer 2 connection from the port:

–Get the MAC address of the port.

–Navigate to discovery_switch_fwd_table and search for records with this MAC address (and status field is not ‘self’).

–For each such record, search if there are more records in the forwarding table with the same switch and port but with MAC addresses that don’t belong to the ESX or one of its VMs. Count the number of such exceptional MAC addresses.

–Only in case the number of exceptional MAC addresses is very low (less than 3 and less than 15% of all MAC addresses of the ESX and VMs), create a layer 2 connection.

•Step 4: Try to find the port of the target switch and create the layer 2 connection

–The same logic as in PhysicalHostConnectionStrategy.

 

NetworkDeviceLayer2ConnectionStrategy 

•Creates layer 2 connections between a network device and its neighbors.

•Prerequisites: 

–Horizontal discovery of the network devices (switches or routers).

•Step 1: Find the ports of the switch.

•Step 2: For each port, try to find if there is a layer 2 connection from the port:

–Navigate to discovery_device_neighbors table and query the table by the switch (configuration item) and the port (origin interface).

–Look at the neighbor address and neighbor interface of the record.

–Ignore records that their neighbor interface is with install status = absent.

–If we have exactly one neighbor with neighbor address or neighbor interface or both, we will create a layer 2 connection.

•Step 3: create a layer 2 connection

–In case the neighbor interface exists, create a relation of type ‘Connects to::Connected by’ between the origin interface to the neighbor interface. Otherwise, create a relation of type ‘Connects to::Connected by’ between the origin interface to the switch with the neighbor address.

  

JavaScriptLayer2ConnectionStrategy 

•JavaScriptLayer2ConnectionStrategy is calling to createConnections (hostId) function in Layer2ConnectionStrategy script include.

•The implementation of this function is empty and can be replaced by any other implementation on a customer instance in case we want to add another strategy or override an existing strategy.

 

Known Problems 

•discovery_switch_fwd_table and discovery_device_neighbors extend a table called discovery_net_base.

•discovery_net_base table has a field called ’absent’ which is used to indicate old records.

•There is a table cleaner on discovery_net_base table that deletes records with absent=true and sys_updated_on is at least 30 days old.

•PRB1260562 - Currently we don't consider the 'absent' field in the code that creates the layer 2 connections. As a result, sometimes layer 2 connections are not created.

•PRB1258317 - Records can flip from absent=false to absent=true.

•Those problems are targeted for JP9, KP5 and L.

•Layer 2 connection is not presented in the dependency view (‘Connects to::Connected by’ relation exists in the cmdb, but does not appear in the dependency view when applying the ‘Physical Network Connections’ dependency type):
 
–Run the following script in scripts-background:
var npm = new SNC.NetworkPathManager();
npm.getNetworkNeighbors(<host_sys_id>);

If you get error which is similar to the following: ‚Syntax Error or Access Rule Violation detected by database (Unknown column 'cmdb$par10.a_ref_8' in 'where clause’)’, open a task to Persistence team

 

Change in London 

•The call to the java method NetworkPathManager.jsFunction_createPhysicalConnections(String deviceId) was moved from the business rule to a Script action named ‘Create Layer 2 connections’.

•The script action listens to the event called ‘discovery.device.complete’.

 

 

Article Information

Last Updated:2019-12-02 03:04:19
Published:2019-12-02