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: How does Smarts form a Trunk Cable Connection via Bridge (323295)

Last Updated: 12/17/2018Categories: How toTotal Views: 2342Language:
English

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Resolution

To display how Smarts forms a Trunk Cable connection via Bridge.  This is a "GOOD" example of a Bridge Trunk Cable connection.

NOTE: Version used for this testing was IP Manager version 9.4.0.0

BRIDGE: Trunk Cable connection between a Switch (Port) to Switch (Port).

The creation of Trunk Cables is important, because if they are not created, Smarts IP Manager will not automatically managed each of the involved ports and monitor them for their Admin/Oper Status.  Many customers prefer this and this is why they come to us to find out why these aren't being created.

Two Devices used during this exercise:

Device 1:

Make: Ciena

Model 3920

System ObjectID: .1.3.6.1.4.1.6141.1.77

Snapper IP address: 192.168.101.13

FileName: 10.65.162.9.snap

Device 2:

Make: Ciena

Model 3960

SystemObjectID: .1.3.6.1.4.1.6141.1.81

Snapper IP address: 192.168.101.16

FileName: 10.65.168.11.snap

NOTE: The snapper ip addresses will be different if you conduct this same test in the lab, but for this example, these were the ip addresses used here.

1.) So after discovering both devices, below you can see the details of the Trunk Cable that's created.  After clicking on the Trunk Cable object itself, you'll notice in the attributes on the right side, the Description is Bridge.

The connection is formed as follows:

Device 1: 192.168.101.13 on Port Index 7 <----> Device 2: 192.168.101.16 on Port Index 6

1A.) Notice Port Index 7 (10007) Bridges a single MAC address (00-03-18-87-0B-77), which belongs to Port 6 (underlying).

1B.) Notice Port Index 6 (10006) Bridges a single MAC address (00-03-18-4E-3B-68), which belongs to Port 7 (underlying).

1C.) The MAC address of each Port index can be found looking up the following OID in each devices .mimic file:

ifPhysAddress .1.3.6.1.2.1.2.2.1.6

Device 1 Port Index 7:

Line 687:  .1.3.6.1.2.1.2.2.1.6.10007: 00 03 18 4E 3B 68

Device 2 Port Index 6:

Line 660:  .1.3.6.1.2.1.2.2.1.6.10006: 00 03 18 87 0B 77

1D.) The following picture should help in the understanding of what's required to create a Trunk Cable via Bridge

2.) So now we need to validate all information from the perspective of each port and prove that the opposing Switch does actually contain the MAC in it's Bridging table and it's related to the correct opposing Port.

2A.) Device 1 (192.168.101.13) on local Port Index 7 (10007) Bridges a single MAC address (00-03-18-87-0B-77), which belongs to peer Port Index 6 on Device 2.

2B.) Device 2 (192.168.101.16) on local Port Index 6 (10006) Bridges a single MAC address (00-03-18-4E-3B-68), which belongs to peer Port Index 7 on Device 1.

Device 1: 192.168.101.13 on Port Index 7 (00-03-18-4E-3B-68) <----> Device 2: 192.168.101.16 on Port Index 6 (00-03-18-87-0B-77)

3.) Search for the following oid, in each of the .mimic files for both Device 1 and Device 2:

Object ifPhysAddressOID                 = "1.3.6.1.2.1.2.2.1.6"

This proves what the local MAC Address is for each port on each Device:

3A.) Device 1 Local Port Index 7 MAC Address:

Line 687:  .1.3.6.1.2.1.2.2.1.6.10007: 00 03 18 4E 3B 68

3B.) Device 2 Local Port Index 6 MAC Address:

Line 660:  .1.3.6.1.2.1.2.2.1.6.10006: 00 03 18 87 0B 77

4.) Now to determine, how the above MAC address above associate back to the opposing switches Local Port.

Search for the following OID in the switch .mimic file:

Object dot1dTpFdbAddressOID          = ".1.3.6.1.2.1.17.4.3.1.1";
"A unicast MAC address for which the bridge has forwarding and/or filtering information."

4A.) Device 1 Local Port Index 7 Bridges the below MAC Address (belonging to peer Port Index 6)

Line 1578:  .1.3.6.1.2.1.17.4.3.1.1.0.3.24.135.11.119: 00 03 18 87 0B 77

4B.) Device 2 Local Port Index 6 Bridges the below MAC Address (belonging to the peer Port Index 7)

Line 1692:  .1.3.6.1.2.1.17.4.3.1.1.0.3.24.78.59.104: 00 03 18 4E 3B 68

5.) Pay close attention to the 3.24.135.11.119 and 3.24.78.59.104 above while looking for the next OID.

Search for the following OID in each switch .mimic file:

dot1dTpFdbPortOID                = ".1.3.6.1.2.1.17.4.3.1.2";
-"Either the value '0', or the port number of the port on which a frame having a source address equal to the value of the corresponding instance of dot1dTpFdbAddress has been seen. A value of '0' indicates that the port number has not been learned, but that the bridge does have some forwarding/filtering information about this address (e.g., in the dot1dStaticTable). Implementors are encouraged to assign the port value to this object whenever it is learned, even for addresses for which the corresponding value of dot1dTpFdbStatus is not learned(3)."
-This Object provides the  port number of the port on which the corresponding MAC address of dot1dTpFdbAddress is learned.

5A.) 3.24.135.11.119

Device 1

Line 1586:  .1.3.6.1.2.1.17.4.3.1.2.0.2.161.39.41.109: 1
Line 1587:  .1.3.6.1.2.1.17.4.3.1.2.0.2.161.39.41.127: 1
Line 1588:  .1.3.6.1.2.1.17.4.3.1.2.0.3.24.124.16.3: 8
Line 1589:  .1.3.6.1.2.1.17.4.3.1.2.0.3.24.135.11.119: 7
Line 1590:  .1.3.6.1.2.1.17.4.3.1.2.0.3.24.135.11.127: 7
Line 1591:  .1.3.6.1.2.1.17.4.3.1.2.0.19.195.67.114.8: 7
Line 1592:  .1.3.6.1.2.1.17.4.3.1.2.0.22.200.96.185.154: 7
Line 1593:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.49.31.240: 7
Line 1594:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.80.205.150: 7
Line 1595:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.80.254.45: 7
Line 1596:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.232.138.178: 7

Notice the 7

5B.) 3.24.78.59.104

Device 2

Line 1706:  .1.3.6.1.2.1.17.4.3.1.2.0.2.161.39.41.127: 6
Line 1707:  .1.3.6.1.2.1.17.4.3.1.2.0.3.24.78.59.96: 6
Line 1708:  .1.3.6.1.2.1.17.4.3.1.2.0.3.24.78.59.104: 6
Line 1709:  .1.3.6.1.2.1.17.4.3.1.2.0.19.195.67.114.8: 8
Line 1710:  .1.3.6.1.2.1.17.4.3.1.2.0.22.200.96.185.154: 8
Line 1711:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.49.31.240: 8
Line 1712:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.49.70.134: 8
Line 1713:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.80.205.150: 8
Line 1714:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.80.254.45: 8
Line 1715:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.232.138.178: 8
Line 1716:  .1.3.6.1.2.1.17.4.3.1.2.0.32.210.232.140.67: 8
Line 1717:  .1.3.6.1.2.1.17.4.3.1.2.0.224.76.24.225.141: 8
Line 1718:  .1.3.6.1.2.1.17.4.3.1.2.80.135.137.32.252.73: 2050
Line 1719:  .1.3.6.1.2.1.17.4.3.1.2.80.135.137.40.20.152: 8
Line 1720:  .1.3.6.1.2.1.17.4.3.1.2.132.120.172.59.100.19: 2050
Line 1721:  .1.3.6.1.2.1.17.4.3.1.2.132.120.172.59.100.20: 2050

Notice the 6

6.) Finally, search the following OID to relate the 7 and the 6 to the actual port Index.

dot1dBasePortIfIndex          = ".1.3.6.1.2.1.17.1.4.1.2";
"The value of the instance of the ifIndex object, defined in IF-MIB, for the interface corresponding to this port."

6A.) Device 1:

Line 1329:  .1.3.6.1.2.1.17.1.4.1.2.1: 10001
Line 1330:  .1.3.6.1.2.1.17.1.4.1.2.2: 10002
Line 1331:  .1.3.6.1.2.1.17.1.4.1.2.3: 10003
Line 1332:  .1.3.6.1.2.1.17.1.4.1.2.4: 10004
Line 1333:  .1.3.6.1.2.1.17.1.4.1.2.5: 10005
Line 1334:  .1.3.6.1.2.1.17.1.4.1.2.6: 10006
Line 1335:  .1.3.6.1.2.1.17.1.4.1.2.7: 10007
Line 1336:  .1.3.6.1.2.1.17.1.4.1.2.8: 10008
Line 1337:  .1.3.6.1.2.1.17.1.4.1.2.9: 10009
Line 1338:  .1.3.6.1.2.1.17.1.4.1.2.10: 10010
Line 1339:  .1.3.6.1.2.1.17.1.4.1.2.11: 10011
Line 1340:  .1.3.6.1.2.1.17.1.4.1.2.12: 10012

The first hightlighted bold 7 above on line 1335 is the Port Number:  The 2nd 10007 is the interfaceNumber as seen below:

6B.) Device 2:

Line 1406:  .1.3.6.1.2.1.17.1.4.1.2.1: 10001
Line 1407:  .1.3.6.1.2.1.17.1.4.1.2.2: 10002
Line 1408:  .1.3.6.1.2.1.17.1.4.1.2.3: 10003
Line 1409:  .1.3.6.1.2.1.17.1.4.1.2.4: 10004
Line 1410:  .1.3.6.1.2.1.17.1.4.1.2.5: 10005
Line 1411:  .1.3.6.1.2.1.17.1.4.1.2.6: 10006
Line 1412:  .1.3.6.1.2.1.17.1.4.1.2.7: 10007
Line 1413:  .1.3.6.1.2.1.17.1.4.1.2.8: 10008
Line 1414:  .1.3.6.1.2.1.17.1.4.1.2.9: 10009
Line 1415:  .1.3.6.1.2.1.17.1.4.1.2.10: 10010
Line 1416:  .1.3.6.1.2.1.17.1.4.1.2.11: 10011
Line 1417:  .1.3.6.1.2.1.17.1.4.1.2.12: 10012
Line 1418:  .1.3.6.1.2.1.17.1.4.1.2.2049: 12049
Line 1419:  .1.3.6.1.2.1.17.1.4.1.2.2050: 12050

The first highlighted bold 6 above on line 1411 is the Port Number: The 2nd 10006 is the interfaceNumber as seen below:

8.) In Summary, this is how to validate a Trunk Cable Connection from a Switch Port to a Switch Port through gathering both a sm_snmpwalk of both the devices from customer, loading in the lab via a snap server, and validating the data via the .mimic file of each switch.

Download sm_snmpwalks here. This can be reproduced in the lab using a snap server.

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