Transparent Bridge Discovery

Discovering Layer 2 network links using the bridge forwarding table requires a special algorithm that is based on Topology Discovery for Large Ethernet Networks. The gathered information is used to classify links as macLinks and bridgeLinks.

Definitions

A macLink represents a link between a workstation or server that is identified by a MAC address. A bridgeLink represents a connection between backbone ports.

A shared segment is a connection established among workstations or servers (made up of several MAC addresses) and backbone ports (for example, devices connected via a hub). A bridgeLink is a shared segment with only two bridge backbone ports. A macLink is a shared segment with only one bridge port and one MAC address.

Broadcast and bridge domains are collections of shared segments, based on common sets of MAC addresses.

Bridge domains

Discovery bridge broadcast domains are made in two steps. The first step is data collection. To collect the necessary information, the BridgeDiscovery collector collects the BFT and other spanning tree information. The BFT is maintained in memory to be processed by BridgeDomainDiscovery. BridgeDomainDiscovery runs the specified algorithm on collected BFTs, and will produce a bridge domain (or several bridge domains) based on the broadcast set of MAC addresses identified.

BridgeDomainDiscovery does not support multi-VLAN; the bridge network model identifies a bridge for every VLAN identified. Each VLAN has its own BFT and spanning tree. Although discovery is run only against the main VLAN, the algorithm has to be run against all bridges and VLANs to discover a bridge topology.

Bridge domains provide no information about Layer 3 links; they produce only a Layer 2 map of the broadcast domains. You can determine which Layer 3 interfaces map to Layer 2 nodes if your device supports the IpNetToMedia table. You can associate a MAC address with its corresponding IP address and the associated node using this table.

Bridge Topology Updater

The Bridge Topology Updater combines the information stored in bridge domains with the ipnettomedia data and the provided Bridge OnmsTopology.

Whenever possible, the Bridge Topology Updater tries to associate a MAC address to an IP address, and then to a monitored node. It may be that the specified MAC address and IP address are not associated with a single node (for example, because there are duplicate nodes, or because the nodes support a protocol like LACP). Because the Updater does not support LACP and other similar aggregation protocols, Horizon does not resolve the node or record the association discovered as a MAC:IP relationship for a specific vertex.

Transparent bridging is not loop-free. If you have loops, you must enable the spanning tree protocol, which detects loops and will put some ports in a blocking state to avoid them.

You can find generic information about the bridge link discovery process in the Bridge Information box on any device’s Node Detail page. Information gathered from the supported OIDs is stored in the following database tables:

Network diagram depicting database tables that are used in transparent bridge discovery
Figure 1. Database tables related to transparent bridge discovery

Required SNMP MIB

To define links, Horizon must perform some calculations, and the SNMP agent must support the following MIB to allow this:

Supported MIB from the Cisco-VTP MIB
Name Description OID

vtpVersion

The local version of VTP. A device reports its version capability, but not the particular version that it uses. If the device does not support VTP, the version is none(3).

.1.3.6.1.4.1.9.9.46.1.1.1.0

Supported OIDs

The bridge discovery process supports the following OIDs:

Supported OIDs from the IP-MIB module
Name Description OID

ipNetToMediaIfIndex

Interface on which the entry’s equivalent is effective. The Layer 2 interface identified by a particular value of this index is the same as identified by the value of ifIndex.

.1.3.6.1.2.1.4.22.1.1

ipNetToMediaPhysAddress

Media-dependent physical address.

.1.3.6.1.2.1.4.22.1.2

ipNetToMediaNetAddress

IP address that corresponds to ipNetToMediaPhysAddress.

.1.3.6.1.2.1.4.22.1.3

ipNetToMediaType

Mapping type. Setting this object to invalid(2) invalidates its corresponding entry in the ipNetToMediaTable. This effectively disassociates the entry’s identified interface from its mapping. Accordingly, management stations must be prepared to receive tabular information from agents that correspond to entries that are not currently in use. Proper interpretation of such entries requires the relevant ipNetToMediaType object to be examined.

.1.3.6.1.2.1.4.22.1.4
Supported OIDs from the BRIDGE-MIB module
Name Description OID

dot1dBaseBridgeAddress

MAC address used by the bridge as a unique identifier. We recommend that this be the numerically smallest MAC address of all ports that belong to this bridge; however, it is only required to be unique. When concatenated with dot1dStpPriority, they form a unique BridgeIdentifier which is used in the spanning tree protocol.

.1.3.6.1.2.1.17.1.1.0

dot1dBaseNumPorts

Number of ports controlled by this bridging entity.

.1.3.6.1.2.1.17.1.2.0

dot1dBaseType

Type of bridging that this bridge can perform. If a bridge is actually performing a certain type of bridging, entries in the appropriate port table will reflect this.

.1.3.6.1.2.1.17.1.3.0

dot1dBasePort

Port number as defined by the corresponding bridge management information.

.1.3.6.1.2.1.17.1.4.1.1

dot1dPortIfIndex

Value of the ifIndex object, as defined in MIB-II, for the interface that corresponds to this port.

.1.3.6.1.2.1.17.1.4.1.2

dot1dStpProtocolSpecification

Version of the spanning tree protocol that is being run.
decLb100(2): Indicates the DEC LANbridge 100 protocol.
ieee9021d(3): Indicates IEE 802.1d implementations. If future versions of the IEE protocol are released that are not compatible with the current version, a new value will be defined.

.1.3.6.1.2.1.17.2.1.0

dot1dStpPriority

Value of the writeable portion of the bridge ID (for example, for first two octets of the eight-octet bridge ID). dot1dBaseBridgeAddressOther provides the final six octets of the bridge ID.

.1.3.6.1.2.1.17.2.2

dot1dStpDesignatedRoot

Bridge identifier for the root of the spanning tree, as determined by the node’s spanning tree protocol. This value is used as the root identifier parameter in all configuration bridge protocol data units (BPDUs) originated by this node.

.1.3.6.1.2.1.17.2.5

dot1dStpRootCost

Cost of the path to the root of the spanning tree, from the perspective of the current bridge.

.1.3.6.1.2.1.17.2.6

dot1dStpRootPort

Port number of the port that offers the lowest-cost path from the current bridge to the root.

.1.3.6.1.2.1.17.2.7

dot1dStpPort

Port number of the port for which this entry contains spanning tree protocol management information.

.1.3.6.1.2.1.17.2.15.1.1

dot1dStpPortPriority

Value of the property field contained in the first octet (in network byte order) of the two-octet port ID. dot1dStpPort provides the second octet of the port ID.

.1.3.6.1.2.1.17.2.15.1.2

dot1dStpPortState

Current state of the port, as defined by the spanning tree protocol. This state controls what action a port takes upon reception of a frame. If the bridge detects a malfunctioning port, it places that port into the broken(6) state. For ports that are disabled (see dot1dStpPortEnable), this object has a value of disabled(1).

.1.3.6.1.2.1.17.2.15.1.3

dot1dStpPortEnable

Port’s enabled or disabled status.

.1.3.6.1.2.1.17.2.15.1.4

dot1dStpPortPathCost

Current path’s contribution to the cost of paths toward the root. 802.1D-1990 recommends that this parameter’s default value be in inverse proportion to the speed of the attached LAN.

.1.3.6.1.2.1.17.2.15.1.5

dot1dStpPortDesignatedRoot

Unique bridge identifier of the bridge that is recorded as the root in the configuration BPDUs that the designated bridge transmitted for the segment to which the port is attached.

.1.3.6.1.2.1.17.2.15.1.6

dot1dStpPortDesignatedCost

Path cost of the segment connected to the designated port. This value is compared to the root path cost field in received BPDUs.

.1.3.6.1.2.1.17.2.15.1.7

dot1dStpPortDesignatedBridge

Identifier of the bridge that this port considers to be the designated bridge for the port’s segment.

.1.3.6.1.2.1.17.2.15.1.8

dot1dStpPortDesignatedPort

Identifier of the port on the designated bridge for the current port’s segment.

.1.3.6.1.2.1.17.2.15.1.9

dot1dTpFdbAddress

Unicast MAC address for which the bridge has forwarding or filtering information.

.1.3.6.1.2.1.17.4.3.1.1

dot1dTpFdbPort

Either 0 or the port number of the port on which a frame whose source address is equal to the value of dot1dTpFdbAddress has been seen. A value of 0 indicates that the port number has not been discovered, but that the bridge does have some forwarding or filtering information about this address (for example, stored in dot1dStaticTable).
You are encouraged to assign the port value to this object when it is discovered, even for addresses for which the value of dot1dTpFdbStatus is not learned(3).

.1.3.6.1.2.1.17.4.3.1.2

dot1dTpFdbStatus

The current entry’s status.
other(1): Indicates "none of the following". This may include the case in which another MIB object (which is not dot1dTpFdbPort or an entry in the dot1dStaticTable) is being used to determine if and how frames addressed to the value of dot1dTpFdbAddress are being forwarded.
invalid(2): Indicates that the entry is no longer valid (for example, the entry was discovered but has since aged out) but has not yet been flushed from the table.
learned(3): Indicates that the value of dot1dTpFdbPort was discovered and is being used.
self(4): Indicates that the value of dot1dTpFdbAddress represents one of the bridge’s addresses. dot1dTpFdbPort indicates which of the bridge’s ports has this address.
mgmt(5): Indicates that the value of dot1dTpFdbAddress is also the value of an existing instance of dot1dStaticAddress.

.1.3.6.1.2.1.17.4.3.1.3
Supported OIDs from the Q-BRIDGE-MIB module
Name Description OID

dot1qTpFdbPort

Either 0 or the port number of the port on which a frame whose source address is equal to the value of dot1qTpFdbAddress has been seen. A value of 0 indicates that the port number has not been discovered, but that the device does have some forwarding or filtering information about this address (for example, in the dot1qStaticUnicastTable).
You are encouraged to assign the port value to this object whenever it is discovered, even for addresses for which dot1qTpFdbStatus is not learned(3).

.1.3.6.1.2.1.17.7.1.2.2.1.2

dot1qTpFdbStatus

The current entry’s status.
other(1): Indicates "none of the following". This may include the case in which another MIB object (which is not dot1qTpFdbPort or an entry in the dot1dStaticUnicastTable) is being used to determine if and how frames addressed to the value of dot1dTpFdbAddress are being forwarded.
invalid(2): Indicates that the entry is no longer valid (for example, the entry was discovered but has since aged out) but has not yet been flushed from the table.
learned(3): Indicates that the value of dot1dTpFdbPort was discovered and is being used.
self(4): Indicates that the value of dot1dTpFdbAddress represents one of the device’s addresses. dot1dTpFdbPort indicates which of the device’s ports has this address.
mgmt(5): Indicates that the value of dot1dTpFdbAddress is also the value of an existing instance of dot1dStaticAddress.

.1.3.6.1.2.1.17.7.1.2.2.1.3