Author: Dan DiNicolo

On small networks, the auditing process is almost always carried out manually. This is usually accomplished by issuing commands on various network devices to view their configuration, status, and so on. While this is a practical solution for environments that are relatively small, such a method would be exceptionally time consuming on a network that includes hundreds of network devices or more. Depending upon the equipment in use on the network, scripting can often to be to help automate the process, although this depends on the relative skill set of the network designer working on the project.

On larger networks, a variety of tools and utilities are typically used to gather auditing information. In some cases a customer may already have these tools deployed, while in others, specific utilities may need to be purchased or downloaded and installed just for this purpose. Examples of common utilities used to gather network audit information include:

• Network management systems like HP OpenView, Sun Solstice, IBM Tivoli, TNG Unicenter, CiscoWorks, and What’s Up Gold. Network management systems typically provide a wide variety of data about the current network including physical and logical topology maps, information about the configuration of network equipment, and so forth.
• Network diagramming and data collection tools like Microsoft Visio Enterprise Network Tools.
• Security tools like Cisco Secure Scanner to test for security vulnerabilities and issues.
• SNMP data-gathering utilities like the free Multi Router Traffic Grapher (MRTG).

Although network auditing using the tools listed is very effective and usually highly accurate, some of these applications can be very expensive, and therefore not practical in all situations. The good news is that another highly effective way of auditing a network is by using information provided by existing equipment. For example, accurate information about a network can also be gathered by analyzing the configuration of network devices.

On Cisco equipment, this information is usually gathered through the use of a few key commands.

Some of the common commands used to gather information about existing Cisco equipment include:

• show running-configuration. When issued on Cisco switches and routers, this command displays the configuration of a device that is currently being used.
• show version. When issued on Cisco switches, routers, and PIX firewalls, this command displays information about the model in use, system specifications, the device’s IOS version, and more.
• write terminal. When issued on a Cisco PIX firewall, this command displays the current running configuration of the system.
• show tech-support. When issued on a Cisco switch, router, or PIX firewall, this command displays complete information about the configuration of the device, aggregating the information provided by various show commands.
• show processes. This command displays information about all of the processes currently running on a system, including CPU utilization information for the last 5 seconds, 1 minute, and 5 minutes.
• show buffers. This command displays information about how a system is allocating RAM for the purpose of buffering packets. A high level of buffer misses may mean that the system does not have sufficient memory to function effective on the network.

When attempting to characterize a customer’s existing network, using the configuration of existing equipment (Cisco or otherwise) represents a very accurate method of obtaining information for analysis purposes.

A far more accurate source of information about the existing customer network is obtained through auditing. Generally speaking, auditing involves using various methods, tools, and IOS commands to gather information about the current status of the network.

For example, a company may already have a network management system like HP OpenView deployed that could be used to generate network topology maps, provide performance-related information, and more. Similarly, various IOS commands can also be used to gather information of the status of any existing Cisco equipment. Ultimately, this auditing information will help to paint a more realistic picture of the current network environment.

Although all network design projects will ultimately involve a very careful and thorough analysis of the existing network, a great deal of information is often provided in advance by the customer. Sometimes this information is limited to what has been provided in the RFP and RFI documents, while in others, large amounts of supplementary documentation may be passed to the designer. While this provides a useful introduction to the existing environment, documentation can often be well out of date, incorrect, or misleading. For that reason, documentation provided by the customer should never be assumed to be complete and/or accurate.

By the same token, understanding a customer’s existing network will usually involve interviews with various staff and management. Where documentation generally provides the details of an existing implementation, interviews can often help to uncover the rationale for various decisions that were made. Again, the information that is gathered about the existing network from various staff members can seldom be considered entirely complete or accurate. Here again, people have points of view and opinions, and their perspective may not accurately reflect the true current situation.

Conducting interviews and using examining existing documentation are almost always the first steps in attempting to characterize a customer’s existing network. However, always keep in mind that this is generally the least accurate of the different types of information you will collect as part of your assessment.

Once the initial customer requirement, goals, and constraints associated with a proposed network design project have been determined and documented, it’s time to move on to step 2 of the network design process. Identifying and analyzing the current network involves learning as much information as possible about an organization’s existing network. Having this information is absolutely critical, since it provides the designer with in-depth knowledge of the potential issues that will need to be dealt with as part of designing, implementing, and testing the proposed solution.

As a general rule, three main methods are used to identify and analyze a customer’s existing network environment. These include:

• Using existing documentation and interviews with the customer
• Auditing the current network
• Performing network traffic analysis

Each of these methods may be comprised of many steps that involve different processes and applications to gather the required data. Although each method represents a valid and important part of identifying and analyzing an existing network, the actual accuracy of the information varies between the sources. For example, while the information provided through auditing the existing network is likely to be very accurate, information provided by the customer could often be less accurate based on biases and points of view.

The types of information that need to be gathered about the existing network include:

• Network topologies in use at different OSI layers
• Network services currently deployed
• Network configuration including addressing, routing, and equipment configuration
• Network applications in use
• Performance and functionality of the existing infrastructure

The following articles outline each of the methods used to identify and analyze a customer’s existing network, along with an overview of the tools and information sources used by each method.

As part of the process of gathering information about a customer’s goals, constraints, and requirements for a new or upgraded network, documentation needs to be created. Ultimately, this documentation will be used to confirm that both the designer and the customer agree on the requirements, as well as associated goals and constraints that will impact the project.

The documentation of the gathered information is not subject to any specific format at this point in the process. However, there are certain methods that can be used to structure the information, making it easier for both the network designer and the customer to review in a more organized and simplified manner. Perhaps the most popular method is through the use of decision matrices.

A decision matrix is not nearly as complex as it sounds. In truth, it’s really nothing more than a table that can be used to document information about specific elements of the network design or data gathering process. For example, a decision table might be used to document all required applications for a new network, as shown below. In this example, the matrix simply lists a particular application type, its name, importance information, and comments.

Example Decision Matrix 

Once created, a decision matrix provides a simplified high-level overview of gathered data or design information that makes it easy for the designer and decision makers to easily review project details.

Aside from documenting the business and technical goals and constraints of an organization, the initial data gathering process needs to also consider any new planned services, applications, and features required for the new or upgraded network. For example, an organization might be planning to implement a new email platform, Voice over IP (VoIP) services, or a network management system (NMS). Ultimately, the network requirements outlined by the customer need to be considered in conjunction with both the goals and constraints looked at earlier.

The bullet points below outline some of the common types of applications, services or features that a company might have defined as requirements for a new or upgraded network.

• Security services. Examples of security services that a company might be looking to implement as part of a new or redesigned network include authentication services like RADIUS, firewalls like a Cisco PIX, or IPSec VPN connections between offices.
• Network management applications. Examples of network management applications that a company might be looking to deploy include elements of the CiscoWorks suite, HP OpenView, and other SNMP-based utilities.
• Network availability. On of the most common requirements specified by customers includes the need for high network availability in order to provide redundancy. This can be accomplished in a variety of ways, including through the use of redundant links to interconnect equipment.
• Advanced service support. Customer requirements for a new or upgraded network may include the need to support features like Quality of Service (QoS) and IP Multicasting.

Outside of simply defining new applications, services and features, information should also be gathered about how critical the customer considers each to be. For example, although the customer may specify ten new requirements, some of the business constraints (such as the budget) may impact the number of applications or services that can be ultimately be deployed. By prioritizing in this way, the designer can work with the customer to determine which elements can reasonably be implemented based on all of the available information.

Similar to business constraints, technical constraints represent any of a number of technical issues and obstacles that will impact the network design. For example, a company may have made a fairly recent investment in some new equipment, and require that this equipment be incorporated into the new network design. Similarly, a company might be trying to connect many rural branch offices to a central location via WAN links. An example of a technical constraint in this case might be a company’s preference for Frame Relay, but it not being available in some of the proposed locations.

The bullet points below outline some of the most common types of technical constraints that a network designer may encounter, along with examples.

• Bandwidth or media limitations. In any network design project, it is conceivable that certain parts of a network cannot be changed for a variety of reasons. For example, an organization might have a LAN installed in a factory that uses 10 Mbps fiber optic cabling that they are not willing to replace, perhaps for budgetary reasons. In this case, the available media and bandwidth represents a technical constraint that must be circumvented, since replacement is not an option
• Application limitations. The applications currently used by an organization can have a significant impact on a network design project. For example, the customer may rely upon a particular program that can only function using a specific protocol like NetBEUI. In this case, the application would either need to be replaced, or the design would have to include support for the NetBEUI protocol. In a similar manner, a customer might still be using an older operating system like Novell NetWare 3.11 for an accounting application, necessitating that the design include the IPX/SPX protocol.
• Personnel limitations. Even in cases where an organization has sufficient staff to allocate to a project, it is possible that these staff members do not have the technical expertise required to help implement the new network or manage it once complete. This is another example of a technical constraint that may need to be dealt with by obtaining additional training for the staff, hiring additional staff, or revising the scope of the project.
• Existing equipment. Over time, companies invest in a variety of different network equipment to meet different needs. Although some companies can afford to replace all existing equipment as part of a network upgrade project, others will want to protect existing investments and reuse as much existing equipment as possible. This is a classic technical constraint that ultimately impacts almost every network design project.

Although the implementation of technologies is generally driven by business needs to begin with, companies ultimately come to rely upon these same technologies in order to function over the longer term. In line with this concept, an organization will general have technical goals as part of any planned network design project.

Examples of common technical goals include improving the security, performance, availability, and scalability of a network, as well as streamlining network management functions. Each of these areas is looked at in the bullet points below in more detail.

• Improve network security. Improving or redesigning the security of an organization’s network is an example of a technical goal. For example, a company may want to implement firewalls or intrusion detection systems to better protect internal systems from external users.
• Improve network performance. Improving performance through the implementation of a new network or the upgrade of an existing network is another common example of a technical goal. For example, a company might still be using 10 Mbps Ethernet hubs for connectivity on some LANs, and might want to increase performance at the access layer by implementing Fast Ethernet and dedicated switch ports for all systems.
• Increase network availability. Increasing network availability is a technical goal usually achieved through the implementation of network redundancy features. For example, a company might specify that any new network must implement redundant trunk links between switches, such that the failure of any link would not impact the entire network.
• Streamline network management. The redesign of network management processes in another example of a technical goal. For example, an organization’s current network management strategy might be largely reactive, trying to deal with problems when they arise. Deciding to implement a network management system such as HP OpenView for the purpose of proactive management would be considered a technical goal.
• Increase network scalability. Over time, the network requirements for an organization will change. For example, a company might be planning to merge with another organization in the near future, and wants to ensure that the new network will be able to scale in a manner suitable to supporting new users, connections, and more.

In a perfect world, a network design project would not have any business constraints. The network designer would be given a list of business and technical goals, along with a blank check. Unfortunately, business constraints like financial issues, corporate policies, scheduling, and personnel issues must all be carefully determined, considered, and well understood in order for a network design project to succeed. Overlooking any one of these areas would at best lead to a few unpleasant surprises, and at worst, potentially doom the network design project to failure.

The list below outlines some of the more common business constraints that you should be familiar with, along with examples.

• Budgets. Financial considerations represent the most common business constraint. While some companies develop a fixed budget for a project in advance, others tend to be more flexible, especially in cases where the scope of a project changes after the current situation is assessed. Regardless of whether it is flexible or not, the budget associated with any project represents the classic example of a business constraint, and one that is generally easy to identify.
• Corporate policies. Businesses of all sizes define policies and procedures based on what they perceive to be best practices. Since policies vary from organization to organization, it is critical for the network designer to gather information about any policies that might impact a project. An example of a corporate policy that represents a business constraint would include a company requiring you to deal with a preferred vendor.
• Scheduling issues. Scheduling issues are an example of another very common business constraint. As part of deciding to pursue a particular project like implementing a new network or an upgrading an existing one, a customer will generally include a schedule that defines when the project should be completed, as well as individual milestones.
• Personnel issues. Personnel issues are an example of a business constraint that can take many different forms. For example, a company might not have sufficient staff to allocate to a project, or those staff members may not have the required knowledge to participate. Similarly, personnel issues can also impact project schedules based on the availability of staff when factors like other projects or vacation time are considered.

Perhaps the most important part of gathering information for any network design project is determining an organization’s business goals. While implementing a new network that supports a variety of new applications and services may be the main deliverable for a project, this outcome is usually driven by business needs. Very few companies have the resources (monetary or otherwise) to implement technology for technology’s sake. Instead, they have specific organizational goals, which technologies like a new or redesigned network are implemented to support and enhance. In almost all cases, business needs drive technology, and not vice versa. This is an important distinction that many IT people often overlook.

The bullet points below outline some common business goals that you should be familiar with. Others certainly do exist, but almost all can be broadly characterized with the categories provided.

• Increase productivity. Increasing productivity is a central goal of just about all organizations. For example, a company may want make employees more efficient, helping them to spend more time on their core responsibilities. Similarly, a manufacturing company may be looking to implement new communications processes for advanced monitoring, thereby reducing downtime. Anything that relates to increasing productivity or efficiency can safely be considered a business goal.
• Improve customer support. All organizations rely upon their customer base in order to survive. Regardless of industry, a company without customers soon ceases to be one. As globalization makes competition fiercer, companies need to look towards improved methods of communication with and supporting their customers. For example, perhaps the goal of a company is to consolidate customer management functions, or shift all order processing and procurement to a new online system. Both would be examples of a business goal, namely improving customer support.
• Reduce costs. One major reason for implementing a new or redesigned network is to help reduce costs, both in the short and longer term. Although implementing a network generally involves a fairly large initial capital investment, it may have a significant impact on reducing costs in the long term. For example, perhaps a company is looking to implement a Voice over IP solution in order to reduce costs associated with long distance calls, or a new VPN in order to allow staff to work from home, reducing the need for office space and related equipment.
• Improve partner relationships. For many companies, managing partnerships or associated relationships effectively is critical to their line of business. For example, an automobile manufacturer relies upon potentially hundreds of suppliers to ensure that it can produce completed vehicles. When companies have different internal processes and methods for exchanging information, this can become a daunting task. As such, many companies now look to implement systems to tie into those of their partners, streamlining processes and communications. While implementing an extranet might be a technical goal, improving and streamlining processes between organizations would be the associated business goal.