Smarts: How to determine if Smarts is building LLDP connections correctly
Article ID: 332004
Updated On:
Products
Issue/Introduction
This article explains how to determine if Smarts is building an LLDP connection correctly.
LLDP connections are not being represented correctly in the Smarts IP topology, leading to issues with Alerts not being correct and correlation not being correct
Environment
Cause
There is an issue in the Smarts IP 8.1.x - 8.1.4 software and the IP 9.x - 9.2.1 that is causing the software to use the wrong indexes when creating the cable connections in the Topology. The cables are technically built correctly by the software, but topology objects are not built correctly, this leads to confusion and issues with event correlation. The errors are in the logic for the ic-lldp-post-processor.asl script.
Resolution
The following sections explain and illustrate how to identify if Smarts is properly representing LLDP cable connections between two devices.
Identifying the connection in Smarts
This example will consider two switches (network switch 01 and network switch 02) where the trunk cable is not being represented correctly. These switches are going to be referred to as ns01 and ns02 respectively. To begin to identify this issue, you need to search for an instance of a trunk cable for one of the two devices as shown in Fig 1.
Fig. 1
The above results show this cable connection in Smarts as being established between port 45 (Gigabit Ethernet 1/0/45) on ns01 and port 216 (Gigabit Ethernet 1/0/46) on ns02.
Confirming the connection configuration
To confirm whether the connection found above is correct, the detailed configuration of both switches needs to be investigated. This can be done by running the show neighbor command against the port on one of the switches. Where this issue exists, the show neighbor output will differ from what is seen in Smarts. Fig. 2 below illustrates the show neighbor responses for our example. In this example, running the show neighbor command against port 1/0/45 on switch ns01 shows that this port is connected to port 216 on ns02. However, port 216 is actually Gigabit Ethernet 4/0/48, not Gigabit Ethernet 1/0/46.
Note: The segment in red is the remote information (data from ns02) for ns01 and the segment in green is the remote information (data from ns01) for ns02.
Fig. 2
As indicated in the show neighbor output above, the remote port information (Port ID) on one switch lines up correctly with the Port ID on the remote switch. The remote Port ID on ns01 for GigabitEthernet1/0/45 points to GigabitEthernet4/0/48 on ns02, and the remote Port ID on ns02 for GigabitEthernet4/0/48 points to GigabitEthernet1/0/45 on ns01. Both switches (ns01 and ns02) indicate a cable connection to each other on Ports GigabitEthernet1/0/45 and GigabitEthernet4/0/48 respectively. However, as noted previously, the Smarts software does not indicate this same connection information. The Smarts software displays Port GigabitEthernet1/0/45 on ns01 as being connected to GigabitEthernet1/0/46 on ns02 as highlighted in Figure 3 below.
Fig. 3
Verifying SNMP connection data received by Smarts
The SNMP data that the switches are sending to the Smarts software when Smarts requests data can be seen in Figure 4 below. The data highlighted in red is the SNMP response from switch ns01 to the Smarts software for Port ID GigabitEthernet1/0/45. The data highlighted in green is the SNMP response from switch ns02 to the Smarts software for Port ID GigabitEthernet4/0/48 (the port ID the data is for can be identified by looking at the Local port ID entries value).
Fig. 4
As can be seen in the Remote port ID output highlighted in each response, the data that ns01 and ns02 supplied to the Smarts software matches the configuration data on the switches shown by the show neighbor command in Fig. 2.
As highlighted in detail in Fig 5 below, the remote information in the SNMP responses to Smarts on ns01 Port ID GigabitEthernet1/0/45 match correctly and exactly with the corresponding local information on ns02 for Port ID GigabitEthernet4/0/48, and vice versa. This indicates that both switches (ns01 and ns02) are showing the same correct data for each switch and sending the same correct data to the Smarts software.
Fig. 5
Looking again at the incorrect TrunkCable built by Smarts highlighted in Fig 6 below, it can be seen that the Smarts software correctly considers the two ports used in the cable connection are Port 45 for ns01 and Port 216 for ns02. However, this figure also shows that the Smarts software incorrectly considers Port 216 to be GigabitEthernet1/0/46 instead of the actual GigabitEthernet4/0/48, while it correctly considers Port 45 to be GigabitEthernet1/0/45.
Fig. 6
Finding the cause of the issue
The preceding sections have shown that the TrunkCable connection is not being properly represented by the Smarts software. To understand why this is happening the source of the erroneous information needs to be identified. Continuing the same example, searching the Smarts topology for the GigabitEthernet4/0/48 ports and GigabitEthernet1/0/46 produces the following results shown in Fig. 7:
Fig. 7
As can be seen in Fig. 7 the Smarts software thinks that GigabitEthernet4/0/48 belongs to Port 162 and that GigabitEthernet1/0/46 belongs to Port 216 (red and green boxes respectively).
Using Notepad++ the port data can be searched for in the SNMP walks of each device. The SNMP walks are files that contain the same data that Smarts requests from devices to discover and build the devices into the topology. Searching the SNMP of each device for their respective data reveals the following search results in Notepad++.
Fig. 8
The data that was searched against in the walks of ns01 and ns02 were GigabitEthernet1/0/45 in ns01, GigabitEthernet4/0/48 in ns02, and GigabitEthernet1/0/46 in ns02. The reason for searching GigabitEthernet4/0/48 and GigabitEthernet1/0/46 in ns02 is because both of these Port IDs are present in the port list for the ns02 device in Fig 7.
The OIDs (Object ID) in the search results that are of concern represent the following:
-
.1.0.8802.1.1.2.1.4.1.1.7.<lldpRemIndex>.#.1 = lldpRemPortId -> This is the remote Port ID in the LLDP MIB (used earlier in the examination of this problem). Where lldpRemIndex is the index assigned by the SNMP agent. Where # is the port number for the LLDP port, not the port number for the physical port on the switch also known as the ifIndex.
-
.1.0.8802.1.1.2.1.3.7.1.3.# = lldpPortId -> This is the local Port ID in the LLDP MIB (used earlier in the examination of this problem). Where # is the port number for the LLDP port, not the port number for the physical port on the switch also known as the ifIndex.
-
.1.3.6.1.2.1.2.2.1.2.# = ifDescr -> This is the description of the physical port. Where # is the ifIndex for the physical port on the switch.
-
.1.3.6.1.2.1.31.1.1.1.1.# = ifName -> This is the name of the physical port with ifIndex #.
The following information can be seen from Fig. 9 below:
It can be seen in the green box that LLDP port 160 with an lldpRemIndex of 50843 has a lldpRemPortId (.1.0.8802.1.1.2.1.4.1.1.7.50843.160.1) value of GigabitEthernet1/0/46. This information is for another connection to another switch which has a port with the port ID GigabitEthernet1/0/46 and is not participating in the connection being examined. But the physical port 216 (ifIndex 216) on the switch also has a name GigabitEthernet1/0/46. This is the information that is seen in the search results presented in Fig. 7. It can also be seen in the blue boxes that LLDP port 216 and LLDP port 45 have a lldpPortId (.1.0.8802.1.1.2.1.3.7.1.3.216) of GigabitEthernet4/0/48 and GigabitEthernet1/0/45 respectively. Which correctly lines up with the show neighbor configuration data in Fig. 2.
Fig. 9
Comparing the black boxes in the large red box in Fig. 9, it can be seen that the data for the physical port numbers on the switches matches the description of the port showin in Fig. 7. Port 162 on ns02 has an interface name and an interface description of GigabitEthernet4/0/48 while Port 216 on ns02 has an interface name and an interface description of GigabitEthernet1/0/46. This is where the Smarts software is making its topology building mistake.
As seen in the show neighbor information for ns02 in Fig. 2 the LLDP Port number for GigabitEthernet4/0/48 is Port 216, but the physical port number on the switch for GigabitEthernet4/0/48 is port 162 (1.3.6.1.2.1.31.1.1.1.1.162 in Fig. 9). When Smarts is building the Trunk Cable it is incorrectly mapping the information from the ifName and ifDescription (1.3.6.1.2.1.2.2.1.2 and 1.3.6.1.2.1.31.1.1.1.1 respectively) for physical port (ifIndex) 216 to LLDP port 216. But LLDP port 216 should instead map to physical port (ifIndex) 162.
To confirm the findings it would be wise to check the ns02.mimic file to see what LLDP port 216 maps to. Searching the mimic file for the lldpRemPortId oid produces the results seen in Fig. 10. As can be seen from the outlined search value (.1.0.8802.1.1.2.1.4.1.1.7.49532.216.1) the LLDP port 216 maps to a remote port with port ID GigabitEthernet1/0/45. Which was confirmed earlier on in Fig. 5 as the correct mapping.
Fig. 10
Searching the ns02 MIB in Notpad++ for a possible mapping from port 162 to port 216 (162: 216), or from port 216 to port 162 (216: 162) produces the following results in Fig. 11:
Fig. 11
The top section of the search is not very useful, even though it looks like those OIDs map something with an index of 162 to another value of 216. This is because the OIDs 1.3.6.1.4.1.25506.8.35.1.1.1.# are H3C oids, but and are not part of the LLDP.
The values in the bottom section in the red and green boxes on the other hand can be looked up in an OID viewer. The value in the red box is promising because it is easy to see from the 8802 value in the OID that it is part of the LLDP MIB. The OID in the green box though is not part of the LLDP MIB, it is in fact part of the BRIDGE MIB. The definitions of the two oids are as follows:
-
.1.0.8802.1.1.2.1.5.4623.1.2.3.1.2 = lldpXdot3LocLinkAggPortId: This object contains the IEEE 802.3 aggregated port identifier, aAggPortID (IEEE 802.3-2002, 30.7.2.1.1), derived from the ifNumber of the ifIndex for the port component in link aggregation. If the port is not in link aggregation state and/or it does not support link aggregation, this value should be set to zero.
-
1.3.6.1.2.1.17.1.4.1.2 = dot1dBasePortIfIndex: The value of the instance of the ifIndex object, defined in MIB-II, for the interface corresponding to this port
Both of these values show an apparent mapping from the logical Port number in the LLDP to the physical port. But given that the first value is from the LLDP-MIB it is the value that will be used for the mapping.
This evidence shows that there is a mapping in the MIB from the LLDP port of 216 to the physical port of 162 and that the Smarts software is incorrectly associating the information from physical port 216 to the trunk cable connected to physical port 162. This should be all the evidence needed to demonstrate a connection is not being represented correctly by the Smarts software.
Additional Information
This article makes use of a few OIDs. There is one of three possible indexing systems used in the OIDs in this article. LLDP port number (LLDP port index), physical port number on switch (ifIndex), and lldp remote index (index value for remote ports).
For reader reference below are the LLDP-MIB definitions for the OIDs used in this article:
lldpLocChassisId .1.0.8802.1.1.2.1.3.2 # Local ChassisID
lldpLocChassisId OBJECT-TYPE
SYNTAX LldpChassisId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the chassis component
associated with the local system."
REFERENCE "IEEE 802.1AB-2005 9.5.2.3"
::= { lldpLocalSystemData 2 }
lldpLocSysName .1.0.8802.1.1.2.1.3.3 # Local Sys Name
lldpLocSysName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the system name of the
local system. If the local agent supports IETF RFC 3418,
lldpLocSysName object should have the same value of sysName
object."
REFERENCE "IEEE 802.1AB-2005 9.5.6.2"
::= { lldpLocalSystemData 3 }
lldpLocPortId .1.0.8802.1.1.2.1.3.7.1.3 # Local port ID entries
lldpLocPortIdSubtype OBJECT-TYPE
SYNTAX LldpPortIdSubtype
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of port identifier encoding used in the associated
'lldpLocPortId' object."
REFERENCE "IEEE 802.1AB-2005 9.5.3.2"
::= { lldpLocPortEntry 2 }
lldpLocPortDesc .1.0.8802.1.1.2.1.3.7.1.4 # Local port Desc entries
lldpLocPortDesc OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the 802 LAN station's port
description associated with the local system. If the local
agent supports IETF RFC 2863, lldpLocPortDesc object should
have the same value of ifDescr object."
REFERENCE "IEEE 802.1AB-2005 9.5.5.2"
::= { lldpLocPortEntry 4 }
lldpRemChassisId .1.0.8802.1.1.2.1.4.1.1.5 # Remote Chassis ID
lldpRemChassisId OBJECT-TYPE
SYNTAX LldpChassisId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the chassis component
associated with the remote system."
REFERENCE "IEEE 802.1AB-2005 9.5.2.3"
::= { lldpRemEntry 5 }
lldpRemPortId .1.0.8802.1.1.2.1.4.1.1.7 # Remote port ID
lldpRemPortId OBJECT-TYPE
SYNTAX LldpPortId
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the port component
associated with the remote system."
REFERENCE "IEEE 802.1AB-2005 9.5.3.3"
::= { lldpRemEntry 7 }
lldpRemPortDesc .1.0.8802.1.1.2.1.4.1.1.8 # Remote port Desc
lldpRemPortDesc OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the description of
the given port associated with the remote system."
REFERENCE "IEEE 802.1AB-2005 9.5.5.2"
::= { lldpRemEntry 8 }
lldpRemSysName .1.0.8802.1.1.2.1.4.1.1.9 # Remote system name
lldpRemSysName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The string value used to identify the system name of the
remote system."
REFERENCE "IEEE 802.1AB-2005 9.5.6.2"
::= { lldpRemEntry 9 }
lldpRemManAddrIfId .1.0.8802.1.1.2.1.4.2.1.4 # Remote Man Addr
lldpRemManAddrIfId OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The integer value used to identify the interface number
regarding the management address component associated with
the remote system."
REFERENCE "IEEE 802.1AB-2005 9.5.9.6"
::= { lldpRemManAddrEntry 4 }
Attachments
Feedback
