Loading

×Sorry to interrupt
This page has an error. You might just need to refresh it.
[NoErrorObjectAvailable] Uncaught ReferenceError: addCTracking is not defined
Failing descriptor: {markup://c:KM_ArticleThemeLayout}

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Smarts IP: How does Smarts IP create Cable, TrunkCable and Network Connections? (336478)

Last Updated: 4/11/2019Categories: TroubleshootingTotal Views: 6205Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

This document describes what order Smarts uses to build a connection. How Smarts builds a connection and each protocol Smarts uses to build the connections.

Resolution

Each of the protocol listed below is evaluated for the data Smarts receives through SNMP queries during discovery.  It starts with the first protocol on the list - CDP, and works through each one, building and making adjustments as it gathers more data from each protocol.  Each subsequent protocol overwrites, if it contradicts, or adds to the data of the proceeding protocol.  For example, if the Bridge protocol is probed for a device and it contradicts the CDP information probed, the bridge data is used as it is considered more authoritative.

1.            Build Cisco CDP connection.
2.            Build bridge connection
3.            Build STP connection
4.            Build LLDP connection
5.            Build WAN link connection
6.            Build ATMPeer Connection
7.            Build IPSec tunnel Connection
8.            Build UserDefined Connection.

Each connection depends on the respective protocols configured on the device which in turn gets populated on the MIBs Smarts probes.
And the subsequent connection probes can overwrite the connections that were created by the former probes.

Explanation of each

Cisco CDP connection:
*****************
a.            Relies on the CDP protocol running on the Cisco based devices.
b.            Before building this connection, we check if the bridge relationship also holds good between the ports we intend to create the connection.
c.            When customer sets the  CiscoOnlyNetwork  to TRUE, then we bypass the point b (which avoids checking the existence of bridge relationship).
d.            Following are the oids we make primarily use in identifying the CDP neighbours.
--- cdpCacheAddressOID     {".1.3.6.1.4.1.9.9.23.1.2.1.1.4"}
--- cdpCacheDeviceIdOID    {".1.3.6.1.4.1.9.9.23.1.2.1.1.6"}
--- cdpCacheDevicePortOID  {".1.3.6.1.4.1.9.9.23.1.2.1.1.7"}

For IPV6
--- portChannelIfIndexOID {".1.3.6.1.4.1.9.5.1.18.1.1.10"}
--- cdpCacheAddressTypeOID {".1.3.6.1.4.1.9.9.23.1.2.1.1.3"}
--- cdpCacheAddressOID {".1.3.6.1.4.1.9.9.23.1.2.1.1.4"}
--- cdpCacheDeviceIdOID {".1.3.6.1.4.1.9.9.23.1.2.1.1.6"}
--- cdpCacheDevicePortOID {".1.3.6.1.4.1.9.9.23.1.2.1.1.7"}
--- cdpCachePlatformOID {".1.3.6.1.4.1.9.9.23.1.2.1.1.8"}
--- cdpCacheDuplexOID {".1.3.6.1.4.1.9.9.23.1.2.1.1.12"}
--- cdpGlobalDeviceIdOID {".1.3.6.1.4.1.9.9.23.1.3.4"}

Bridge Connection:
***************
a.            Bridge connection is made through the bridge protocol which is by default enabled at the device end.
b.            When a data packet is sent between the layer2 devices, then a MAC will be bridged by the respective ports/interfaces hosted by the connected devices. This is basic bridging concept.
c.            There is no flag to control this probe being called or not. By default this probe will be executed for all the devices.
d.            Following are list of OIDs we are looking for:

---  dot1dBaseBridgeAddressOID   = ".1.3.6.1.2.1.17.1.1";
--- dot1dBasePortIfIndexOID        = ".1.3.6.1.2.1.17.1.4.1.2";
--- dot1dTpFdbAddressOID          = ".1.3.6.1.2.1.17.4.3.1.1";
--- dot1dTpFdbPortOID                = ".1.3.6.1.2.1.17.4.3.1.2";

STP connection:
************
a.            STP connection is based on the spanning tree protocol that is enabled at the connected network devices.
b.            This is basically to avoid loop of data packets being sent among the connected devise.
c.            SMARTS identify such devices that are taking part in the STP and created STP nodes in the topology.
d.            Following are the list of OIDs being used to create the STP connection:
--- dot1dStpDesignatedRootOID        = ".1.3.6.1.2.1.17.2.5";
--- dot1dStpRootPortOID              = ".1.3.6.1.2.1.17.2.7";
--- dot1dStpPortStateOID             = ".1.3.6.1.2.1.17.2.15.1.3";
--- dot1dStpPortPriorityOID          = ".1.3.6.1.2.1.17.2.15.1.2";
--- dot1dStpPortDesignatedBridgeOID  = ".1.3.6.1.2.1.17.2.15.1.8";
--- dot1dStpPortDesignatedPortOID    = ".1.3.6.1.2.1.17.2.15.1.9";
e.            There is a flag to control the creation of STP nodes. i.e  STPTrunkEnabled . By setting this flag, the Connections will not be created using this protocol.

LLDP (Link Layer Discovery protocol) connection:
*************************************
a.            This is a vendor-neutral link layer protocol similar to CDP but this can be enabled in all the devices that is hosting a  IEEE 802 local area network.
b.            This protocol identifies the directly connected neighbor and populates them in the following OIDs.
--- localChassisOID      {".1.0.8802.1.1.2.1.3.2"}
--- localSystemNameOID   {".1.0.8802.1.1.2.1.3.3"}
--- localSystemDescOID   {".1.0.8802.1.1.2.1.3.4"}
--- localPortOID         {".1.0.8802.1.1.2.1.3.7.1.3" }
--- localPortDescOID     {".1.0.8802.1.1.2.1.3.7.1.4" }
--- remoteChassisOID     {".1.0.8802.1.1.2.1.4.1.1.5" }
--- remotePortOID        {".1.0.8802.1.1.2.1.4.1.1.7" }
--- remotePortDescOID    {".1.0.8802.1.1.2.1.4.1.1.8" }
--- remoteSystemNameOID  {".1.0.8802.1.1.2.1.4.1.1.9" }
--- remoteSystemDescOID  {".1.0.8802.1.1.2.1.4.1.1.10"}
--- remoteManAddrIfOID   {".1.0.8802.1.1.2.1.4.2.1.4" }
c.            There is no any flag as such to control whether or not to call this driver. This driver is by default executed for all the devices if the neighbor probe is certified to probe LLDP mibs.

WAN link connection:
*****************
a.            There is no specific OID this looks for to create this connection.
b.            Create network connection based on IP network.
c.            If IP network is only connected to TWO IPs, and the two IPs are on different routers, and two IPs are configured on Serial/FrameRelay interface, we make the connection.
d.            This is basically between the Interfaces that is hosted by a router.
e.            There is no specific flag that is controlled to invoke this driver.

ATMPeer Connection:
*****************
a.            This is also similar to the WAN link connection; but instead this builds connection between the ATM configured interfaces.
b.            There is no specific flag that is controlled to invoke this driver.
c.            There is no specific OID this looks for to create this connection.

IPSec tunnel Connection:
********************
a.            This is to build connection between the IPsec interfaces.
b.            Following are the list of OIDs which are used to identify the Ipsec tunnel interfaces:
--- cipSecTunLocalAddrOID  {".1.3.6.1.4.1.9.9.171.1.3.2.1.4"}
--- cipSecTunRemoteAddrOID {".1.3.6.1.4.1.9.9.171.1.3.2.1.5"}
--- cikeTunLocalAddrOID {".1.3.6.1.4.1.9.9.171.1.2.3.1.4"}
--- cikeTunRemoteAddrOID {".1.3.6.1.4.1.9.9.171.1.2.3.1.8"}
--- cipSecTunIkeTunnelIndexOID {".1.3.6.1.4.1.9.9.171.1.3.2.1.2"}
c.            This is controlled by a flag;   EnableIPSecDiscovery . Once the IPsec tunnels are discovered then SMARTS cerates the tunnel connection.

UserDefined Connection:
********************
a.            This is a user specific connections.
b.            User-defined-connections.conf is used to specify manually between which ports/interfaces the connection has to be formed.
c.            There is no flag to control this driver.
d.            There is no any specific OID essential for this connection to be created. SMARTS just relies the information present in the user-define-connection.conf to build the connection.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware Smart Assurance - SMARTS

Take Our Survey

Support Assistant