Transparent Bridge Discovery

Discovering Layer 2 network links using the Bridge Forwarding table requires a special algorithm. To discover Links an algorithm based on a scientific paper with the title Topology Discovery for Large Ethernet Networks is implemented. The gathered information is used to classify Links in macLink and bridgeLink. A macLink represents a Link between a workstation or server identified by a mac address. A bridgeLink is a connection between backbone ports. A Shared Segment is a connection among workstations or servers (several mac addresses) and backbone ports (for example devices connected via an hub). A bridgeLink is a a shared segment with only two bridge backbone ports. A macLink is a shared segment with only a bridge port and only one mac address. A Broadcast Domain is a collection of Shared Segment based on common set of mac addresses.

Discovery Bridge Broadcast Domains is made in two step, the first step regards data collection. The Bridge Forwarding Table together with other Spanning Tree information is collected by the BridgeDiscovery Collector. The BTF is not persisted into database and is maintained in memory to be processed by the BridgeDomainDiscovery. BridgeDomainDiscovery runs the specified algorithm over collected BFT and will produce a Bridge Domain or several Bridge domains depending on the broadcasts set of mac addresses found. Bridge Domains are collection of Shared Segments as described above.

BridgeDomainDiscovery does not support multi vlan, the Bridge Network model identify a Bridge for every VLAN. Each VLAN has it’s own Bridge Forwarding Table and it’s own Spanning Tree. So in line to discovery a Bridge Topology the algorithm has to be run against every bridge and every vlan. Actually the discovery is run only against the main VLAN.

Bridge Domains provide no information about layer 3 but only a layer 2 two map of the Broadcast Domains. While Bridge/Switch are identified by the fact that are OpenNMS Nodes to map mac to Nodes where possible the IpNetToMedia table is needed. In this manned we are able to associate to mac address the corresponding ip address and then the associated node. The Bridge Topology Updater put together the information stored into bridge domains with the ipnettomedia data and provide Bridge OnmsTopology.

Bridge Topology Updater whenever possible tries to associate a mac address to an ip address and then to a node. It can happen that the mac address and the ip address specified are not associate to a single node (for example because there are duplicated node or also because the nodes supports protocol like LACP), in this case we do not resolve the node but leave the association found mac:ip into a specific Vertex.

Bridge Topology Updater do not support LACP protocols and other similar aggregation protocols.

Transparent bridging is not loop free so if you have loops you have to enable the spanning tree protocol that will detect loops and again will put some ports in a blocking state to avoid loops. To get links it is necessary to perform some calculations that let us define the Links. The following MIBS must be supported by the SNMP agent to allow Transparent Bridge Discovery.

Table 1. Supported MIBS from the Cisco-VTP MIB
Name	OID	Description
vtpVersion	`.1.3.6.1.4.1.9.9.46.1.1.1.0`	The version of VTP in use on the local system. A device will report its version capability and not any particular version in use on the device. If the device does not support VTP, the version is none(3).

Table 2. Supported OIDs from the IP-MIB
Name	OID	Description
ipNetToMediaIfIndex	`.1.3.6.1.2.1.4.22.1.1`	The interface on which this entry’s equivalence is effective. The layer-2 interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex.
ipNetToMediaPhysAddress	`.1.3.6.1.2.1.4.22.1.2`	The media-dependent physical address.
ipNetToMediaNetAddress	`.1.3.6.1.2.1.4.22.1.3`	The IpAddress corresponding to the media-dependent physical address.
ipNetToMediaType	`.1.3.6.1.2.1.4.22.1.4`	The type of mapping. Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively dissasociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object.

Table 3. Supported OIDS from the BRIDGE-MIB
Name	OID	Description
dot1dBaseBridgeAddress	`.1.3.6.1.2.1.17.1.1.0`	The MAC address used by this bridge when it must be referred to in a unique fashion. It is recommended 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 a unique BridgeIdentifier is formed which is used in the Spanning Tree Protocol.
dot1dBaseNumPorts	`.1.3.6.1.2.1.17.1.2.0`	The number of ports controlled by this bridging entity.
dot1dBaseType	`.1.3.6.1.2.1.17.1.3.0`	Indicates what type of bridging this bridge can perform. If a bridge is actually performing a certain type of bridging this will be indicated by entries in the port table for the given type.
dot1dBasePort	`.1.3.6.1.2.1.17.1.4.1.1`	The port number of the port for which this entry contains bridge management information.
dot1dPortIfIndex	`.1.3.6.1.2.1.17.1.4.1.2`	The value of the instance of the ifIndex object, defined in MIB-II, for the interface corresponding to this port.
dot1dStpProtocolSpecification	`.1.3.6.1.2.1.17.2.1.0`	An indication of what version of the Spanning Tree Protocol is being run. The value decLb100(2) indicates the DEC LANbridge 100 Spanning Tree protocol. IEEE 802.1d implementations will return ieee8021d(3). If future versions of the IEEE Spanning Tree Protocol are released that are incompatible with the current version a new value will be defined.
dot1dStpPriority	`.1.3.6.1.2.1.17.2.2`	The value of the writeable portion of the Bridge ID, i.e., the first two octets of the (8 octet long) Bridge ID. The other (last) 6 octets of the Bridge ID are given by the value of dot1dBaseBridgeAddress.
dot1dStpDesignatedRoot	`.1.3.6.1.2.1.17.2.5`	The bridge identifier of the root of the spanning tree as determined by the Spanning Tree Protocol as executed by this node. This value is used as the Root Identifier parameter in all configuration Bridge PDUs originated by this node.
dot1dStpRootCost	`.1.3.6.1.2.1.17.2.6`	The cost of the path to the root as seen from this bridge.
dot1dStpRootPort	`.1.3.6.1.2.1.17.2.7`	The port number of the port which offers the lowest cost path from this bridge to the root bridge.
dot1dStpPort	`.1.3.6.1.2.1.17.2.15.1.1`	The port number of the port for which this entry contains Spanning Tree Protocol management information.
dot1dStpPortPriority	`.1.3.6.1.2.1.17.2.15.1.2`	The value of the priority field which is contained in the first (in network byte order) octet of the (2 octet long) Port ID. The other octet of the Port ID is given by the value of dot1dStpPort.
dot1dStpPortState	`.1.3.6.1.2.1.17.2.15.1.3`	The port’s current state as defined by application of the Spanning Tree Protocol. This state controls what action a port takes on reception of a frame. If the bridge has detected a port that is malfunctioning it will place that port into the broken(6) state. For ports which are disabled (see dot1dStpPortEnable), this object will have a value of disabled(1).
dot1dStpPortEnable	`.1.3.6.1.2.1.17.2.15.1.4`	The enabled/disabled status of the port.
dot1dStpPortPathCost	`.1.3.6.1.2.1.17.2.15.1.5`	The contribution of this port to the path cost of paths towards the spanning tree root which include this port. 802.1D-1990 recommends that the default value of this parameter be in inverse proportion to the speed of the attached LAN.
dot1dStpPortDesignatedRoot	`.1.3.6.1.2.1.17.2.15.1.6`	The unique Bridge Identifier of the Bridge recorded as the Root in the Configuration BPDUs transmitted by the Designated Bridge for the segment to which the port is attached.
dot1dStpPortDesignatedCost	`.1.3.6.1.2.1.17.2.15.1.7`	The path cost of the Designated Port of the segment connected to this port. This value is compared to the Root Path Cost field in received bridge PDUs.
dot1dStpPortDesignatedBridge	`.1.3.6.1.2.1.17.2.15.1.8`	The Bridge Identifier of the bridge which this port considers to be the Designated Bridge for this port’s segment.
dot1dStpPortDesignatedPort	`.1.3.6.1.2.1.17.2.15.1.9`	The Port Identifier of the port on the Designated Bridge for this port’s segment.
dot1dTpFdbAddress	`.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.
dot1dTpFdbPort	`.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).
dot1dTpFdbStatus	`.1.3.6.1.2.1.17.4.3.1.3`	The status of this entry. The meanings of the values are: *other(1): none of the following. This would include the case where some other MIB object (not the corresponding instance of dot1dTpFdbPort, nor an entry in the dot1dStaticTable) is being used to determine if and how frames addressed to the value of the corresponding instance of dot1dTpFdbAddress* are being forwarded. *invalid(2): this entry is not longer valid (e.g., it was learned but has since aged-out), but has not yet been flushed from the table. learned(3): the value of the corresponding instance of dot1dTpFdbPort* was learned, and is being used. *self(4): the value of the corresponding instance of dot1dTpFdbAddress* represents one of the bridge’s addresses. The corresponding instance of dot1dTpFdbPort indicates which of the bridge’s ports has this address. *mgmt(5)*: the value of the corresponding instance of dot1dTpFdbAddress is also the value of an existing instance of dot1dStaticAddress.

Table 4. Supported OIDS from the Q-BRIDGE-MIB
Name	OID	Description
dot1qTpFdbPort	`.1.3.6.1.2.1.17.7.1.2.2.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 dot1qTpFdbAddress has been seen. A value of 0 indicates that the port number has not been learned but that the device does have some forwarding/filtering information about this address (e.g., in the dot1qStaticUnicastTable). Implementors are encouraged to assign the port value to this object whenever it is learned, even for addresses for which the corresponding value of dot1qTpFdbStatus is not learned(3).
dot1qTpFdbStatus	`.1.3.6.1.2.1.17.7.1.2.2.1.3`	The status of this entry. The meanings of the values are: *other(1): none of the following. This may include the case where some other MIB object (not the corresponding instance of dot1qTpFdbPort, nor an entry in the dot1qStaticUnicastTable) is being used to determine if and how frames addressed to the value of the corresponding instance of dot1qTpFdbAddress* are being forwarded. *invalid(2): this entry is no longer valid (e.g., it was learned but has since aged out), but has not yet been flushed from the table. learned(3): the value of the corresponding instance of dot1qTpFdbPort* was learned and is being used. *self(4): the value of the corresponding instance of dot1qTpFdbAddress* represents one of the device’s addresses. The corresponding instance of dot1qTpFdbPort indicates which of the device’s ports has this address. *mgmt(5): the value of the corresponding instance of dot1qTpFdbAddress* is also the value of an existing instance of dot1qStaticAddress.

Generic information about the bridge link discovery process can be found in the Bridge Information box on the Node Detail Page of the device. Information gathered from this OID will be stored in the following database table:

Figure 1. Database tables related to transparent bridge discovery