Conducting a Connectivity Audit

Understanding how devices are logically and physically associated with each other is the next step of a network audit. Without tracking this information, you can never be sure what the true source of traffic to a device can be. It makes a huge difference whether traffic coming into a switch is from a server, user, or another switch. When deciding which ports to monitor in the network, you may mistakenly choose not to monitor a particular port because you thought it was a user port, when in fact it was the mainframe connection.

Unfortunately, after the audit is complete, you must maintain the currency of the documentation. The nature of business is that people move (and so do their connections), devices move, and networks undergo change. As a result, the documentation will be good as long as it is accurate. As soon as its accuracy declines, people will learn not to trust the information and eventually find other methods to keep track of network connectivity. Most of the time, the alternative method is guesswork, which leads to unnecessary outages due to mistakes.

Connectivity maps tend to be the most-used pieces of documentation with network operations. Therefore, it is important to integrate appropriate maintenance of the information within the framework of work. Don't let the information get out-of-date.

Documenting network connectivity consists of the following:

• Standardization

• Layer 2 Automation

• Layer 3 Automation

Standardization

Standardization involves setting up standard methods for naming, connecting devices, and locating equipment. Develop a naming scheme that will allow people (and automated tools) to quickly identify the type and use of a device. Use DNS names, hostnames, and interface descriptions to implement the naming. Interface description usage is especially helpful because the description can be obtained both from the device configuration file as well as SNMP.

Another form of standardization involves consistently using physical ports on devices to identify the type of device connected. For instance, the first port of the first card on a Catalyst 5000 could be used exclusively for connecting building routers.

Figure 1-3 provides an example of port standardization. In this case, port 1/1 is used for connection back to the backbone router, whereas port 1/2 is always used to connect to a redundant switch.

Figure 1-3. Example of Port Standardization

You should also indicate the purpose of the port in the configuration of the port name or interface description. For example, the switch in Figure 1-3 might have port names such as bb-rtr-2 for port 1/1 and redun-flr1-sw-2 for port 1/2.

Finally, you can standardize on IP address assignment. For instance, for each subnet, the following host portions would be reserved:

• .1 .9 are reserved for routers, switches, and RMON probes

• .10 .20 are server addresses

So, if you see a problem with an address such as 172.26.10.6, you would know that it is a router, switch, or RMON probe, as opposed to a user workstation or server.

Documentation Using Data Exchange

Network administrators typically begin documenting physical network and connection information using spreadsheets. With spreadsheets, it's quite easy to quickly create something for tracking IP address assignments, wiring schemes, and just about anything else. Spreadsheets are quick and easy to set up, but do not work well when trying to build an interconnected and automated knowledge database.

If you determine the need to move beyond spreadsheets, you should consider software built upon a relational database that will allow the tracking of assets and how they're connected. Chapter 3, "Developing the Network Knowledge Base," describes the selection and building of a knowledge database.

Regardless of your approach, you should strive to implement a software solution that can integrate with other database systems such as your network monitoring, element management, and HR database systems (for contact information). Data exchange among various systems will allow the presentation of a more unified system to its users.

Layer 2 Connectivity

The next stage of a connectivity audit involves learning and documenting the physical relationships between devices. In this context, the physical relationships include the following:

• The physical locations of the devices

• How the devices are connected together

• The name of one device's port that connects to the name of its neighbor's port (for example, switch 1 port 2/1 connects to switch 2 port 1/1)

• Redundant paths (for example, HSRP router peers and redundant bridged paths, port channels)

Network management software from Cisco and other vendors provides Layer 2 discovery in which given a particular switch, Layer 2 and physical relationships between switches and routers can be discovered. The software can be used to seed your documentation with the current connectivity of devices, which generally requires the use of proprietary protocols. This is because there is no standard method for network devices to learn and report their Layer 2 neighbor relationships.

With Cisco devices, the Cisco Discovery Protocol (CDP) is used. CDP runs on each Cisco device and allows it to track those Cisco devices connected off of each of its ports. CDP works well in an all-Cisco network for documentation and troubleshooting, but becomes less useful in a multi-vendor network because non-Cisco devices do not participate in CDP, and thus will not be known by their neighbor.

Figure 1-4 compares the CDP discovery of Cisco devices with a Cisco and a non-Cisco device in-between. If a Catalyst 5000 connects two Cisco routers, a CDP discovered map would display the proper relationship. However, if two Cisco routers are connected by a hub or switch from another vendor who does not participate in CDP, the map will simply display the routers as directly connected without a switch in-between.

Figure 1-4. CDP Discovery with a Cisco Switch and a Non-Cisco Switch

A CDP discovery application generally requires the specification of a starting, or seed device. The seeding involves manually entering a device name or IP address, community strings, and possibly Telnet passwords for each device of interest. This provides the auto-discovery routine with enough information to be able to interrogate the device for more information. The downside of this approach is that if devices are swapped out, moved around, or reconfigured, the changes must manually be tracked.

Given the seed device, the application queries the device's CDP neighbor table. Once discovered, the application can continue to track the changes that occur in the network. The discovered network can then be displayed or printed in map form.

The map displays the physical connectivity relationship between network devices. For each device, there is a line that connects to each of its physically adjacent network device peers.

Figure 1-5 provides an example of a map that was discovered using CDP. Notice that the map is able to display the Layer 2 and Layer 3 relationships of Cisco devices.

Figure 1-5. Example of a Hypothetical Map Discovered Using CDP

By using CDP, the application can determine how each device is physically connected, down to the port/interface number. Unfortunately, auto-discovering the physical relationships among multi-vendor networks is considerably more difficult because of the complete lack of standard neighbor discovery protocols.

Cisco has submitted the CDP standard to the IETF.

Layer 3 Connectivity

Unlike physical connectivity, Layer 3 connectivity is easier to auto-discover and map. This is mainly due to public domain methods and MIBs to collect the necessary information.

Logical connectivity maps demonstrate the distribution and relationship of network layer addresses. There are multiple methods for documenting logical connectivity (as mentioned for physical connectivity), including auto-discovering network management software, spreadsheets, and databases.

The data/reports should then be made available to those who need it. You could generate reports or capture screen shots and place them on an internal web server. Or you could simply print them out and distribute. (Don't forget to date them so people know whether they've got the latest version.)

In addition, DNS and DHCP servers can be used to capture and enforce the distribution of addressing. Network management products that auto-discover logical networks can also be used as reference documentation.

TIP

Never allow network devices to dynamically learn their network addresses. You should always assign a static address so that the device is definitively known by that address.

Automatic discovery of logical connectivity is relatively commonplace in today's network management tools. By parsing through each router's routing table, an auto-discovery routine can determine the neighbor router for each learned route. The routine then can query the routing table from the neighbor and discover the neighbor's neighbors.

TIP

You can take certain preventive steps to help auto-discovery routines more accurately discover your network and in general provide you with a cleaner network to manage:

• Ensure that the network management software is installed with the latest patches. This will help prevent bugs that may exist with the base release of the software.

• Ensure that the IP addresses for each network device are consistently and appropriately named across your DNS servers. Problems can arise when two DNS servers refer to the same IP address with different names. Also, problems can arise when an IP address has multiple names associated with it, the reverse lookup name doesn't match the forward lookup name, or finally two IP addresses are associated with the same name. Ensure that there are no duplicate IP addresses in the network. This situation, aside from causing more general connectivity issues, causes difficulty for network management software. Software vendors must take special cases into consideration when writing their software (for example, fault-tolerant features such as HSRP).

• Use consistent SNMP community strings across all devices and network management software. When the strings vary from device to device, some network management software might not be capable of handling the differences. Some network management software might have to wait for the use of the first incorrect community string to time out before trying the second correct community string. This causes unnecessary delays. Inconsistent community strings occur frequently when different groups in an organization manage different types of devices.

There are third-party tools available that allow you to draw the network connectivity as it makes sense to your organization. One method for mapping the logical network is to draw maps that display the physical network and identify the IP addresses and networks between network devices. You may also choose to incorporate connecting port and server information as well. You may also choose to store MAC addresses in the system.

Typically, hybrid maps will evolve in which logical and physical information is displayed together. This is the kind of information that people will print out and store in their notebooks or pin up on the wall. Figure 1-6 provides an example of a hybrid map.

Figure 1-6. Example of a Hybrid Connectivity Map

In this map, notice how physical connectivity, physical device traits, logical addressing, and VLAN information are displayed on the same map. Notice the following:

• The IP addressing is indicated for each of the network interface.

• A picture of a building provides a quick visual cue that we are talking about the building network infrastructure versus a floor or campus.

• The pictures of the devices themselves provide visual cues as to the type of device.

• VLANs are indicated by color, thereby weaving in the Layer 2 element of the topology.