Characterizing the Existing Network and Sites

The second step of the design methodology is characterizing the existing network and sites. Information collected and documented in this step is important, because the design might depend on the existing network's hardware, software, and link capacity.

In many cases, a network already exists and the new design relies on restructuring and upgrading the existing network and sites. Even when a network does not exist, the sites that will be networked still should be examined. The following sections present insights into the process of examining an existing network and sites and describe the tools used to gather the data, assess the network, and analyze the network. A checklist to assess the network's health is presented. Guidelines for creating a summary report are introduced. The discussion concludes with the draft design document and estimates of the time required to complete the entire characterization process.

The first step in characterizing the existing network and sites is to gather as much information about them as possible, typically based on the following input:

Step 1 Customer input: Review existing documentation about the network, and use verbal input from the customer to obtain a first impression about the network. Although this step is mandatory, it is usually insufficient, and some results might be incorrect.

Step 2 Network audit: Perform a network audit, also called an assessment, which reveals details of the network and augments the customer's description.

Step 3 Traffic analysis: If possible, use traffic analysis to provide information about the applications and protocols used and to reveal any shortcomings in the network.

NOTE Although traffic analysis is a good idea in principle, it is often too costly in terms of time and effort to do in practice.

The following sections describe each of these steps and the tools used. Customer Input

Customer input includes all pertinent network and site documentation. Some items the designer could request, depending on the scope of the project, include the following:

■ Site contact information (especially needed if remote deployments are planned)

■ Existing network infrastructure (from physical diagrams and documents, and site surveys as needed), including the following:

— Locations and types of servers, including a list of network applications supported

— Locations and types of network devices

— Cabling that is currently in place, including network interface connection tables and worksheets

— Wiring closet locations

— Environmental controls, including heating, ventilation, and air conditioning requirements, and filtration

— Locations of telephone service demarcation points

— WAN speeds and locations of the WAN connection feeds

— Locations of power receptacles, and availability of additional receptacles and power sources

■ Existing network infrastructure from logical topology diagrams, including the addressing scheme and routing protocols in use, and the infrastructure services supported, such as voice, storage, and wireless services

■ Information about the expected network functionality

This documentation should allow the designer to determine information about the planned and existing network and sites, including the following:

■ Network topology: Includes devices, physical and logical links, external connections, bandwidth of connections, frame types (data link encapsulations), IP addressing, routing protocols, and so forth.

■ Network services: Includes security, QoS, high availability, voice, storage, wireless, and so forth.

■ Network applications: Examples include unified messaging and video delivery.

All this information should be included in the design document; it also forms the basis for breaking the network into modules.

Sample Site Contact Information

Site contact information is especially important for projects involving remote deployments when equipment delivery and installations must be coordinated. The customer might provide all the necessary site contact information, or the designer might have to conduct a physical site audit to obtain the necessary information.

While at the site, the designer can also obtain other information; for example, power availability can be determined by examining the existing wiring closets. Digital pictures taken by a remote site contact can help in getting a quick sense of the remote environment. Table 2-8 illustrates a sample site contact form.

Table 2-8 Sample Site Contact Form

1. What is the site location/name?

2. What is the site address?

3. What is the shipping address?

4. Who is the site contact?

Name: Title:

Telephone Number: Cell Phone Number: Fax Number: Pager Number: E-mail address:

Out-of-Hours Contact Number:

5. Is this site owned and maintained by the customer?

Yes/No

6. Is this a staffed site?

Yes/No

7. What are the hours of operation?

8. What are the building and room access procedures?

9. Are there any special security/safety procedures?

Yes/No

What are they?

10. Are there any union/labor requirements or procedures?

Yes/No

What are they?

11. What are the locations of the equipment cabinets and racks?

Floor: Room: Position:

Sample High-Level Network Diagram

Figure 2-8 shows the high-level topology of a sample network, provided by a customer.

Figure 2-8 Sample Customer-Provided High-Level Network Diagram

Management

Workstations Server Farm External Servers

Management

Workstations Server Farm External Servers

Figure 2-8 Sample Customer-Provided High-Level Network Diagram

High Level Network Diagram

With only this diagram, many questions remain about the network and the expected network functionality, including the following:

■ What is the IP addressing scheme?

■ What level of redundancy or high availability currently exists in the network?

■ What level of redundancy or high availability is required in the new network?

■ What are the details of the security design?

■ What types of links are in the network?

■ What are the planned Layer 2 and Layer 3 topologies?

■ How is connectivity provided to remote sites?

■ What network infrastructure services are in use, such as voice and video, and what is planned?

■ Are existing wireless devices in place, or are any wireless deployments planned?

■ What routing protocols are in use?

■ Are there any server farm or remote data center connectivity requirements?

■ What network management tools are in place?

It is important to get as much information as possible about the existing situation before commencing design.

Auditing or Assessing the Existing Network

A network audit or assessment is the second step in acquiring information about an existing network. The auditing process starts by consolidating existing information the customer provides. Up-to-date information can be gathered from the existing management software used by the customer. If the customer has insufficient tools, the designer can choose to temporarily introduce additional software tools; if they prove useful, these tools can be used in the network permanently (during the Operate and Optimize phases). An audit provides details such as the following:

■ A list of network devices

■ Hardware specifications and versions, and software versions of network devices

■ Configurations of network devices

■ Output of various auditing tools to verify and augment the existing documentation

■ Link, CPU, and memory utilization of network devices

■ A list of unused ports, modules, and slots in network devices, to be used to understand whether the network is expandable

Figure 2-9 illustrates three different sources of information that can be used in the auditing process: existing documentation, existing tools, and new tools.

Figure 2-9 Network Audit Information Sources

Figure 2-9 Network Audit Information Sources

Network Designer

Existing Management Software

Network Designer

Additional Auditing Tools (Optional)

Existing Management Software

Additional Auditing Tools (Optional)

The auditing process might require minor (temporary) network changes. Automated auditing should be used in large networks for which a manual approach would take too much time. However, the audit process balances both detail and effort to produce as much information as needed or possible. For example, it should not require that a large set of CPU-heavy auditing tools be purchased and installed in the customer network to collect configurations of network devices. The auditing process is typically performed from a central location, such as a location in a secure environment that has access to all network devices.

Figure 2-10 illustrates sample information that a manual or automated auditing process collects from the network management workstation. The auditing process should collect all information relevant to the redesign. The same process should be used for all network devices affected by the design.

Figure 2-1C Sample Information Collected During a Network Audit

Management Workstation a

Use Auditing Tools to Collect Network Information

Router Type CPU Type

Average CPU Utilization Memory Size and Utilization FLASH Size IOS Version Configuration Routing Tables

Interface Types Speeds

Average Link Utilizations Identify Unused Interfaces, Modules, or Slots

Tools for Assessing the Network

A small network can be assessed without special tools. Monitoring commands can be used to collect relevant information on a small number of network devices. The approach can be semi-automated by introducing scripting tools to execute the monitoring commands automatically.

In large networks, a manual auditing approach is too time-consuming and less reliable. The following are some special tools that can be used to collect the relevant information from the network devices:

■ CiscoWorks to map a network and collect various types of information (such as network topology, hardware and software versions, configurations, and so on).

■ Third-party tools such as WhatsUp Professional from Ipswitch, SNMPc from Castle Rock Computing, open-source Cacti (which is a successor to the popular Multi Router Traffic Grapher), NetMRI from Netcordia, and NetVoyant from NetQoS.

■ Other vendors' tools to collect relevant information from equipment manufactured by those vendors.

■ Other tools can help characterize the existing environment. For example, instead of a full wireless site survey, it can be helpful to conduct a brief RF sample of the environment using enterprise-level tools. Such tools include AirMagnet Survey PRO (to perform an RF site survey), Cognio Spectrum Expert (a spectrum analysis tool), and laptop applications such as AiroPeek from WildPackets (network analyzer software that supports decoding of wireless data packets) and the Cisco Aironet Site Survey Utility. Wireless networks are described in detail in Chapter 9, "Wireless Network Design Considerations."

Assessment Tool Information

Information on the aforementioned tools can be found at the following locations:

■ CiscoWorks: http://www.cisco.com/

■ WhatsUp Professional: http://www.ipswitch.com/

■ SNMPc: http://www.castlerock.com/

■ Cacti: http://www.cacti.net/

■ NetMRI: http://www.netcordia.com/

■ NetVoyant: http://www.netqos.com/

■ AirMagnet Survey PRO: http://www.airmagnet.com/

■ Spectrum Expert: http://www.cognio.com/

■ AiroPeek: http://www.wildpackets.com/

■ Cisco Aironet Site Survey Utility: http://www.cisco.com/

Manual Information Collection Examples

The auditing process can be performed manually on relatively small networks using various monitoring commands. Figure 2-11 illustrates three different types of network devices, information to be collected, and commands that can be used to obtain the information:

■ On Cisco routers that run Cisco IOS software, the show tech-support command usually displays all information about the router. show processes cpu can be used to determine CPU use, and show processes memory can be used to determine memory usage.

■ On Cisco switches that run Cisco Catalyst Operating System (CatOS) software, the most useful commands vary, depending on the version of the software. Useful commands might include show version, show running-config, or show tech-support, if available.

■ On Cisco Secure PIX Security Appliances, the show version and write terminal (to see the configuration) commands are useful.

Figure 2-11 Collecting Audit Information on Cisco Devices

Platform: Cisco 7206 Cisco IOS Version: 12.2(8)T Memory: 64 MB FLASH: 16 MB Free Memory: 5 MB Config:

I Platform: Catalyst 5509 Cat OS Version: 6.3.5cv Memory: 16 MB FLASH: 16 MB Free Memory: 6 MB Config:

Router#show tech-support

irk Operating System Software IOS (tm) 7200 Software (C720 0-JS-M), Version TAC Support: http://www.cisco.com/tac Copyright (c) 1986-2002 by Cisco Systems, Inc. (snip)

Switch#show

version

<snip>

Switch:show

running-config

<snip>

Swithc#show

tech-support

<snip>

PIX#write terminal

Platform: PIX 535 PIX OS Version: 6.1(2) Memory: 64 MB FLASH: 16 MB Config:

PIX#show version

PIX#write terminal

Characterizing the Existing Network and Sites 91 Many other commands are available on Cisco devices to determine relevant information.

NOTE If older equipment or older versions of the Cisco IOS are being used, the capability of the network to support new services might be affected.

Example 2-1 illustrates sample output from the show processes cpu command on a Cisco router.

Example 2-1 show processes cpu Command Output Router#show processes cpu

CPU utilization for five seconds: 24%/20%; one minute: 45%; five minutes: 40%

PID

Runtime(ms)

Invoked

uSecs

5Sec

1Min

5Min

TTY

Process

1

2464

468381

5

0.00%

0.00%

0.00%

0

Load Meter

2

44

44

1000

0.16%

0.04%

0.01%

66

Virtual Exec

3

0

2

0

0.00%

0.00%

0.00%

0

IpSecMibTopN

4

6326689

513354

12324

0.00%

0.25%

0.27%

0

Check heaps

5

0

1

0

0.00%

0.00%

0.00%

0

Chunk Manager

6

60

58

1034

0.00%

0.00%

0.00%

0

Pool Manager

7

0

2

0

0.00%

0.00%

0.00%

0

Timers

8

0

12

0

0.00%

0.00%

0.00%

0

Serial Backgroun

9

2139

468342

4

0.00%

0.00%

0.00%

0

ALARM_TRIGGER_SC

10

3851

78081

49

0.00%

0.00%

0.00%

0

Environmental mo

11

4768

44092

108

0.00%

0.00%

0.00%

0

ARP Input

12

4408

19865

221

0.00%

0.00%

0.00%

0

DDR Timers

13

4

2

2000

0.00%

0.00%

0.00%

0

Dialer event

14

16

2

8000

0.00%

0.00%

0.00%

0

Entity MIB API

15

0

1

0

0.00%

0.00%

0.00%

0

SERIAL A'detect

16

0

1

0

0.00%

0.00%

0.00%

0

Critical Bkgnd

17

57284

377088

151

0.00%

0.00%

0.00%

0

Net Background

18

15916

59331

268

0.00%

0.00%

0.00%

0

The output in Example 2-1 displays information about the network device CPU utilization, which is important for describing the network's health. Table 2-9 describes the show processes cpu command output's fields and descriptions.

Table 2-9 show processes cpu Command Output Description

Field

Description

CPU utilization

CPU utilization for the last:

Five seconds—The first number in the ratio indicates the total CPU utilization; the second number in the ratio indicates the percentage of CPU time that was spent at the interrupt level

One minute—Total CPU utilization for the last minute Five minutes—Total CPU utilization for the last 5 minutes

PID

The process ID

Runtime (ms)

CPU time, expressed in milliseconds, that the process has used

Invoked

The number of times the process has been invoked

uSecs

Microseconds of CPU time for each process invocation

5Sec

CPU utilization by task in the last 5 seconds

1Min

CPU utilization by task in the last minute

5Min

CPU utilization by task in the last 5 minutes

TTY

Terminal that controls the process

Process

Name of the process

Example 2-2 illustrates sample output from the show processes memory command on a Cisco router.

Example 2-2 show processes memory Command Output Router#show process memory

Total

: 26859400, Used

: 8974380,

Free: 17885020

PID

TTY

Allocated

Freed

Holding

Getbufs

Retbufs

Process

0

0

88464

1848

6169940

0

0

*Init*

0

0

428

1987364

428

0

0

*Sched*

0

0

116119836

105508736

487908

373944

55296

*Dead*

1

0

284

284

3868

0

0

Load Meter

2

66

5340

1080

17128

0

0

Virtual Exec

3

0

668

284

7252

0

0

IpSecMibTopN

4

0

0

0

6868

0

0

Check heaps

5

0

96

0

6964

0

0

Chunk Manager

6

0

17420

231276

6964

5388

254912

Pool Manager

7

0

284

284

6868

0

0

Timers

8

0

284

284

6868

0

0

Serial Background

Example 2-2 show processes memory Command Output (Continued)

9

0

0

0

6868

0

0

ALARM_TRIGGER_SC

10

0

284

284

6868

0

0

Environmental mo

11

0

316

3799360

7184

0

0

ARP Input

12

0

2547784

1033916

7372

6804

0

DDR Timers

13

0

284

284

12868

0

0

Dialer event

14

0

10744

2284

15328

0

0

Entity MIB API

15

0

96

0

6964

0

0

SERIAL A'detect

16

0

96

0

6964

0

0

Critical Bkgnd

17

0

23412

2632

15404

0

0

Net Background

<more>

Table 2-10 describes the show processes memory command output's fields and descriptions. Table 2-10 show processes memory Command Output Description

Field

Description

Total

Total amount of held memory

Used

Total amount of used memory

Free

Total amount of free memory

PID

Process ID

TTY

Terminal that controls the process

Allocated

Bytes of memory allocated by the process

Freed

Bytes of memory freed by the process, regardless of who originally allocated it

Holding

Amount of memory currently allocated to the process

Getbufs

Number of times the process has requested a packet buffer

Retbufs

Number of times the process has relinquished a packet buffer

*Init*: System initialization *Sched*: The scheduler

*Dead*: Processes that are now dead as a group

Total (not shown in Example 2-2)

Total amount of memory held by all processes

Automatic Information Collection Examples

Figure 2-12 is a screen shot from the open-source Cacti application showing a list of devices found in the network.

Figure 2-12 Cacti Device List Example

Figure 2-12 Cacti Device List Example

Figure 2-13 is a screen shot from the NetMRI appliance from Netcordia. The inventory results are expanded to show the Cisco Cat4506 devices, including IP addresses, device names, and operating system versions.

Figure 2-13 NetMRI Inventory Example

Figure 2-13 NetMRI Inventory Example

Was this article helpful?

+1 0

Post a comment