The Current Network

With the discussion of Cisco’s framework behind us, let’s look at the customer’s existing network. Like it or not, most networks are not new networks but are updates of existing networks. Very few companies can afford to say, “Scrap everything.” They must carry some pieces of their existing network forward. Therefore, it is critical to first understand how the customer’s network is currently performing. Gaining an understanding of the customer’s current network gives you a starting point, a point of reference. This understanding is required later when discussing the customer’s needs. For example, when the customer tells you, “I want my new LAN to be faster and more secure,” you cannot understand exactly what he means unless you understand just how fast and secure his current LAN is. The customer gave you relative statements in saying “more secure” and “faster;” you must understand the customer’s current network in order to understand these statements.

You begin categorizing the customer’s current network by gathering data about it. This information is divided into two categories: administrative data and technical data. Administrative data is generally gathered from company management and includes information such as the company’s business goals, corporate structure, geographic locations, current and future staffing, and policies and politics that will affect the design of a new network. This information paints a picture of the corporate environment and helps identify business constraints (business issues, not technical issues, that will affect the final network design). Technical data is taken from the customer’s current network and can usually be gathered from the IS department or using network analysis tools (discussed in Chapter 11, “Network Management”). Technical data includes protocols in use, collision rates, broadcast rates, packet flows, segment utilization, and other network-related issues.

Administrative Data

Administrative data helps you to understand the workings of the company whose network you will be designing. Administrative data allows you to identify business constraints that may arise throughout the design and implementation processes. Business constraints are defined as any nontechnical item that will affect your final design. There are many types of administrative data you may wish to gather. The following list contains questions you might want to answer as you gather administrative data:

• Who will be your technical contact(s) within the company?

• Who will be involved in the design process, and how involved will they be?

• Who will approve your design?

• Is the company’s climate one of acceptance to change, or is there resistance to your changes?

• Has someone else tried and failed in this project?

• How does the company’s IS department feel about your involvement (assuming you are external to the company)?

• Who reports to whom? Who can override decisions made by your contacts?

• What are the company’s growth expectations? Will they be expanding significantly? Do they want to expand?

• How is their industry performing, and how are they competing in their industry?

• Where (geographically) are the users located?

• What are their staffing levels like?

• Once the new network is in place, who will run it? Does the company have internal personnel who are capable, or will they need training? Will they need to increase staffing to support the new network?

Gathering this data may present challenges, especially if there is any resistance in some parts of the company to the project. You will probably have to work with several different departments such as personnel, technology, management, and even Human Resources, to gather all of this information. However, gathering the administrative data is an important step that will pay significant dividends in your final design. At most, it will allow you to gain insight into the company’s vision and design a network that helps them attain their goals. At least, it will prevent you from stepping on the wrong toes as you complete your design process.

Technical Data

As the name implies, technical data has more to do with technology than administrative data. It helps you to better understand how the customer’s network is operating, and as explained earlier, this will help you understand the customer’s expectations. Technical data to be gathered on the customer’s network includes the following:

• Analyze the current network for media problems. Media problems are caused by too many devices sharing a network segment (collision domain). Symptoms include high latency and difficulty in accessing services.

• Analyze the protocols being used in the current network. Are they appropriate to the scale of the network? Some protocols are fine for small networks, but as the network grows and becomes increasingly more complicated and segmented, these protocols do not scale well.

• Take inventory of which networked applications are currently being used and what applications the customer plans on implementing or migrating to in the future.

• Examine the information flows within the company. What paths do information flows such as e-mail, database access, etc., use to cross the internetwork?

• Find out where shared data is located and who accesses it.

• Measure network traffic between segments. Is there data accessed from outside the network such as Internet resources?

As you can see, technical data focuses on Layer 3 technologies (IP, IPX, DDP, and routing) and on Layer 2 technologies (switching). The data gathered here will be categorized using Cisco’s Small- to Medium-Sized Business Solutions Framework, and from that point, problems will be identified and solved.

There are many tools available to help you gather this data. These tools include protocol analyzers, network management stations, and others. These tools are explained in detail in Chapter 11.

Now that we have discussed administrative and technical data and the differences between the two, let’s look at a road map that you can use to evaluate the state of the customer’s current network.

Design Methodology

Having a consistent, systematic approach for designing a network from the ground up or for modifying an existing network is essential to creating a viable network that truly meets the needs of those it’s going to service. You simply must have a concise methodology—an established set of steps to refer to for preventing wasted energy and time spent reinventing the wheel. A solid plan is a very good tool to have, but it’s also very important to be flexible. With that in mind, here are some basic precepts to follow that will help you avoid common pitfalls and problems and instill confidence in your work to those depending on the integrity of your design:

• Make sure all design steps are fully addressed.

• Make sure your network design is consistent to facilitate its implementation, maintenance, and optimization.

• Make sure your plan is concise and clear so that both managers and clients are able to understand that you’ve carefully thought out the network design structure to meet their needs.

• You must provide a realistic and solid framework to facilitate the design process for any and all involved.

With those concepts in mind, read through the following design methodology steps. Some of them relate directly to the design phase itself. Others relate indirectly, being relevant to one or more of the other PDIOO phases:

1. Know and understand the client’s exact requirements.

2. Map the client’s existing network.

3. Determine the viable network solutions or topology design.

4. Plan the actual implementation.

5. Create the model network.

6. Write it all down.

7. Implement and verify the actual design.

8. Look, listen, and learn.

Let’s look at each of these steps in great detail.

Know and understand the client’s exact requirements. This step is accomplished by mining all pertinent information from your client accurately and thoroughly; you do this during the PDIOO planning phase.

Map the client’s existing network. You only need to follow this step if your job is to redesign and/or upgrade a network that already exists. If that’s the case, network audits and network analysis are your best tools. Network auditing consists of testing and examining the existing network’s integrity, performance, and quite likely, its scalability as well. Network analysis deals with analyzing network behavior—the levels of traffic, congestion factors, etc.—and is ascertained during the PDIOO optimization phase.

Determine the viable network solutions or topology design. This is where you create the real-world model of the actual, working network that you intend to eventually implement. Decisions herein center upon specifying and determining the network infrastructure—the hardware and software, routing protocols, intelligent network services, QoS, physical topology, etc. Also highly relevant to this step are determining factors like network solutions such as Voice over IP (VoIP) and content networking. The information required to make these decisions accurately is acquired during the first two design methodology steps.

Plan the actual implementation. This is the time to prepare proper implementation procedures and delimit and clarify the design’s real cost assessment. Preparing this documentation in advance serves to facilitate and illuminate what the implementation will require in order for it to be actualized.

Create the model network. You really could skip this step, but it can be very useful for both you and your client. Having a prototypical model of the final product you’re proposing can prove highly useful in verifying why your design should actually be implemented. If you opt to create the model network, you should present it at the dawn of the PDIOO implementation phase.

Write it all down. Document the design. Yes—document that design! If you need help with this step, look over the section on implementing design methodology covered in Chapter 5.

Implement and verify the actual design. This is where you build the actual network you’ve designed and you test that design in a real-world environment in order to verify if it does in fact work as you planned it would.

Look, listen, and learn. You’ve built the design—does it fly? Here is where you get to see if the network you’ve designed and built really works. And if it doesn’t really work, at least you get a chance to monitor it, discover why, and fix it before anyone notices! Even good designs need tweaking sometimes, and this is the step where you monitor the network’s operation and check it for errors and potential issues. You troubleshoot and modify according to any probable or potential error you’ve discovered, hoping to avoid redesigning the entire network. But if your testing is proving so dismal that you’ll need to actually redesign the network, here’s where you’ll find that out—after the network is built and operational. Hopefully, this won’t be you, and in the worst case, you’ll just need to tweak things a bit!

Portraying the Current Network

Cisco recommends 12 items that should be inventoried in the customer’s current network. These 12 items will, in most cases, generate most or all of the administrative and technical data. The items to gather are

1. Existing applications

2. Existing network protocols

3. Network topology and addressing

4. Potential bottlenecks in the current network

5. Business constraints

6. Existing network availability

7. Existing network performance

8. Existing network reliability

9. Existing network utilization

10. Status of existing routers

11. Existing network management system(s)

12. Overall health of existing network

Let’s look at each of these items in more detail.

Existing applications The objective here is to itemize major applications in use by the customer. Understanding which applications are used where will allow you to map packet flow and better understand the customer’s expectations. For example, a customer LAN used to exchange large CAD drawings may require more bandwidth than a customer LAN used exclusively to exchange spreadsheets, even though both are file transfer operations.

Existing network protocols This list will give you a complete picture of protocols in use by your customer. This information will be invaluable in later design steps, as you plan for items such as routing protocols and network addressing. It is important to list each and every network protocol currently in use by the customer, including routing, routed, and bridged protocols.

Network topology and addressing You will want to construct a document called a high-level topology of the customer’s current network. This is a map that includes all major network segments, routers, bridges, switches, servers, and other devices. It does not have to be too detailed; the idea is to get the big picture of the overall network. This item can usually be obtained from the customer.

Consider Figure 4.2. Notice that the map presents the overall internetwork rather than focusing on details such as the type of hubs, the type of hardware used for the workstations and servers, WAN protocols, etc. Even the number of servers and workstations is approximated! This map will be used along with the customer’s requirements to create a new high- level topology map of the customer’s proposed network. Don’t worry, we’ll practice these maps and give examples of each later in this chapter when we do our case studies.

Figure 4.2: High-level topology map

Once you have the high-level topology of the customer’s current network, you can add addressing information. The idea is to identify anything that you might need later when designing the new network’s addressing scheme.

Potential bottlenecks in the current network When identifying bottlenecks, just measuring bandwidth utilization is not sufficient. It is important to understand the profile of traffic on each network segment. Whenever possible, use a protocol analyzer to identify local and non-local traffic on segments. This will help you identify three types of traffic:

• Traffic where both source and destination are local

• Traffic where either source or destination is local

• Traffic where neither source nor destination is local

Understanding what type of traffic exists on a network will help you later in your design.

Business constraints This is the point where you review the administrative data you have gathered. As mentioned, any network design in the real world involves many nontechnical administrative and political factors. As part of your evaluation of the customer’s current network, it is essential that you understand any of these factors that have influenced the current network design. Otherwise, a well-intentioned improvement on your part might result in unfortunate consequences. Gather any nontechnical data that will be relevant to your design. Make sure to get a full understanding of the company’s policies regarding technology. These would include naming standards, addressing standards, routing protocols, etc.

Existing network availability In order to understand the condition of the current network, gather statistics on network down time and the mean time between failure (MTBF). The MTBF is the average time between network outages, so the higher the number, the better. You may wish to document costs associated with down time, if available.

Existing network performance Network performance is a measure of latency between two network devices. When latency is high, deeper analysis is required to ascertain the cause of the latency. Remember the customer who wanted the “faster” network? By measuring existing network performance, you can discover what the customer means by “faster.” Select several critical hosts and servers and measure response times using a protocol analyzer.

Existing network reliability Network reliability is different than network availability. While network availability measures up time, network reliability measures error rates when the network is “up.” Even when networks are working, there are still transmission errors that occur. By measuring network reliability, you can discover potential problems with the existing network. This can be accomplished by using a tool such as a protocol analyzer or a network-monitoring or management tool to monitor each network segment. You may want to consider the following properties for a given segment over a 24-hour period:

• Number of frames

• Traffic (in MB) transmitted

• Number of CRC (cyclic redundancy checksum) errors

• Number of runts/giants (Ethernet)

• Number of collisions (Ethernet)

• Number of broadcast frames and multicast frames.

Existing network utilization You need to use a protocol analyzer to gather information on network utilization. You will want to collect data on total network utilization and gather a breakdown of information about each individual protocol on the segment.

Status of existing routers You may want to check out the overall health of the routers currently running on the network. Check for items such as media errors and CPU utilization and take note of memory utilization. This information will augment the data already collected on the media segments and will give you the additional insight about how well your routers are doing under the current load. This information will be important later in the design process as you consider routing protocols and routing equipment.

Existing network management system(s) Make a list of all network management tools being used and which platform they run on. Be sure to include version information and document items such as method of gathering data, devices managed, and reporting capabilities. Gather samples of any reports, maps, or output from the network management system. As with other issues, understanding the customer’s current system will help you better understand their expectations for their new network management system.

Overall health of existing network Once you have gathered all of the relevant information you need about the current network, you should be able to compose a fairly accurate picture of the health of the current network. Cisco has made some specific recommendations for potential warning signs. They include

• Ethernet segments should not exceed 40 percent network utilization.

• Token Ring segments should not exceed 70 percent network utilization.

• WAN links should not exceed 70 percent network utilization.

• Response time should be less than 1/10 of a second (100 milliseconds).

• Broadcasts/multicasts should not be more than 20 percent of overall traffic.

• On Ethernet, there should be no more than one CRC error per one million bytes of data on any network segment.

• No Cisco router CPU utilization should exceed 75 percent.