This chapter presents some of the key techniques and methods that an analyst should use when performing a network baseline study. By following these high-level steps, you can ensure the successful completion of a network baseline in both a reactive and a proactive environment.
A network baseline project includes three main stages:
Stage 1. . Data-acquisition and baseline-study planning
Stage 2. . Data acquisition and active network baselining
Stage 3. . Composing and building the network baseline report
For a network baseline program to succeed, an analyst must proceed carefully through these three stages.
Stage 1 is the data-acquisition planning phase—the initial front end of the project. If any one area requires 100% accuracy and thoroughness in terms of detail, it is the step of composing the initial network baseline plan. If key items are properly reviewed and processed, a thorough and technically competent baseline data-acquisition plan can be developed and the final network baseline results for reporting obtained. This chapter identifies the specific steps required when planning a network baseline.
After the initial baseline data-acquisition plan has been composed, the next stage is the actual baseline data acquisition, Stage 2. This active network baseline process is guided by the baseline data-acquisition planning cycle. This is why it is so critical that the first stage of planning the study be 100% accurate and complete.
When an analyst is performing active data acquisition, he must perform many separate steps to ensure that the proper data is captured from the specific network analysis monitoring points. Note that many of these steps must be followed exactly.
After an analyst has completed the data-acquisition process, he starts the final process, Stage 3. In this stage the analyst moves to final network baseline reporting. During the reporting process, an analyst must thoroughly review all the materials (documentation and data) gathered during the baselining process. The analyst must carefully correlate all the information to create a final network baseline report.
This discussion now turns to a detailed analysis of each stage's required steps. Each step is critical to achieving the goal of creating a comprehensive, on-target, and technically competent network baseline report. Figure 13.1 shows the main overall steps required when network baselining.
As stated earlier, the project plan (also called the front-end network baseline planning session) is very critical. When developing a project plan, an analyst must take on the role of network detective, gaining a full understanding of the complete internetwork architecture relevant to the network baseline study. Every network is composed of disparate network topologies and protocols that comprise the complete network architecture.
Consider, for instance, a network using the Ethernet topology and Windows NT for an operating system. Compare that network to a network using Ethernet for the topology but using Novell NetWare for an operating system. These two networks have two different network architectures. Therefore, an analyst must be prepared with a network analyzer that can study the Ethernet topology from a physical layer standpoint and also be able to study the network layer, transport layer, and other key layers (such a the application layer) from a protocol-decoding perspective.
That said, and it merits repeating, an analyst must understand the internetwork architecture. To do so, an analyst must engage in a project entrance briefing with all key technical personnel who support the network baseline process. In some cases, an analyst may have to review other areas of the network life cycle (problem history, past migrations, future directions, and so on).
Early on during the planning stage, the analyst must review another key area: application deployment. Specifically, such a review is vital because the applications deployed throughout the network may be applied to both the servers and the user workstations that engage the applications.
During the data-acquisition planning stage, an analyst should start with an entrance meeting or briefing. In an entrance briefing, all the key members of the network support team should be present to review the internetwork configuration, symptomatic history, and migration issues, along with application and user profiles. In this type of meeting, a network baseline analyst should take the lead and ask a series of questions regarding the key information required to create a network baseline plan.
The first area of review is the network configuration. An analyst should closely study the internetwork topology by reviewing network diagrams available at the facility (including both LAN and WAN topology diagrams). An analyst should review the types of hubs, switches, routers, and other key devices that provide the actual interconnection and passthrough routes of the topology from a LAN and a WAN perspective.
Certain configuration and operational profiles of main devices, such as switches and routers, may be required throughout the baseline study. An analyst should inventory the total node count along with the actual file server count within the facility.
Next an analyst must understand the type of network operating systems and the placement of key server resources throughout the facility. It is important to understand whether the site is using a distributed or centralized design or both.
After the previously discussed information has been gathered, an analyst should next confirm such details as the cabling layout and other specific items, such as workstation hardware configurations and other details related to the network's physical architecture.
Next the analyst must focus on the workstation. The analyst must understand workstation configuration including such information as software shells, operating shells, application profiles, and other details that relate to the configuration and usage of the workstations. It is also important to understand how the workstations and servers intercommunicate across the network infrastructure.
As the entrance briefing continues, the analyst must next review the network's problem history. An analyst must thoroughly understand the symptomatic history. It is helpful to review network server problem logs, device problem logs, and any Help Desk logged calls that took place in the facility. Key members of the network support staff may hold valuable information. By interviewing specific members of the network staff, a network baseline analyst may be able to understand the symptoms and problems that thread throughout the history of the internetwork's evolution.
During the entrance briefing, the analyst should ask about any recent migrations (recent meaning during the past calendar year at the facility, for instance). These would include topology migrations as well as such things as application deployment. The analyst should also take a close look at the planned migration direction for the next calendar year (and possibly even beyond that), to understand how the internetwork may evolve in the near future. Such information enables the analyst, when baselining the network, to possibly obtain data that may assist with fine-tuning the final network migration direction.
An analyst should closely review all main application types deployed at the facility. A network baseline analyst should attempt to understand the general user types as well as the types of applications each user uses on a specific PC. Different user profiles may emerge. One user might use just a word processing application and a general email program, for example. Another user might engage a word processing program along with a high-end application, such as a computer-aided design (CAD) drawing application. These two users fit two different user profiles.
After having completed the question-and-answer session with the appropriate network parties, an analyst will gain an initial grasp on the overall internetwork configuration as it currently stands, its problem history, and the anticipated direction for the network. The analyst should also have a handle on the applications currently deployed at the facility as well as some idea regarding the projected future deployment of applications.
From the information discussed throughout this section, the analyst can begin to develop a network project plan. The network project plan must include a full planning stage, during which an analyst chooses specific network analysis monitoring points and uses network analysis tools that will enable the analyst to achieve the network baseline goals.
The final project plan may vary, depending on whether the network baseline study is a proactive study or a reactive study. A proactive study refers to a network baseline study being performed on a network that is not having any major problems. A reactive study refers to a network baseline study being performed on a network that is experiencing problems at the time of the study.
The following section discusses how to develop your project plan.
After the entrance briefing has concluded the analyst should completely understand the internetwork configuration, symptomatic history, and migration direction. The analyst should also have application profiles (deployment and actual user profiles). The final data-acquisition project plan is the next focus of the study.
Before just deploying network protocol analyzers and monitoring equipment, an analyst should understand the types of sampling points necessary to effect relevant data capture with the protocol analyzers positioned throughout the network. An analyst must also understand the sampling time periods necessary to achieve the data capture results for the baseline study.
An analyst must develop a network baseline plan that fits the requirements of the particular internetwork being sampled. An analyst might be called on, for example, to examine areas of the network that are experiencing problems.
In this type of situation, an analyst may decide to immediately deploy network analysis tools in that specific area. (This is an example of being reactive.) Figure 13.2 shows a protocol analyzer positioning process in a network baseline study.
In a proactive situation, an analyst may decide to move through the network in a more proactive way and develop a plan that applies to the specific network to ensure that key areas are sampled. An analyst may also decide to develop a sampling session that captures certain application traffic, as required.
Consider this reactive analysis baseline scenario: An analyst is studying a two-segment Ethernet network with approximately 200 users. One main segment is connected through a router and holds a main file server that is having connectivity issues and provides services to the complete site user domain. As noted, the specific file server within the facility appears to have connectivity issues during certain high traffic loads (noted through user complaints). Another server on the same segment is not having any problems. The analyst could develop a network positioning plan to perform a simple network baseline study on both segments, (1) and (2). This would enable the analyst to develop a background baseline view of each main segment, (1) and (2).
The analyst could then study the server for key workload characterization measurements and then focus on details, such as server delta response time and actual file transfer throughput. The analyst could then also study the server that is not having any problems and perform a comparison of the two servers. By reviewing the measurements as well as the proper server documentation, an analyst may then be able to isolate a problem within the server. The issues may relate to the server's network operating system configuration or its hardware build. Software application balancing may also be causing the site connectivity issues.
This preceding network baseline example shows how a baseline project plan could lead to a rapid baseline with a brief sampling session on segments (1) and (2). The problem could be further resolved through cause isolation analysis and close sampling of the problem server.
Consider this proactive analysis baseline scenario: A Token Ring network has a 16Mbps Token Ring backbone. The Token Ring backbone is connected to three user Token Rings running at 16Mbps and uplinked through a Token Ring–switched layout design. If the site experiences no problems, the analyst should plan a full network baseline sampling session on all four main rings, including the backbone. Each ring should then be sampled using standard workload characterization measurements, such as utilization, node-by-node utilization protocol percentages, physical Token Ring error measurements, along with Token Ring MAC review.
The analyst could then proceed to an upper-layer protocol review and study throughput and latency measurements among all the rings. Specific workstations could be sampled for their response time when communicating with certain servers on the backbone ring. Certain servers could also be sampled for their interpacket delta response time on the main backbone ring and how they respond back to the user ring. Application characterization tasks could be run, in which an analyst captures an application on each one of the main subrings for certain user profiles and then closely reviews how applications perform on the subrings when communicating to the servers on the backbone ring. This process generally applies to a proactive study. This type of project planning approach could be applied to a small network with 100 nodes or a large complex internetwork with 5,000 nodes.
The key point is that network analysis positioning is critical, along with network baseline sampling time.
In a proactive study, the network baseline sampling time might spread over a period of a normal business timeframe, such as eight hours for each Token Ring. This type of case presents an example of a proactive view.
In a reactive situation, an analyst may have to adjust the sampling time to a shorter time period to resolve the network issues. In the first example earlier in this chapter, for example, an analyst may have to review the Ethernet segments briefly on a rapid baseline approach for no more than one hour on each segment. The analyst could then troubleshoot the servers on a brief one-hour sample per server. Quite possibly, the issues could be resolved within one business day. Figure 13.3 shows the key steps of the project plan.
These were just two brief examples of project-plan processes that an analyst can use during the network baseline planning stage.
The discussion now turns to a description of the actual data-acquisition process, Stage 2.
When performing a network data-acquisition process an analyst must keep in mind that the statistical sampling process of the overall network study is critical. It is important to develop a rapid understanding of what is wrong with the network and to develop a set of recommendations and create a focused written report. That said, it is also important to understand that it may be necessary to extract certain quantitative statistical measurements to create the necessary graphs or statistical printouts or associated technical data trace printouts to support the findings in a network baseline report.
Many talented network designers, implementers, and analysts can very quickly assess a network issue and develop a report on a network problem. Any report most likely includes a discussion of the network symptomatic problem, a technical synopsis, and an applied recommendation. Through network baselining, an analyst can utilize specific sampling measurements to develop quantitative technical result documents that can support the findings discussed in a baseline report.
An analyst managing a complete network on a day-to-day basis must understand, from a project management perspective, that statistical analysis is crucial to support the final baseline report. In a proactive network or a reactive network baselining process, an analyst must understand which statistics need to be sampled.
In a proactive study, for instance, measurements should be taken on every network area. These measurements include standard measurements (discussed in Chapter 4, "Quantitative Measurements in Network Baselining," and Chapter 5, "Network Analysis and Optimization Techniques" ). Some of these measurements include statistics, such as utilization for average and peak transitions, along with node-by-node utilization and protocol percentages. Error statistics are critical on a per-device basis along with physical traffic associated with certain topologies. Upper-layer protocol statistics as related to timing metrics are critical. This includes measurements to mark metrics, such as the delta time differences and latency between different network segment areas, along with throughput between different segment areas. The main file server and host internetwork response times are also important measurements.
An analyst must take these measurements carefully and develop statistics for quantitative measurement support that he can attach to the final network baseline report. An analyst must always understand that these statistics are going to support the final findings. When performing a network baseline study, an analyst must use an intuitive process to decide which statistics are critical and should be developed for reporting after sampling a certain area. Assume, for example, that an analyst is performing a network sampling session on an Ethernet segment and a high number of physical errors shows up in the initial trace results. The analyst should print the physical trace error results for quantitative statistical support and should attach the results to the final network baseline document.
Other valuable attachments to the final report include network baseline graphs that show, for instance, a high average and a high peak-utilization level.
When performing upper-layer protocol analysis on an Ethernet segment, for example, a high number of low effective throughput conditions are detected. The analyst determines that certain types of file transfers cause the event. The analyst can then develop a printed version of file data output that relates to this concern. The output can include printouts of the low effective throughput statistics along with detailed technical printouts of the files opened and closed during the low throughput occurrence. The analyst can also correlate these low throughput events with the high peak saturation utilization that appears on a graph printed prior to the review of this area.
When completing this stage, the analyst usually has many sets of attachments. The graphs, for example, might support the findings that the particular Ethernet segment is oversaturated and is showing low throughput and high utilization. The attachments represent how application loading is causing low throughput and negative performance on other applications and also affecting the physical Ethernet layer. In this particular case, the analyst develops a technical write-up on the capacity-loading situation that provides a synopsis of the occurrence and also recommends to either partition the Ethernet segment or to introduce switched Ethernet architecture. In this case, the analyst can supplement the network baseline report with all the statistical printouts, such as utilization graphs, physical statistic graphs, effective throughput statistics, and file detail open and close technical printouts for the file movement that caused the utilization peak.
The preceding example shows how critical the data-acquisition statistical mode is to a final network baselining process.
In summary, an analyst must understand that the network baseline data- acquisition stage involves the following key analysis steps:
Engaging key analysis positioning and capturing points against the topology in the applied architecture.
Establishing and moving toward a goal during each particular network analysis session in the complete network baseline study.
Ensuring that the proper analysis and management tools are deployed, properly configured, and set up to gain the required statistics.
Recording the proper workload statistics and developing technical output reports for graphs, charts, and technical printouts, as required.
Performing a detailed review of all data gathered in the analysis session, and recording all final baseline information as well as other data including quantitative measurement supports, and ensuring that the data is saved to a proper file for future review.
Figure 13.4 displays the key steps in data acquisition.
The following section shows how an analyst can produce a final report that accurately represents the output of a network baseline study.
When composing the final network baseline report, an analyst must keep in mind that many issues need careful review.
Of primary concern, and to be identified at the outset, is the network baseline report's intended audience. If the network baseline report is to be submitted to a group of technical individuals who just need the main technical information, the report can be developed in a short and to-the-point status memo approach. If the network baseline is required for an annual baseline study that is going to be considered a blueprint for the direction of the internetwork for the future, a comprehensive network baseline study may be required.
Having grasped an understanding of the audience, the analyst can then guide the overall network baseline composition and writing process to ensure that the audience receives the relevant information from the network baseline study results.
Certain steps must be followed when preparing to develop a final network baseline report, including the following:
Problem issue identification and extraction
Technical synopsis development
Recommendation threading
Quantitative baseline data-measurement attachment development
The following subsections briefly discuss these steps.
When an analyst starts to perform the final off-site network baseline reporting-building process, he should first determine whether any issues are considered problems at the site. An analyst can start this process by closely reviewing all the trace files taken from the network baseline stage. The network baseline traces need to be closely reviewed from an internal perspective. The data must be closely reviewed by cross-reading certain trace information from different sessions. It is important to identify problem issues that relate to workload characterization measurements or physical issues, or associated upper-layer protocol issues that may be identified in the study. As any problems are identified, an experienced analyst starts to very carefully extract the issues involved (even keeping a "running issue list"). Each issue should be identified as a problem in a specific trace session.
Any trace that has a problem should be documented along with the area of the trace that shows the problem. An analyst can extract the issues by producing a technical printout of the finding. (As mentioned earlier and as shown here, the analyst must make and keep for future reference technical printouts during the data-acquisition stage.) After the analyst has identified the problem issue, he should list it in a network baseline outline draft of the final report.
The discussion now turns to how an analyst can develop a technical synopsis from the issues identified and extracted from a network baseline session.
After the issue has been identified, the analyst must develop a technical synopsis of the problem. As the analyst moves through all the network baseline data for all sessions sampled, eventually a complete list of problem issues emerge; these require a synopsis and applied recommendation.
As noted, an analyst should start the network baseline reporting process by developing a network problem "running issue list." The issue list will most likely consist of network problematic circumstances that occur at the physical, network, transport, or application layer. Any identified issues will most likely be developed on a per-session extraction basis. In other words, the analyst pulls the issues from each separate session as part of a complete network baseline study. In this case, for example, if three segments were studied there may be three separate sets of issues.
The analyst should next perform a cross-review of all separate issue lists and try to determine which issues cross-thread throughout the network baseline study and affect the complete internetwork being studied. Through this methodology, the analyst then can develop a synopsis on each major issue. Some of the issues may require only one synopsis discussion because they may affect multiple segments or multiple network areas. The key factor in this process of the network baselining stage is to next apply a synopsis to each identified technical issue. A baseline technical synopsis is defined as a technical review of a network problem's cause and effect. This is where an analyst discusses the actual cause as it relates to the symptomatic effect or network issue (problem) identified during the network baseline stage.
If a physical network problem exists, for example, an analyst can discuss the cause of the network problem as it relates to a failure of a certain type of NIC or an improper NIC driver. This is just one example of applying a technical synopsis to the actual problem event.
After each technical issue is reviewed, a synopsis should be applied. Then, any redundant technical issues and technical synopsis information should be combined for a simplified and streamlined problem issue list that has a technical synopsis applied to each main issue. From this point, the analyst must then move to the process of developing a recommendation for each technical issue.
In this process, an analyst must understand the internals of internetwork design, implementation, and support. This is where the network baseline process moves to the next level in terms of technical skill and knowledge. To provide a recommendation, the technical analyst writing the report must have a solid understanding of these key areas, along with a good understanding of the network analysis baseline results. Recommendations should be clear and technically concise and above all effective. An analyst must determine whether the recommendation is required for a short-term solution or a long-term solution approach so that immediate issues can be quickly resolved. This would mainly include those issues causing network problems. There may also be issues that are not causing major network outages that could be resolved through interim recommendations that involve migration steps, such as the addition/reconfiguration of major equipment, such as bridges, routers, switches, or the reconfiguration of a complete topology or architecture.
After all the issues have been reviewed and the synopsis information has been thoroughly detailed, the analyst should next apply a recommendation for each issue and associated synopsis. If any recommendations are redundant or related to cross-site events, these recommendations can be combined/related to other issues in the report, if required.
One final note: An analyst must ensure that all recommendations are clear and concise. The analyst should ensure that any recommendations requiring design specification or implementation be clearly identified in the network baseline report. This is important so that the network support team understands that such recommendations require immediate action. It is important that actual design specification and implementation planning be well thought out before recommendations are offered.
After the final report has been composed (that is, all the major issues have been identified and an associated technical synopsis has been applied), and final recommendations have been made, it may be necessary to back up the findings.
An analyst may need to attach proof to substantiate the technical network baseline issues and subsequent recommendations. Technical proof material is important because many support personnel may question the report because of the nature of certain recommendations (especially as to how they affect the internetwork). This is why statistical data acquisition is very important (during network baseline stage). If the project plan is correct and accurate, and the data-acquisition process is completed in a proper manner, the necessary quantitative statistical graphs and data printouts should be available to support any issues discussed in the main network baseline report. An analyst should carefully lay out a table of contents and appendix section of the report to ensure that the attachments support all the issues discussed in the report.
During the network baseline data-acquisition stage, many network attachments may appear to be redundant in nature and not required (graphs, technical trace printouts, and certain statistical screen printouts, for example). Other information may appear to be absolutely relevant to a specific issue discussed. This is where an analyst must apply his expertise and extract from the reporting site files all the printouts and graphs that support the network baseline discussions in the main body of the report. These attachments should be carefully referenced in the network baseline report and cross-referenced to their actual location as attachments.
The analyst may have to go back into the main body of the report and cross-reference the attachments to ensure a complete cross-reference between each technical issue and applied synopsis and recommendation, as well as an associated quantitative measurement statistical printout that supports the finding. This is a critical area of network baseline reporting.
In closing, a key point to mention here is that network baselining is not about producing a large number of graphs and technical printouts that show the overall statistics of the network. Instead, it is crucial for the network baseline report to be on-target from an issue, synopsis, and recommendation standpoint. In other words, the final network baseline report should provide a statistical review of the network sampling session from a workload baseline characterization standpoint for all critical layers, such as the physical, network, and application layer. This is important for each network baseline session sample in the overall network baseline study. When the report reflects all the key network issues and an applied technical synopsis and recommendations are brought forward, it is then time to confirm that the study also includes the proper quantitative measurement statistical printouts to support the findings.
A network baseline report should never be compiled based on just statistical graphs and technical printouts without the proper technical support information (that is, a discussion of the technical printouts within the report itself).
Many network baseline reports consisting of just a series of graphs and technical charts have been delivered in the industry. In such a case, a person reading the network baseline report may find no real value in the measurements if the actual issues are not properly discussed (from an issue, associated synopsis, and applied recommendation perspective).
Note also that if the report is written in a clear and concise fashion and the recommendations are accurate, it is still necessary to support the report with the proper quantitative statistical graphs and printouts in the attachment section.
Figure 13.5 shows the main steps in creating a network baseline report.
This book has presented the key principles and goals of a network baseline study. The early chapters of this book presented the major principles of network baselining. The book then moved to a discussion of the importance of ensuring that a network is stable, reliable, and performing at a high level. Some of the key network analysis tools that can be used in a network baseline study were also discussed. The book then presented extremely detailed information on workload characterization baseline measurements, network baseline process measurements, upper-layer protocol-decoding processes, and problem extraction techniques. Analysis techniques were discussed for network communication analysis along with application characterization. Detailed trace analysis techniques were also discussed. Next, the book moved to a discussion of how a network should be documented. That discussion included some of the key methods used to ensure that a network baseline is properly documented. Also included in this book are chapters with important information on network protocol architecture along with methods and techniques on how to analyze those protocols. Most major LAN and WAN topologies were presented from an architecture perspective with a focus on the technique to analyze and baseline the specific topology.
This closing chapter has discussed the methodology involved when performing a network baseline study along with the steps required to create and deliver a network baseline report.
With all the process methodology offered here, most technical individuals in the industry who are interested in this type of work should be able to eventually plan, perform, and complete their first network baseline against a specific architecture.
The subject matter presented in this book should prove extremely effective as long as all steps and methodologies presented throughout this book are followed properly.
At this point, I want to offer the reader "Best Wishes" in developing the skill set required to be a true network baseline analyst.
The "Art of Network Baselining" is considered a pinnacle area in the networking industry in terms of the technical scope of work involved. This is because an analyst must intimately understand internetwork architecture, design, implementation and support, and this critical process called network baselining!