| 0 comments ]

Characterizing the Existing Network and Sites

Add a note here 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.

Add a note hereIn 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.

Add a note hereThe 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:

Add a note here Step 1

Add a note here 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.

Add a note here Step 2

Add a note here Network audit: Perform a network audit, also called an assessment, which reveals details of the network and augments the customer’s description.

Add a note here Step 3

Add a note here 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

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

Add a note hereThe following sections describe each of these steps and the tools used.

Add a note here Customer Input

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

  • Add a note hereSite contact information (especially needed if remote deployments are planned)

  • Add a note hereExisting network infrastructure (from physical diagrams and documents, and site surveys as needed), including the following:

    • Add a note here Locations and types of servers, including a list of network applications supported

    • Add a note hereLocations and types of network devices

    • Add a note hereCabling that is currently in place, including network interface connection tables and worksheets

    • Add a note hereWiring closet locations

    • Add a note hereEnvironmental controls, including heating, ventilation, and air conditioning requirements, and filtration

    • Add a note hereLocations of telephone service demarcation points

    • Add a note hereWAN speeds and locations of the WAN connection feeds

    • Add a note hereLocations of power receptacles, and availability of additional receptacles and power sources

  • Add a note hereExisting 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

  • Add a note hereInformation about the expected network functionality

Add a note hereThis documentation should allow the designer to determine information about the planned and existing network and sites, including the following:

  • Add a note here 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.

  • Add a note here Network services: Includes security, QoS, high availability, voice, storage, wireless, and so forth.

  • Add a note here Network applications: Examples include unified messaging and video delivery.

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

Sample Site Contact Information

Add a note hereSite 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.

Add a note here 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.

Add a note here Table 2-8: Sample Site Contact Form
Open table as spreadsheet
  1. Add a note hereWhat is the site location/name?

  1. Add a note hereWhat is the site address?

  1. Add a note hereWhat is the shipping address?

  1. Add a note hereWho is the site contact?

Add a note hereName:

Add a note hereTitle:

Add a note hereTelephone Number:

Add a note hereCell Phone Number:

Add a note hereFax Number:

Add a note herePager Number:

Add a note hereE-mail address:

Add a note hereOut-of-Hours Contact Number:

  1. Add a note hereIs this site owned and maintained by the customer?

Add a note hereYes/No

  1. Add a note hereIs this a staffed site?

Add a note hereYes/No

  1. Add a note hereWhat are the hours of operation?

  1. Add a note hereWhat are the building and room access procedures?

  1. Add a note hereAre there any special security/safety procedures?

Add a note hereYes/No

Add a note hereWhat are they?

  1. Add a note hereAre there any union/labor requirements or procedures?

Add a note hereYes/No

Add a note hereWhat are they?

  1. Add a note hereWhat are the locations of the equipment cabinets and racks?

Add a note hereFloor:

Add a note hereRoom:

Add a note herePosition:

Sample High-Level Network Diagram

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

Click to collapse
Add a note hereFigure 2-8: Sample Customer-Provided High-Level Network Diagram

Add a note hereWith only this diagram, many questions remain about the network and the expected network functionality, including the following:

  • Add a note hereWhat is the IP addressing scheme?

  • Add a note hereWhat level of redundancy or high availability currently exists in the network?

  • Add a note hereWhat level of redundancy or high availability is required in the new network?

  • Add a note hereWhat are the details of the security design?

  • Add a note hereWhat types of links are in the network?

  • Add a note hereWhat are the link speeds?

  • Add a note here What are the planned Layer 2 and Layer 3 topologies?

  • Add a note hereHow is connectivity provided to remote sites?

  • Add a note hereWhat network infrastructure services are in use, such as voice and video, and what is planned?

  • Add a note hereAre existing wireless devices in place, or are any wireless deployments planned?

  • Add a note hereWhat routing protocols are in use?

  • Add a note hereAre there any server farm or remote data center connectivity requirements?

  • Add a note hereWhat network management tools are in place?

Add a note hereIt is important to get as much information as possible about the existing situation before commencing design.

Add a note here Auditing or Assessing the Existing Network

Add a note hereA 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:

  • Add a note hereA list of network devices

  • Add a note hereHardware specifications and versions, and software versions of network devices

  • Add a note hereConfigurations of network devices

  • Add a note hereOutput of various auditing tools to verify and augment the existing documentation

  • Add a note hereLink, CPU, and memory utilization of network devices

  • Add a note hereA list of unused ports, modules, and slots in network devices, to be used to understand whether the network is expandable

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

Click to collapse
Add a note hereFigure 2-9: Network Audit Information Sources

Add a note here 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.

Add a note here 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.

Click to collapse
Add a note hereFigure 2-10: Sample Information Collected During a Network Audit

Add a note here Tools for Assessing the Network

Add a note here 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 semiautomated by introducing scripting tools to execute the monitoring commands automatically.

Add a note hereIn 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:

  • Add a note hereCiscoWorks to map a network and collect various types of information (such as network topology, hardware and software versions, configurations, and so on).

  • Add a note hereThird-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.

  • Add a note hereOther vendors’ tools to collect relevant information from equipment manufactured by those vendors.

  • Add a note hereOther 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.”

Manual Information Collection Examples

Add a note hereThe 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:

  • Add a note hereOn 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.

  • Add a note hereOn 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.

  • Add a note hereOn Cisco Secure PIX Security Appliances, the show version and write terminal (to see the configuration) commands are useful.

Click to collapse
Add a note hereFigure 2-11: Collecting Audit Information on Cisco Devices

Add a note here Many other commands are available on Cisco devices to determine relevant information.


Note

Add a note hereIf older equipment or older versions of the Cisco IOS are being used, the capability of the network to support new services might be affected.

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

Add a note here Example 2-1: show processes cpu Command Output

Add a note hereRouter#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 Logger




Add a note hereThe 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.

Add a note here Table 2-9: show processes cpu Command Output Description
Open table as spreadsheet

Add a note here Field

Add a note hereDescription

Add a note hereCPU utilization

Add a note hereCPU utilization for the last:

Add a note here 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

Add a note here One minute— Total CPU utilization for the last minute

Add a note here Five minutes— Total CPU utilization for the last 5 minutes

Add a note herePID

Add a note hereThe process ID

Add a note hereRuntime (ms)

Add a note hereCPU time, expressed in milliseconds, that the process has used

Add a note hereInvoked

Add a note hereThe number of times the process has been invoked

Add a note hereuSecs

Add a note hereMicroseconds of CPU time for each process invocation

Add a note here5Sec

Add a note hereCPU utilization by task in the last 5 seconds

Add a note here1Min

Add a note hereCPU utilization by task in the last minute

Add a note here5Min

Add a note hereCPU utilization by task in the last 5 minutes

Add a note hereTTY

Add a note hereTerminal that controls the process

Add a note hereProcess

Add a note hereName of the process

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

Add a note here Example 2-2: show processes memory Command Output

Add a note hereRouter#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
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


Add a note here Table 2-10 describes the show processes memory command output's fields and descriptions.

Add a note here Table 2-10: show processes memory Command Output Description
Open table as spreadsheet

Add a note hereField

Add a note hereDescription

Add a note hereTotal

Add a note hereTotal amount of held memory

Add a note hereUsed

Add a note hereTotal amount of used memory

Add a note hereFree

Add a note hereTotal amount of free memory

Add a note herePID

Add a note hereProcess ID

Add a note hereTTY

Add a note hereTerminal that controls the process

Add a note hereAllocated

Add a note hereBytes of memory allocated by the process

Add a note hereFreed

Add a note hereBytes of memory freed by the process, regardless of who originally allocated it

Add a note hereHolding

Add a note hereAmount of memory currently allocated to the process

Add a note hereGetbufs

Add a note hereNumber of times the process has requested a packet buffer

Add a note hereRetbufs

Add a note hereNumber of times the process has relinquished a packet buffer

Add a note hereProcess

Add a note hereProcess name

Add a note here*Init*: System initialization

Add a note here*Sched*: The scheduler

Add a note here*Dead*: Processes that are now dead as a group

Add a note hereTotal (not shown in Example 2-2)

Add a note hereTotal amount of memory held by all processes

Automatic Information Collection Examples

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

Image from book
Add a note hereFigure 2-12: Cacti Device List Example

Add a note here 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.

Image from book
Add a note hereFigure 2-13: NetMRI Inventory Example

Add a note here Analyzing Network Traffic and Applications

Add a note here Traffic analysis is the third step in characterizing a network. Traffic analysis verifies the set of applications and protocols used in the network and determines the applications’ traffic patterns. It might reveal any additional applications or protocols running on the network. Each discovered application and protocol should be described in the following terms:

  • Add a note hereImportance to the customer

  • Add a note hereQoS-related requirements

  • Add a note hereSecurity-related requirements

  • Add a note hereScope (in other words, the network modules in which the application or protocol is used)

Add a note hereUse the following interactive approach, illustrated in Figure 2-14, to create a list of applications and protocols used in the network:

Add a note here Step 1

Add a note hereUse customer input to list expected applications.

Add a note here Step 2

Add a note hereUse traffic analyzers to verify the customer’s list of applications.

Add a note here Step 3

Add a note herePresent the customer with the new list of applications, and discuss discrepancies.

Add a note here Step 4

Add a note hereGenerate the final list of applications and their requirements (importance, QoS, security), as defined by the customer.

Click to collapse
Add a note hereFigure 2-14: Use an Interactive Traffic Analysis Process

Add a note here For example, the following information was collected about a fictitious application:

  • Add a note hereName: Application #8

  • Add a note hereDescription: Accounting software

  • Add a note hereProtocol: Transmission Control Protocol (TCP) port 5151

  • Add a note hereServers: 2

  • Add a note hereClients: 50

  • Add a note hereScope: Campus

  • Add a note hereImportance: High

  • Add a note hereAvg. Rate: 50 kbps with 10-second bursts to 1 megabit per second (Mbps)

Add a note hereAssume that a customer requirement concerns QoS on a WAN connection with limited bandwidth. In this case, the information collected is relevant because it describes the following:

  • Add a note hereThe application (TCP port 5151), which is required for performing classification

  • Add a note hereThe importance of the application; this information is useful for evaluating how much bandwidth should be allocated to the application

  • Add a note hereThe current bandwidth consumption according to the present QoS implementation

Add a note hereNote, however, that this information might not be relevant should the customer requirement instead concern a secure and resilient Internet connection. In that case, it might be necessary to gather additional information.

Add a note here Tools for Analyzing Traffic

Add a note hereTools used for traffic analysis range from manual identification of applications using Cisco IOS software commands to those in which dedicated software- or hardware-based analyzers capture live packets or use the Simple Network Management Protocol (SNMP) to gather interface information. Analysis tools include the following:

  • Add a note here Cisco IOS Network-Based Application Recognition (NBAR): NBAR can be used to identify the presence of well-known applications and protocols in the network.

  • Add a note here Cisco IOS NetFlow technology: NetFlow is an integral part of Cisco IOS software that collects and measures data as it enters specific routers or switch interfaces. NetFlow allows the identification of lesser-known applications because it gathers information about every flow. This information can be collected manually using the Cisco IOS software show ip cache [verbose] flow command. Alternatively, Cisco Network Service (CNS) NetFlow Collection Engine (NFC) allows automatic information gathering of each flow in the network segment.

  • Add a note here Third-party hardware or software-based products: Can be used to analyze traffic in different subnets of the network. Examples include the following:

    • Add a note hereThe open-source Cacti (http://www.cacti.net/)

    • Add a note hereNetwork General Sniffer (http://www.sniffer.com/)

    • Add a note hereWildPackets EtherPeek and AiroPeek (http://www.wildpackets.com/)

    • Add a note hereSolarWinds Orion (http://www.solarwindssoftware.com/)

    • Add a note hereWireshark (http://www.wireshark.org/)

  • Add a note hereRemote monitoring probes can also be used to support traffic analysis.

Add a note hereThe following sections include examples of some of these tools.

NBAR

Add a note hereCisco IOS NBAR is a classification engine that recognizes a wide variety of applications, including web-based and other difficult-to-classify protocols, which utilize dynamic TCP and User Datagram Protocol (UDP) port assignments. Other QoS tools within the network can be configured to invoke services for a specific application that is recognized and classified by NBAR, ensuring that network resources are used efficiently.

Add a note here Example 2-3 is sample output of the Cisco IOS NBAR show ip nbar protocol-discovery command. This command shows the statistics gathered by the NBAR Protocol Discovery feature, which provides an easy way to discover application protocols that are transiting an interface. The Protocol Discovery feature discovers any protocol traffic supported by NBAR and can be used to monitor both input and output traffic. This command displays statistics for all interfaces on which the Protocol Discovery feature is currently enabled. The default output of this command includes the average 30-second bit rate (in bits per second), input byte count, input packet count, and protocol name.

Add a note here Example 2-3: show ip nbar protocol-discovery Command Output

Add a note hereRouter#show ip nbar protocol-discovery
FastEthernet0/0.2
Input Output
Protocol Packet Count Packet Count
Byte Count Byte Count
30 second bit rate (bps) 30 second bit rate(bps)
------------------------ ------------------------ -----------------------
http 46384 79364
5073520 64042528
305 1655

secure-http 2762 2886
429195 1486350
0 0
snmp 143 10676
17573 1679322
0 0
telnet 1272 12147
122284 988834
0 0
ntp 5383 0
624428 0
0 0
dns 305 235
31573 55690
50 120

NetFlow

Add a note hereNetFlow switching provides network administrators with access to detailed recording information from their data networks. NetFlow also provides a highly efficient mechanism with which to process security access lists without paying as much of a performance penalty as other available switching methods incur.

Add a note here Cisco Network Service NetFlow Collection technology provides the base for applications, including network traffic accounting, usage-based network billing, network planning, network monitoring, outbound marketing, and data-mining capabilities for both service provider and enterprise customers. Cisco provides a set of NFC applications that collect NetFlow export data, perform data volume reduction and post-processing, and give end-user applications easy access to NFC data. NFC also provides measurement-based QoS by capturing the traffic classification or precedence associated with each flow, enabling differentiated charging based on QoS. NFC is supported on HPUX, Solaris, Linux, and the Cisco CNS Programmable Network Family product. Chapter 3, “Structuring and Modularizing the Network,” discusses NetFlow technology in more detail.

Add a note here Example 2-4 provides sample output from the Cisco IOS show ip cache flow command, illustrating statistics gathered by the NetFlow switching feature. By analyzing NetFlow data, a designer can identify the cause of congestion, determine the class of service for each user and application, and identify the traffic’s source and destination network. NetFlow allows extremely granular and accurate traffic measurements and high-level aggregated traffic collection.

Add a note here Example 2-4: show ip cache flow Command Output

Add a note hereRouter#show ip cache flow


IP packet size distribution (12718M total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .554 .042 .017 .015 .009 .009 .009 .013 .030 .006 .007 .005 .004 .004

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.003 .007 .139 .019 .098 .000 .000 .000 .000 .000 .000


IP Flow Switching Cache, 4456448 bytes
65509 active, 27 inactive, 820628747 added
955454490 ager polls, 0 flow alloc failures
Exporting flows to 1.1.15.1 (2057)
820563238 flows exported in 34485239 udp datagrams, 0 failed
last clearing of statistics 00:00:03


Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 2656855 4.3 86 78 372.3 49.6 27.6
TCP-FTP 5900082 9.5 9 71 86.8 11.4 33.1
TCP-FTPD 3200453 5.1 193 461 1006.3 45.8 33.4
TCP-WWW 546778274 887.3 12 325 11170.8 8.0 32.3
TCP-SMTP 25536863 41.4 21 283 876.5 10.9 31.3
TCP-BGP 24520 0.0 28 216 1.1 26.2 39.0
TCP-other 49148540 79.7 47 338 3752.6 30.7 32.2
UDP-DNS 117240379 190.2 3 112 570.8 7.5 34.7
UDP-NTP 9378269 15.2 1 76 16.2 2.2 38.7
UDP-TFTP 8077 0.0 3 62 0.0 9.7 33.2
UDP-Frag 51161 0.0 14 322 1.2 11.0 39.4
ICMP 14837957 24.0 5 224 125.8 12.1 34.3
IP-other 77406 0.1 47 259 5.9 52.4 27.0
...
Total: 820563238 1331.7 15 304 20633.0 9.8 33.0

Add a note here Table 2-11 provides the show ip cache flow command output's fields and descriptions.

Add a note here Table 2-11: show ip cache flow Command Output Description
Open table as spreadsheet

Add a note hereField

Add a note hereDescription

Add a note herebytes

Add a note hereNumber of bytes of memory used by the NetFlow cache

Add a note hereactive

Add a note hereNumber of active flows in the NetFlow cache at the time this command was executed

Add a note hereinactive

Add a note hereNumber of flow buffers allocated in the NetFlow cache

Add a note hereadded

Add a note hereNumber of flows created since the start of the summary period

Add a note hereager polls

Add a note hereNumber of times the NetFlow code looked at the cache to expire entries

Add a note hereflow alloc failures

Add a note hereNumber of times the NetFlow code tried to allocate a flow but could not

Add a note hereExporting flows

Add a note hereIP address and UDP port number of the workstation to which flows are exported

Add a note hereflows exported

Add a note hereTotal number of flows exported and the total number of UDP datagrams sent

Add a note herefailed

Add a note hereNumber of flows that the router could not export

Add a note herelast clearing of statistics

Add a note hereStandard time output (hh:mm:ss) since the clear ip flow stats command was executed

Add a note here The activity by each protocol display field descriptions are as follows:

Add a note hereProtocol

Add a note hereIP protocol and the well-known port number (as documented at http://www.iana.org/)

Add a note hereTotal Flows

Add a note hereNumber of flows for this protocol since the last time statistics were cleared

Add a note hereFlows/Sec

Add a note hereAverage number of flows seen for this protocol, per second

Add a note herePackets/Flow

Add a note hereAverage number of packets in the flows seen for this protocol

Add a note hereBytes/Pkt

Add a note hereAverage number of bytes in the packets seen for this protocol

Add a note herePackets/Sec

Add a note hereAverage number of packets for this protocol, per second

Add a note here Active(Sec)/Flow

Add a note hereSum of all the seconds from the first packet to the last packet of an expired flow

Add a note hereIdle(Sec)/Flow

Add a note hereSum of all the seconds from the last packet seen in each non-expired flow

Other Network Analysis Tools Examples

Add a note here Figure 2-15 shows sample output from the Cacti tool, illustrating the daily throughput on a link in Dallas.

Image from book
Add a note hereFigure 2-15: Cacti Can Display Daily Traffic

Add a note here Figure 2-16 is a sample utilization table from the SolarWinds Orion tool, illustrating the current percentage utilization on the top 25 interfaces.

Image from book
Add a note hereFigure 2-16: SolarWinds Orion Tool Can Display Utilization

Add a note here Network Health Checklist

Add a note here Based on the data gathered from the customer’s network, the designer should check off any items that are true in the following Network Health Checklist. On a healthy network, it should be possible to check off all the items.

Add a note hereNote that these guidelines are only approximations. Exact thresholds depend on the type of traffic, applications, internetworking devices, topology, and criteria for accepting network performance. As every good engineer knows, the answer to most network performance questions (and most questions in general) is “It depends.”

  • Add a note hereNo shared Ethernet segments are saturated (no more than 40 percent network utilization).

  • Add a note hereNo WAN links are saturated (no more than 70 percent network utilization).

  • Add a note hereThe response time is generally less than 100 milliseconds (1 millisecond = 1/1000 of a second; 100 milliseconds = 1/10 of a second).

  • Add a note hereNo segments have more than 20 percent broadcasts or multicasts.

  • Add a note hereNo segments have more than one cyclic redundancy check error per million bytes of data.

  • Add a note hereOn the Ethernet segments, less than 0.1 percent of the packets result in collisions.

  • Add a note hereThe Cisco routers are not overutilized (the 5-minute CPU utilization is no more than 75 percent).

  • Add a note here The number of output queue drops has not exceeded 100 in an hour on any Cisco router.

  • Add a note hereThe number of input queue drops has not exceeded 50 in an hour on any Cisco router.

  • Add a note hereThe number of buffer misses has not exceeded 25 in an hour on any Cisco router.

  • Add a note hereThe number of ignored packets has not exceeded 10 in an hour on any interface on a Cisco router.

Add a note hereThe designer should also document any concerns about the existing network’s health and its ability to support growth.

Add a note here Summary Report

Add a note hereThe result of the network characterization process is a summary report that describes the network’s health. The customer input, network audit, and traffic analysis should provide enough information to identify possible problems in the existing network. The collected information must be collated into a concise summary report that identifies the following:

  • Add a note hereFeatures required in the network

  • Add a note herePossible drawbacks of and problems in the existing network

  • Add a note hereActions needed to support the new network’s requirements and features

Add a note hereWith this information, the designer should be able to propose hardware and software upgrades to support the customer requirements or to influence a change in requirements. Example 2-5 presents a sample summary report that identifies different aspects of a network infrastructure.

Add a note here Example 2-5: Sample Summary Report

Add a note hereThe network uses 895 routers:
–655 routers use Cisco IOS software version 12.3 or later
–221 routers use Cisco IOS software version 12.1(15)
–19 routers use Cisco IOS software version 12.0(25)

Requirement: QoS congestion management (queuing) required in the WAN
Identified problem:
–Cisco IOS software version 12.0 does not support new queuing technologies
–15 out of 19 routers with Cisco IOS software 12.0 are in the WAN
–12 out of 15 routers do not have enough memory to upgrade to Cisco IOS
software version 12.3 or later
–5 out of 15 routers do not have enough flash memory to upgrade to Cisco IOS
software version 12.3 or later

Recommended action:
–12 memory upgrades to 64 Megabytes (MB), 5 FLASH upgrades to 16MB
Alternatives:
–Replace hardware as well as software to support queuing
–Find an alternative mechanism for that part of the network
–Find an alternative mechanism and use it instead of queuing
–Evaluate the consequences of not implementing the required feature in that part of the network

Add a note here The summary report conclusions should identify the existing infrastructure’s shortcomings. In Example 2-5, QoS congestion management (queuing) is required. However, the designer has identified that Cisco IOS software version 12.0 does not support the newest queuing technologies. In addition, some routers do not have enough RAM and flash memory for an upgrade.

Add a note hereSummary report recommendations relate the existing network and the customer requirements. These recommendations can be used to propose upgrading of hardware and software to support the required features or modifying the customer requirements. In this example, options include evaluating the necessity of the queuing requirement in the WAN.

Add a note here Creating a Draft Design Document

Add a note hereAfter thoroughly examining the existing network, the designer creates a draft design document. Figure 2-17 illustrates a draft design document’s index (not yet fully developed), including the section that describes the existing network. The “Design Requirements” and “Existing Network Infrastructure” chapters of the design document are closely related—examining the existing network can result in changes to the design requirements. Data from both chapters directly influences the network’s design.

Image from book
Add a note hereFigure 2-17: Draft Design Document Index

Add a note here Typical draft documentation for an existing network should include the following items:

  • Add a note hereLogical (Layer 3) topology map or maps. Divide the topology into network modules if the network is too large to fit into one topology map.

  • Add a note herePhysical (Layer 1) topology map or maps.

  • Add a note hereThe network audit results, including the types of traffic in the network, the traffic congestion points, the suboptimal traffic paths, and so on.

  • Add a note hereA summary section describing the major network services used in the existing network, such as Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and Internet Protocol Security (IPsec).

  • Add a note hereA summary description of applications and overlay services used in the network.

  • Add a note hereA summary description of issues that might affect the design or the established design requirements.

  • Add a note hereA list of existing network devices, with the platform and software versions.

  • Add a note hereConfigurations of existing network devices, usually attached as either a separate document or an appendix to the design document.

Add a note here Time Estimates for Performing Network Characterization

Add a note hereThis section provides some guidelines to estimate how long it may take to characterize the network. The time required to characterize a network varies significantly, depending on factors such as the following:

  • Add a note hereThe experience of the network engineer

  • Add a note hereThe quality of documentation provided by the customer and the quality of the communication with the customer

  • Add a note hereThe size and complexity of network

  • Add a note hereThe efficiency of network management and discovery tools

  • Add a note hereWhether or not the network devices are carefully managed via SNMP

  • Add a note hereHow much information is needed for the scope of the project

Add a note here Figure 2-18 provides a range of time estimates, in hours, for the characterization of networks in a variety of sizes. These estimates assume a highly skilled (Cisco Certified Internet Expert level) network engineer with efficient automated tools for network discovery and performance gathering, and a network in which the devices communicate with SNMP. The network characterization includes strategic evaluation and possible network redesign.

Image from book
Add a note hereFigure 2-18: Network Characterization Estimates (in Hours)

Add a note hereThe steps in Figure 2-18 are as follows:

  1. Add a note hereInterviewing the management team to gather goals and constraints.

  2. Add a note hereInterviewing the network team, and gathering goals, constraints, documentation, and diagrams.

  3. Add a note hereReviewing documentation and diagrams, and clarifying items with the site team.

  4. Add a note hereSetting up the network discovery tool, which typically involves using automated discovery or entering a device list or IP address range into the tool; verifying that the tool has found most routers and switches; and starting to collect performance data.

  5. Add a note hereResolving SNMP access and similar problems if devices have not been very carefully managed in the past.

  6. Add a note hereAllowing the discovery tool to gather data. The time for this step will vary depending on network, and should include seasonal or cyclical factors, but generally one week of data is sufficient. The network engineer typically does not need to oversee this process.

  7. Add a note here Analyzing the captured data; minimizing the time required is dependent on using efficient tools.

  8. Add a note herePreparing high-level (Layer 3) diagrams of the proposed network.

  9. Add a note herePreparing the report of conclusions and recommendations.


Note

Add a note hereThese estimates do not include the time needed to prepare detailed network diagrams if the customer does not supply them.

Add a note hereConsequently, network characterization typically takes from one to many weeks of effort, depending on the size and complexity of the network and the other factors mentioned at the beginning of this section.


Using the Top-Down Approach to Network Design

Add a note hereAfter establishing the organizational requirements and documenting the existing network, the designer is ready to design a network solution. This section first discusses the top-down approach to network design. Decision tables and structured design are described, and the section includes a brief discussion of the types of network design tools that might be used. The section concludes with a discussion about building a pilot or prototype, and the contents of a detailed design document.

Add a note here The Top-Down Approach to Network Design

Add a note hereDesigning a large or even medium-sized network can be a complex project. Procedures have been developed to facilitate the design process by dividing it into smaller, more manageable steps. Identifying the separate steps or tasks ensures a smooth process and reduces potential risks.

Add a note hereA top-down design allows the designer to “see the big picture” before getting to the details. Top-down design clarifies the design goals and initiates the design from the perspective of the required applications. The top-down approach adapts the physical infrastructure to the needs of the applications. Network devices are chosen only after a thorough requirements analysis. Structured design practices should be integrated with the top-down approach, especially in very complex networks.

Add a note hereIn contrast to top-down design, the network design approach in which network devices and technologies are selected first is called bottom-up, or connect-the-dots. This approach often results in an inappropriate network for the required services and is primarily used when a very quick response to the design request is needed. With a bottom-up approach, the risk of having to redesign the network is high.

Add a note here Guidelines for producing a top-down design include the following:

  • Add a note hereThoroughly analyze the customer’s requirements.

  • Add a note hereInitiate the design from the top of the OSI model. In other words, define the upper OSI layers (application, presentation, and session) first, and then define the lower OSI layers (transport, network, data link, and physical)—the infrastructure (routers, switches, and media) that is required.

  • Add a note hereGather additional data about the network (protocol behavior, scalability requirements, additional requirements from the customer, and so forth) that might influence the logical and physical design. Adapt the design to the new data, as required.

Add a note here Top-Down Approach Compared to Bottom-Up Approach

Add a note hereA top-down approach to design has many benefits compared to a bottom-up approach, including the following:

  • Add a note hereIncorporating the customer organization’s requirements

  • Add a note hereProviding the customer and the designer with the “big picture” of the desired network

  • Add a note hereProviding a design that is appropriate for both current requirements and future development

Add a note hereThe disadvantage of the top-down approach is that it is more time-consuming than the bottom-up approach; it necessitates a requirement analysis so that the design can be adapted to the identified needs.

Add a note hereA benefit of the bottom-up approach—selecting the devices and technologies and then moving toward services and applications—is that it allows a quick response to a design request. This design approach facilitates designs based on the designer’s previous experience.

Add a note hereThe major disadvantage of the bottom-up approach is that it can result in an inappropriate design, leading to costly redesign.

Add a note here Top-Down Design Example

Add a note hereConsider an example that uses the basics of the top-down approach when designing an IP telephony network solution. In this example, the customer requires a network that can support IP telephony. IP telephony permits the use of the same network resources for both data and voice transport, thus reducing the costs of having two separate networks. To achieve this, the network must support Voice over IP (VoIP) technology; this first step in the design process is illustrated in Figure 2-19.

Image from book
Add a note hereFigure 2-19: A Voice over IP Network Is Required for IP Telephony

Add a note here Figure 2-20 illustrates the addition of an IP-based network, which is required to support VoIP. The network includes IP-enabled routers and other devices not shown in the figure. The IP network’s delay is also managed; to achieve this, specific QoS mechanisms are also implemented in the network, as indicated in Figure 2-20.

Click to collapse
Add a note hereFigure 2-20: IP and QoS Are Required for VoIP

Add a note here Figure 2-21 illustrates the addition of the call monitoring and management function. This function was previously overlooked because such functions were traditionally handled by a PBX on a separate voice network; during the top-down design, it became clear that this function is necessary. A Cisco Unified Communications Manager is therefore placed inside the network to manage and monitor IP telephone calls.

Click to collapse
Add a note hereFigure 2-21: Cisco Unified Communications Manager Is Required for Monitoring and Managing VoIP Calls

Note

Add a note hereCisco Unified Communications Manager is a server-based application that establishes and maintains signaling and control for IP telephone sessions.

Add a note hereIP telephony is described further in Chapter 8, “Voice Network Design Considerations.”

Add a note here Decision Tables in Network Design

Add a note here Decision tables are used for making systematic decisions when there are multiple solutions or options to a network issue or problem. Decision tables facilitate the selection of the most appropriate option from many possibilities and can be helpful for justifying why a certain solution was chosen. Options are usually selected based on the highest level of compliance with given requirements. Basic guidelines for creating a network design decision table include the following:

Add a note here Step 1

Add a note hereDetermine the network building block about which decisions will be made (the physical topology, routing protocol, security implementation, and so on).

Add a note here Step 2

Add a note hereCollect possible options for each decision. Be certain to include all options (or as many as possible) to obtain maximum value from the decision table. A thorough survey of the existing state of technology and considerable knowledge are needed to include all options.

Add a note here Step 3

Add a note hereCreate a table of the possible options and the given requirements. Include the relevant parameters or properties.

Add a note here Step 4

Add a note hereMatch the given requirements with the specific properties of the given options.

Add a note here Step 5

Add a note hereSelect the most appropriate option—the option with the most matches—if all requirements are treated equally. However, if some requirements are considered more important than others, implement a weighting system such that each of the requirements is assigned a weight that is proportional to its importance in the decision-making process.

Add a note here Figure 2-22 is an example of a decision table for selecting a routing protocol based on multiple criteria. In this example, several routing protocols are considered as possible options: OSPF, Intermediate System–to–Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP), and BGP. Five required parameters are listed, along with an indication of how well the routing protocols comply with these parameters. As indicated in the figure, the chosen protocol should include the following properties:

  • Add a note hereIt should support a large network. All the protocols being considered meet this requirement.

  • Add a note hereIt must be Enterprise-focused, rather than Internet service provider–focused. BGP was designed to support interconnecting networks of autonomous systems; it is not optimized for use in the enterprise. IS-IS is typically deployed in service provider environments, rather than in enterprises.

  • Add a note hereSupport for variable-length subnet mask (VLSM) is required. All the protocols being considered support VLSM.

  • Add a note hereIt must be supported on Cisco routers, which is the case for all the protocols being considered.

  • Add a note hereNetwork support staff should have a good knowledge of the chosen protocol to enable them to troubleshoot the network. In this case, the network support staff are knowledgeable about EIGRP, but not about OSPF, IS-IS, or BGP.

Image from book
Add a note hereFigure 2-22: Sample Decision Table for Routing Protocol Selection

Note

Add a note hereAll requirements in this example have the same level of importance, so no weights are used.

Add a note hereBased on the stated requirements, EIGRP is the routing protocol of choice in this example.

Add a note here Structured Design

Add a note here The output of the design should be a model of the complete system. The top-down approach is highly recommended. Rather than focusing on the network components, technologies, or protocols, instead focus on the business goals, technical objectives, and existing and future network applications and services.

Add a note hereStructured design focuses on a systematic approach, dividing the design task into related, less complex components, as follows:

  • Add a note hereFirst, identify the applications needed to support the customer’s requirements.

  • Add a note hereNext, identify the applications’ logical connectivity requirements, with a focus on the necessary infrastructure services and network infrastructure.

  • Add a note hereSplit the network functionally to develop the network infrastructure and hierarchy requirements.


    Note

    Add a note hereThis book uses the Cisco Enterprise Architecture to provide consistent infrastructure modularization, as described in Chapter 3.

  • Add a note hereDesign each of the functional elements separately, yet in relation to other elements. For example, the network infrastructure and infrastructure services designs are tightly connected; they are both bound to the same logical, physical, and functional models. Use the top-down approach during all designs.

Add a note hereAfter identifying the connectivity requirements, the designer works on each of the functional module’s details. The network infrastructure and infrastructure services are composed of logical structures. Each of these structures (such as addressing, routing protocols, QoS, security, and so forth) must be designed separately, but in close relation to other structures, with a goal of creating one homogenous network.

Add a note hereSome logical structures are more closely related than others. Network infrastructure elements are more closely related to each other than to infrastructure services, and infrastructure services are more closely related to each other than to network infrastructure elements. For example, physical topology and addressing design are very closely related, whereas addressing and QoS design are not.

Add a note hereSeveral approaches to physically structuring a network module exist. The most common approach is a three-layer hierarchical structure: core, distribution, and access. In this approach, three separate, yet related, physical structures are developed instead of a single, large network, resulting in meaningful and functionally homogeneous elements within each layer. Selecting the functionality and required technologies is easier when it is applied to separate structured network elements than when it is applied to the complex network.


Note

Add a note here Chapter 3 discusses the hierarchical model in detail.

Add a note here Figure 2-23 is an example of how a network design can be divided into smaller, yet related sections using structured design practices.

Click to collapse
Add a note hereFigure 2-23: Structured Design Example

Add a note hereIn this example, network infrastructure design and infrastructure services design are tightly connected; both are bound to the same logical, physical, and functional models. These elements are subdivided logically. The network infrastructure design is subdivided into physical topology design, addressing design, routing design, and technology selection. The infrastructure services design is subdivided into QoS design, security design, and multicast design. All design phases use the top-down approach.

Add a note here Network Design Tools

Add a note here Several types of tools can be used to ease the task of designing a complex modern network, including the following:

  • Add a note here Network modeling tools: Network modeling tools are helpful when a lot of input design information (such as customer requirements, network audit and analysis results, and so on) exists. Network modeling tools enable modeling of both simple and complex networks. The tools process the information provided and return a proposed configuration, which can be modified and reprocessed to add redundant links, support additional sites, and so forth.

  • Add a note here Strategic analysis tools: Strategic analysis or what-if tools help designers and other people who are working on the design (engineers, technologists, and business and marketing professionals) to develop network and service plans, including detailed technical and business analysis. These tools attempt to calculate the effects of specific network components through simulated scenarios.

  • Add a note here Decision tables: As discussed, decision tables are manual tools for choosing specific network characteristics from multiple options, based on required parameters.

  • Add a note here Simulation and verification tools or services: These tools or services are used to verify the acquired design, thereby lessening the need for a pilot network implementation.

Add a note here Figure 2-24 illustrates how the initial requirements information is processed with network design tools to produce a network design.

Click to collapse
Add a note hereFigure 2-24: Using Network Design Tools

Add a note here To verify a network design that was produced with the help of network modeling tools, strategic analysis tools, and decision tables, either use simulation and test tools or build a pilot or prototype network. The pilot or prototype network also creates a proof of concept that confirms the appropriateness of the design implementation plan.

Add a note here Building a Prototype or Pilot Network

Add a note hereIt is often desirable to verify a design before implementation. A design can be tested in an existing, or live, network—this is called a pilot—or, preferably, in a prototype network that does not affect the existing network. A successful design implementation in either a pilot or prototype network can be used as a proof of concept in preparation for full implementation and can be used as input to the implementation steps.

Add a note hereIt is important that the pilot or prototype test the design, including the customer’s most important stated requirements. For example, if a key requirement is minimal response time for remote users, ensure that the prototype or pilot verifies that the maximum acceptable response time is not exceeded.

Add a note hereA prototype or pilot implementation can have one of two results:

  • Add a note here Success: This result is usually enough to prove the design concept.

  • Add a note here Failure: This result is normally used to correct the design; the prototype or pilot phase is then repeated. In the case of small deviations, the design can be corrected and tested in the prototype or pilot network immediately.

Add a note here Figure 2-25 is a sample topology subset of a planned network. The highlighted areas indicate the parts of the network involved in a redesign. This part of the topology is implemented first in a prototype to verify the design.

Click to collapse
Add a note hereFigure 2-25: A Prototype Network

Add a note here Documenting the Design

Add a note here A design document lists the design requirements, documents the existing network and the network design, identifies the proof-of-concept strategy and results, and details the implementation plan. The final design document structure should be similar to the one in Figure 2-26, which includes the following:

  • Add a note here Introduction: Every design document should include an introduction to present the main reasons leading to the network design or redesign.

  • Add a note here Design requirements: Also a mandatory part of any design document, this section includes the organization’s requirements and design goals that must be fulfilled.

  • Add a note here Existing network infrastructure: This section is required only for a network redesign. The subsections document the results of the existing network characterization steps.

  • Add a note here Design: This section is an essential part of the design document and identifies the design and implementation details. The design details documented will obviously differ depending on the type of design project (whether it is a completely new network, a network redesign, or simply a new service introduction, for example), but they typically include the topology, addressing, and design. Implementation details, such as configuration templates and exact configurations of network devices, are included to ease the implementation process.

  • Add a note here Proof of concept: This section describes the pilot or prototype network verification and test results.

  • Add a note here Implementation plan: This section provides the implementation details that technical staff need to carry out as quickly and smoothly as possible, without requiring the presence of the designer.

  • Add a note here Appendixes: The appendixes usually include lists and, optionally, configurations of existing network devices.

Click to collapse
Add a note hereFigure 2-26: Sample Design Document


0 comments

Post a Comment