Think you know your network? Unless you know the intimate details of its physical-link topology, you don't know it at all. This Layer 2 information is crucial for network accounting, diagnostics and planning. But keeping up with the constant flow of network changes is a struggle.
Many network-management packages use automated discovery to track topology changes and conditions. But most of these applications only dig as far down as Layer 3, grouping devices into IP subnets. Hewlett-Packard's HP OpenView Network Node Manager and similar products provide solid Layer 3 information, but that data is primitive--just basic facts on adds and removals, not details on where or how these devices operate with network services.
Layer 2 discovery drills down to such information as which devices are attached to which ports and which switches are connected to one another. It shows the path between clients, switches, routers and servers for application and network services. This level of detail helps you plan and get to the source of network failures.
HP and other network-management vendors have added Layer 2 discovery to their software with limited success. For the most part, these applications at best achieve 90 percent accuracy, leaving out 10 percent of Layer 2 connections. And that's 10 percent too much as far as network managers are concerned: They then must manually audit most of the network to find those undiscovered elements. So much for automation.
But don't blame network-management vendors. The reason it's hard to manage Layer 2 networks is because it's so easy to build them: Switches can connect transparently, so it's really just a matter of plugging in cables to create a LAN. Trouble is, this connection ease also makes LANs transparent to network-management applications.
That doesn't mean you can't do Layer 2 discovery. Key infrastructure vendors have developed proprietary discovery protocols, storing the data in enterprise extensions of SNMP. Cisco Systems has CDP (Cisco Discovery Protocol); Extreme Networks, EDP (Extreme Discovery Protocol); Enterasys Networks, CDP (Cabletron Discovery Protocol); and Nortel Networks, NDP (Nortel Discovery Protocol).
The obvious problem here is that these protocols don't work in mixed-vendor networks. One way to get around this is to have a single-vendor network, using that vendor's management application. But that's not realistic or desirable. A better approach is to map Layer 2 connections.
But mapping Layer 2 connections in heterogeneous networks is difficult for several reasons. There is no single standard, and the often-used SNMP Bridge MIB typically is poorly implemented. Many networks run older SNMP implementations or don't even have SNMP turned on. And network devices don't always behave, failing to flush cached but aged MAC (Media Access Control) address entries, for example, so defunct equipment appears to be still attached to the network.
The most common approach used in network-management tools is reading bridge tables from the SNMP Bridge MIB. It works like this: Algorithms that decipher the bridge tables map the port-to-MAC address entries. When a network uses the Spanning Tree Protocol, the switch at the bottom of the configuration will only have the ports of a single segment or device. Each port of the root switch, meanwhile, will contain the sum total of the devices below it in its bridge table. Most network-management vendors who say they support Layer 2 topology discovery ascertain that if a bridge points "up" (into a spanning tree) or "down" (to the leaf nodes), you just count the number of objects.
But this only works if the bridge tables are accurate. Bridge tables can be implemented incorrectly, and the longer the aging intervals for bridge tables, the more difficult it is to map Layer 2. A virtual interface--the aggregate of multiple, real interfaces--poses another problem here. It fools the management tool reading the bridge table into thinking it's the real interface, which results in an inaccurate Layer 2 map.
Another Layer 2 discovery method for heterogeneous networks is fractal matching, which was developed by Loran Networks, now owned by Peregrine. With this approach, a network-management tool uses traffic patterns between switches to determine the physical network topology. The traffic coming and going between two ports connecting two different switches--or devices attached to these switches--has unique patterns. This is measured by "in" and "out" octets on each port.
The trick is to find another port on a different device that has the same traffic pattern in reverse. So traffic between Switch A Port 1 and Switch B Port 1, for instance, shows that utilization of Switch 1's "out" octet is the same as that of Switch 2's "in" octet. These traffic patterns are measured over time, and this fractal-matching method works well as long as each device is running SNMP. The main catch is that it's a proprietary discovery method.
Another Layer 2 discovery approach yet to be fully implemented by network-management vendors involves understanding the configuration of a network device. This primarily yields Layer 3 data, but can provide port and virtual LAN information as well. The challenge here is for management vendors to understand all the devices in your network. That's a tall order even if your network is mostly a Cisco shop, since the same models of some Cisco switches have configuration differences of their own.
But hope is on the horizon. The IEEE is working on 802.1ab, a draft standard for discovering the physical topology between devices. 802.1ab provides the information that will let network-management systems discover Layer 2 connections between network infrastructures and devices. Switches will be able to pinpoint their neighbors, for instance, and store that information in standard SNMP MIBs.
Although 802.1ab operates at the Ethernet LLC (Link Layer Control) layer, any 802 or other Layer 2 protocol can use it. LLDP (Link Layer Discovery Protocol) is the new protocol defined in 802.1ab that lets neighboring devices notify one another of their existence. Each device on each port stores information defining itself, and sends updates to its directly connected neighbors as needed.
These neighboring devices then store the information in standard SNMP MIBs. The IEEE will use the IETF's existing Physical Topology, Interface and Entity MIBs, and it's expected that the 802.1ab will send all changes LLDP advertises to the Physical Topology MIB. This is good news: Network management vendors will have SNMP access to Layer 2 topology.
LLDP doesn't configure or control network elements or traffic--it just reports on Layer 2 configuration. Although a device can't request Layer 2 updates using LLDP, network-management applications will be able to query the current Layer 2 connections from the MIB. Another proposal in the works with 802.1ab is for network-management software to find some Layer 2 inconsistencies using information LLDP provides.
But like any draft standard, 802.1ab is a long way from becoming part of network devices and management software, and it's not necessarily a sure thing as a standard. For now, though, 802.1ab may be the best hope for automated Layer 2 discovery and more comprehensive network management.
Bruce Boardman, executive editor of Network Computing, tests and writes about network management and systems. He has 12 years' experience managing networks and distributed computing for a financial service provider. Write to him at firstname.lastname@example.org. Post a comment or question on this story at www.nwc.com/go/ask.html.