Grouping Mechanisms
We use several types of grouping mechanisms at NetCraftsmen to reduce the effort that is required to manage customer networks. Grouping by address reduces configuration complexity, while device and interface grouping makes it easier for a network management system to identify problems with critical network elements.
Address Summarization
The first, and probably the most important, is grouping similar devices by IP address. Configuration complexity can be greatly reduced by allocating blocks of addresses out of a few summarizable address ranges. Anywhere an access list is used is a good candidate for using summarizable addresses. Allocate a large block of addresses for use by the UC system and allocate smaller blocks from within that range. Then, anytime you need an access list entry for the UC system, the larger block encompasses all UC system components. Preventing unauthorized access to the UC system is one such use.
Allocate address space from a large, summarizable chunk. Assign smaller chunks from within this space to each geographic region. For example, 10.1.0.0/16 could be the address range in which all VoIP phones are to be assigned. Allocate smaller blocks to geographic regions and finally, the smallest blocks to offices or facilities in those regions. So 10.1.0.0/22 could be allocated to the New York region. Within this block 10.1.1.0/24 could be allocated to the New York City office while 10.1.2.0/24 could be assigned to the New Jersey office. The VoIP phones in both offices fall within the 10.1.0.0/22 block.
In addition to security, these summarizable address blocks can be used to identify packets for QoS marking. Any packet that has a Source or Destination IP address within the 10.1.0.0/22 address space could have its QoS marking set to the appropriate value (typically DSCP 46).
Ah, you say, why not simply identify and mark all voice packets by their inherent characteristics (like packet size, port numbers, protocol ID)? We've seen networks where that was done. In one case, we were brought in to investigate poor voice performance. It turned out that there were many non-business voice packets in the network. The simple classification mechanism was marking all voice packets with DSCP 46. We had to change the network configurations to identify and add QoS markings to the business voice traffic only. This forced the non-business voice traffic into the 'best effort' queue where it wouldn't impact the important voice calls. The network equipment configurations to properly identify the business voice traffic was significantly more complex than we wanted, because the endpoints had not been assigned addresses within an easily summarizable block.
Interface Grouping
Grouping interfaces by tags that you create allows the network management system to easily identify critical interfaces and their current operational state. Since converged networks are often highly redundant, the first failure doesn't cause an outage. It is the second failure, often months later, that causes a major outage. The first failure is invisible; the second failure is not. By using interface groups, we can have the Network Management System (NMS) generate an alert when a critical or redundant interface is down.
This mechanism involves tagging each critical interface, using a tag that is added to the end of the interface description within the device's configuration. The tag needs to be something that the NMS can easily use for grouping interfaces. [Note: The NMS needs to have the ability to group interfaces by arbitrary strings within the interface description, as well as the more common methods of grouping by address or interface name.] Here are some examples:
The first three examples identify critical links between core, distribution, and access network devices. The fourth example identifies the interface to which a UC server is connected. The last tag is a generic descriptive tag instead of a functional description. I prefer the more specific functional tag than the generic tag because it provides more information about the link's purpose. An interface group is created that contains any tag of Tag:core-core, Tag:core-distr, Tag:distr-access, or Tag:ucserver. These are all of our critical interfaces. (There may be more than these. This is a somewhat simplified example.) The interface group is often given the name "Critical Interfaces." We then configure the NMS to generate an alert whenever any interface in the group "Critical Interfaces" is found to be down.
There is no need to match primary and redundant interfaces. Simply mark all critical interfaces with a tag that indicates its importance.
How do we get the interfaces tagged? We use a Network Change and Configuration Management (NCCM) function from the NMS toolset. A good NCCM product will include the ability to write short scripts that can be used to automate the tagging of critical interfaces, simply by examining information that has already been collected by the NMS. The NCCM function will need to be run periodically to make sure that interface tags are up to date on all critical interfaces.
Don't forget to have the NCCM function identify interfaces that should be marked as critical, but are currently down due to a failure. It is common to find one or two "invisible" failures in a large network.
Device Grouping
Device grouping provides benefits similar to those we saw with interface grouping. It is easy to identify failed devices where a redundant device is continuing to provide service. Like the interface group mechanism, we add a tag to a device description field within the configuration. We use the snmp-server location text command to store the tag. The NMS can then group devices by finding the tag in the configuration or by using the tag found by retrieving the snmp location data. Here are some examples:
As with interfaces, finding a redundant device that has failed is very valuable. Many network admins put the function or role of a device in its name, so this tag may not be as useful as with interfaces. The advantage of tagging is that multiple tags can be used, allowing the device to be part of multiple groups.
Summary
The tagging mechanism can be used for any critical device or interface, as long as the NMS provides the ability to identify groups based on where the tag is stored (interface description or device snmp-server location). The examples above use "Tag:" to identify the tags. The string that identifies a tag is arbitrary and can be shortened as long as it is unique within the context that the NMS uses for grouping. An alternative is to use "T:".
Address summarization should be used whenever possible to reduce the size of device configurations. Designing summarization into a new network is easy. It simply takes a little time to document the address design. It is even worth taking the time to implement summarization in an existing network where it was not done. Yes, it is time consuming to implement in an existing network, but the benefits are worth it.
Hear more from Terry Slattery on UC management at Enterprise Connect Orlando, March 16-19. Attend his Wednesday session, "Tools and Trends for Troubleshooting UC Performance." Register with code NJSPEAKER to save $300 on an event pass.
