How Spectrum Infrastructure Manager creates connections

Products

• Spectrum

Issue/Introduction

Description:

Overview of the basic connection determination and building process in the Spectrum Infrastructure Manager product

 

Environment

Release:
Component: SPCINT

Resolution

Solution:

Note that this knowledgebase article is an overview of the generic method by which Spectrum determines and builds connections between interfaces on Routers or Switches and the far end network devices, such as servers. This covers the connection information available in the public MIB areas queried by Spectrum. If the devices involved utilizes vendor specific enterprise or private MIB tables to expose their connection information, the information in this knowledgebase article will not apply.

Routers or Switches to Far End Device Connections (non-VLAN)

How Spectrum builds connections from Routers or Switches to far end devices, such as servers, is done through the dot1dBridge MIB tables (1.3.6.1.2.1.17).

1. First Spectrum queries the dot1dTpFdbAddress OID (1.3.6.1.2.1.17.4.3.1.1) table on the Switch or Router. Spectrum looks for MAC addresses in that table and notes their instance values associated to the MAC addresses present.
   
   
2. Spectrum then takes the instance associated with the MAC Address from the dot1dTpFdbAddress table entry and looks at the dot1dTpFdbPort OID (1.3.6.1.2.1.17.4.3.1.2) table values.
   
   
3. Spectrum then looks for and finds the same instance in the dot1dTpFdbPort table entries and its associated value.
   
   
4. Spectrum then takes the value for the instance from the dot1dTpFdbPort table entry and reads the do1dBasePortIfIndex OID (1.3.6.1.2.1.17.1.4.1.2) table searching for the index value found in the do1dTpFdbPort table. This provides Spectrum with the ifIndex OID (1.3.6.1.2.1.2.2.1.1) table value of the port involved in the connection.
   
   
5. Spectrum then looks to match that ifIndex value found in the do1dBasePortIfIndex table entry and looks for an interface modeled on the Switch or Router that uses that ifIndex value.
   
   
6. Lastly Spectrum then searches its modeling database for a model present with the MAC address of the far end connected device first identified in step 1 above. If found on a modeled device, Spectrum builds a connection to that device. If it is not found, no connection will be made. Both ends of a connection must be modeled in Spectrum for the connection to be built.

If any data point in the flow noted here is missing or incorrect, it will be a likely cause for no connection created. If that is found to be the case there is some problem with the MIB data not being correct, or not being updated correctly, by the device. It could be a firmware bug, or a misconfigured device. In either case only the network administrator of the device, or the device vendor, can help to determine the cause of that and its resolution.

Routers or Switches to Far End Device Connections (VLAN)

When it comes to VLAN interfaces that host interfaces, there is a small difference from the above data flow in debugging these connection issues. VLAN configurations host their own instances of the dot1dBridge MIB tables in the MIB data. If the missing connection is related to an interface hosted or managed by a VLAN configured on the device, you won't see the data flow noted above through the standard MIB Tools queries when investigation this data. In order to see the instances of the dot1dBridge tables for a given VLAN, you will need to first identify the VLAN ID involved.

As an example let us assume that the VLAN involved is VLAN100. Also as an example let us assume that the community string of the device being examined is 'public'. When in MIB tools, to query the devices standard dot1dBridge tables you would enter its IP address, community string and SNMP version in the "Contact Criteria" pane of the MIB Tools UI (change the port in the 'Advanced Options' area of the "Contact Criteria" pane - default port is 161), select the Contact button* to get a successful connection and begin querying the dot1dBridge tables.

But in the case of a VLANs instances of the dot1dBridge table you will need to modify the community string. In the example noted here, you would change the community string in the "Contact Criteria" pane from 'public' to 'public@100', then select the Contact button* to get a successful connection to the dot1dBridge table instances for VLAN100. Once that has been done, you can then continue following the data flow as noted above.

*NOTE: if you get a red box around the "Contact Criteria" pane the connect was not successful and further MIB queries for this device will also fail. Double check the information entered as well as the port specified, and if querying a VLAN, that the correct VLAN ID number is used, to ensure the correct values are set. Successful contact is indicated by a green box around the "Contact Criteria" pane in the MIB Tools UI.