Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

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: Connections appear incorrect for Cisco Devices in domain after physical connections are changed. (522678)

Last Updated: 9/27/2023Categories: TroubleshootingTotal Views: 4359Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Symptoms

There is a physical connection between devices as below in actual network:
Switch1/Port1 <-> Switch2/Port2

When user does initial discovery of Switch1 & Switch2, Smarts make use of CDP MIB information to create a connection.
Smarts adds this pair during CDP probe processing to the DSCV_ListDataSet::Neighbor-Pair-Cisco-Cdp table and creates a proper connection between devices on respective ports in IP domain.

User made a physical change in the connections later on devices in actual network to below:
Switch1/Port2 <-> Switch2/Port2

When user runs discovery again on Switch1 in IP domain, Smarts adds new pair to DSCV_ListDataSet::Neighbor-Pair-Cisco-Cdp table during CDP probe processing.

Now there are two records in CDP(Neighbor-Pair-Cisco-Cdp) table of IP domain where two ports (Port1 & Port2) on Switch1 are connected to same port (Port2) on Switch2, which is conflicting information. Due to this, Smarts is not able to create the proper connection between the two CISCO Switches.

Cause

In this scenario, the Neighbor-Pair-Cisco-Cdp table has not been cleared and reinitialized, and has conflicting information regarding the Neighbor Pairs because a full discovery on IP domain has not been scheduled.

Also, discovering the devices with the Seed file/ below command is not calling the Pre-Processor-Driver functions to clear out the tables as a Full discovery would perform.
./sm_tpmgr -s <IP domain name> --seedfile

CDP probe during devices discovery is two stages process, which is processed by two scripts:

ic-cisco-cdp.asl - This asl file is called to generate a CDP table (DSCV_ListDataSet::Neighbor-Pair-Cisco-Cdp) which contains connected pairs reported by SNMP agent (as described above)

ic-cisco-post-processor.asl - This asl file is called in Cisco post processing which process table DSCV_ListDataSet::Neighbor-Pair-Cisco-Cdp created by ic-cisco-cdp.asl and creates connectivity between devices.

CDP internal table DSCV_ListDataSet::Neighbor-Pair-Cisco-Cdp updates (add new pairs) every time Smarts discovers a device.

Impact / Risks

Moderate.  Running the runPreProcessor command will increase the time that discovery takes as the VSA IP domain will need to rebuild the tables that are cleared.

Resolution

User should schedule and run a full discovery process to resolve the issue, as the full discovery process invokes the PreProcessor functions to clear the tables in Smarts before the full discovery.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
Platform Services Controller(PSC) 6.X でのレプリケーションの契約とステータスの特定 (2127057)

Results 1-2 of 2

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