When performing a network baseline, an analyst should have a complete set of network documentation. Certain documents, such as a network topology drawing, prove extremely valuable to the network baselining or data-acquisition planning process. Documentation that specifies server configurations, router and switch configurations, operating system profiles, and protocol configuration details are also very valuable during the network baseline planning cycle.
An analyst must sometimes perform a network baseline session on a network that has not been documented properly. In this case, it is more difficult to plan the network baseline process because certain parameters—such as where to position network protocol analyzers or management systems for the network evaluation cycle—may not be clear.
More information regarding the data-acquisition planning process for developing a network baseline program appears later in this book. This chapter discusses the importance of network documentation as it relates to the process and program of network baselining.
A clear and accurate set of network documentation assists the analyst with the network baseline planning cycle, enabling the analyst to produce a more accurate network baseline final report. Note also that a properly performed network baseline study yields additional information upon completion that further augments or creates a more in-depth set of network documentation. In other words, by actually performing a network baseline study, you can extract additional information that enables you to update the network documentation for a particular internetwork.
The discussion now turns to some of the important facts related to network documentation when performing a network baseline study.
During a network baseline study, it is very common to encounter a physical network interface card (NIC) address or network layer address (such as an Internet Protocol [IP] address) that is not identified or noted within the network documentation. Quite often major network devices, such as switches or routers, are located in data-trace results. These devices might have been omitted from previous network topology diagrams or network layout documents.
It is important to always note these types of items during the network baseline process to ensure that you can refer to them at the end of the study to investigate problems and also to ensure that you can update the site network documentation after the final baseline process output.
When examining a specific enterprise internetwork with a large infrastructure, this is an important phase of the overall analytical procedure.
When examining protocol analyzer trace files, you might identify certain NIC or network layer addresses that do not directly correlate with the network documentation available prior to the network baseline study. If you follow the proper note-taking procedures (such as those discussed in the past several chapters) when paging through a data trace or a set of protocol analysis session results, you can most probably identify any key conflicts. In other words, you must log any addresses and server names not documented in the initial network documentation that you referenced prior to the study. You should log this information when performing the analytical procedures of reviewing or paging through the data trace.
Quite often after a large-site baseline study has been completed, several baseline sessions are cross-referenced from one large baseline study to identify a common thread such as a device or several devices that do not appear on the network diagram or in the documentation. Usually when this occurs, an analyst can contact the appropriate personnel within the network support division and attempt to identify the physical or network layer addresses identified in the trace analysis session as "not active on the network." Very possibly, the network support team won't be aware of the device addresses in question. You can further investigate the addresses by reviewing previous network documentation and then reviewing the data traces in more detail to identify the physical location of the devices within the internetwork. The analyst and the support personnel can work together as a team to identify these locations. This method often helps to locate devices that were missed during the compilation of the previous network documentation.
Under certain conditions, an undocumented address may also correspond to a network problem or event, such as a routing loop or a misconfigured server or switch on the infrastructure design. When this type of event occurs, it can be extremely beneficial to immediately update the network documentation. In certain cases, you may also need to reconfigure the network when events such as these take place.
Documenting the network is an important part of the network baseline cycle. Network documentation is vital to the network baseline process and, as noted, the process itself often yields information that you can use to update the final network drawings to make them more accurate and on-target and therefore more useful during future troubleshooting processes.
Poor network documentation can negatively affect an analyst's ability to rapidly troubleshoot a critical network problem.
If a physical router is placed on an internetwork in a direct parallel line with another physical router, for example, problems can occur. Assume, for example, that two routers are placed as exterior routers from a local area network (LAN) to a wide area network (WAN) location. The LAN is configured as an Ethernet LAN with approximately 10 segments in one main location. The original network documentation shows only one main physical router (Router A), which provides an exterior router separation between the interior LAN and the WAN for the rest of the corporation at this particular location. Upon trace analysis of the LAN, another router is identified (Router B) and its address noted. Router B does not appear in the current network documentation and support personnel don't know whether it's actually connected or active on the network. Further review of the trace analysis files shows two routers using different routing protocols and causing the routing tables to refresh more frequently than normal in each of the main routers.
If certain workstation devices throughout the internetwork with the multiple Ethernet segments on the local LAN are set up to use one router (Router A) as a default gateway to the WAN, problems can occur if the router tables refresh too frequently. This may cause a situation in which addresses cannot be located (a non-reliable network, as discussed earlier in this book). In this type of situation, an analyst could identify the address of the other router (Router B) that does not appear to match the network documentation received prior to the study. The analyst could contact the appropriate support personnel or router team, and work hand-in-hand with them to identify the newly located router. If the new router is found and placed directly in line with Router A, which was considered the main exterior router, it may be possible to reconfigure the new router (Router B) that was not previously documented or in place on the configuration (see Figure 6.1).
This may sound like an unusual problem—unlikely if a network design team is extremely thorough. In large internetwork infrastructures, however, it is quite common to encounter such situations. In this particular instance, immediate action could possibly be taken to remove the new router located through protocol analysis from the current configuration and place it in a different location within the LAN. After all, the router may be in place for a reason—such as a WAN link that is not part of the main WAN, but which may be a link to another company or a specific Internet link.
In this example, the newly identified router may have been purposely configured without a direct line to the main computer room, possibly to come off another Ethernet segment for some other reason. It may be possible to reposition the new router within the site design.
It is very possible that the second router could have two interfaces and one of the interfaces could be connected in line with the main exterior router, as noted. In this case, it is possible that even a condition such as a routing loop could take place. (Chapter 7, "LAN and WAN Protocols," discusses routing protocols and methods.) In this type of condition, packets could flow in and out of the LAN from the WAN and possibly take multiple routes to the LAN segments through the two parallel routers. This setup could prove extremely problematic and cause extensive delays. The trace protocol analysis results of the baseline sessions may show high multiple router symptom errors along with route validity changes and route cycle changes as related to the router configurations. This could show that the two router tables are being refreshed too frequently and would also possibly correspond to other protocol analyzer symptoms such as long response time for workstations communicating over the WAN, along with timeouts and non-responsive conditions for upper-layer communications. This is considered an important identification item in a protocol analysis session.
This particular example shows how critical it is to use a network analysis session to identify any anomalies related to network documentation and how important it is to immediately identify an unknown device and redesign a configuration that could be causing problems on the network.
In summary, it is important to always have the most current set of network documentation prior to beginning a network baseline study. Such documentation includes information such as the network layout configuration, network blueprints, file server and workstation documentation, any LAN and WAN site maintenance and service logs, and any topology-specific documentation such as LAN and WAN configurations or drawings, along with network protocol configurations and router/switch diagrams and configurations.
The discussion now turns to network documentation as it relates to the network baseline process.
Various types of network documentation can assist an analyst when performing a network baseline session. Some network layout documents relate directly to the topology or the configuration of a specific area of the network. Other relevant network layout documents include network blueprints or documents that contain information related to file server and workstation configuration. LAN and WAN service logs may also prove useful (see Figure 6.2).
Thorough network documentation is very important to the network baseline process. Quite often when performing a network baseline or when making an emergency protocol analysis, an analyst must immediately locate a certain device within a large enterprise internetwork.
Sometimes a protocol analysis trace from a network baseline study shows that a device is generating physical errors on certain topologies. A network baseline study might also show that a device is generating network or upper-layer communication errors that also cause performance problems evident in the baseline data-trace flow. These problems may relate to symptomatic occurrences affecting the user base at the site.
By following the proper methodology for network baselining as discussed earlier in this book—such as performing utilization measurements, reviewing protocol percentages, and reviewing certain statistical metric measurements such as error statistics—an analyst can most likely immediately identify the address of the device causing site problems. The analyst can then contact the relevant network support personnel to locate the device based on the type of error (physical, network, or application). If the network support group can find the device, both the analyst and the network support team can then quickly review the device's operation. They can also assess the impact of the network error on users' day-to-day operations, including application performance within a particular network area. Without current or accurate network documentation, however, finding the specific device can take a much longer time. Even after the device has been located, its impact on the LAN may take longer to understand if certain configuration information is not available. Obviously, network documentation can be extremely important to quick problem identification and problem resolution.
When performing a large network baseline, an analyst faces a slower process if he cannot locate problem devices (identified during data-trace analysis sessions). The process is also slowed if the analyst doesn't have the relevant configuration information (hardware and software builds, for example). Such missing information may impede the analyst's ability to immediately identify technical issues, and may therefore thwart the network baseline progression. The analyst might become bogged down in the data-acquisition process and not be able to move rapidly through the full network baseline cycle.
Among key documentation important to a successful network baseline is a building blueprint that includes an overleaf diagram of the network's cabling. The blueprint must show the building's physical layout as well as the network cabling point-to-point configuration. Each cable run should be labeled on all ends to match the blueprint and the cabling diagram. All patch panels should have affixed labels that show cable-to-cable linking.
A mere network topology diagram may not give an analyst all the necessary information. Even though a network topology diagram may point out LAN segments, WAN location points, and router/server configurations, it may not show exactly where these devices are located within a building.
The building blueprint, very importantly, should document the correlation between the network configuration diagrams and the location of devices within a building. When designing, configuring, and implementing any type of network, it is important to always update a building blueprint with the location of key devices in the network (such as internetwork hubs or switches that provide connections to the user area). Important information also includes main computer room file server locations and key router and switch platform placement within a particular network infrastructure.
A building blueprint should serve as a main reference document during the network design and implementation process. All network devices implemented on a network—such as hubs, switches, routers, and servers, and even possibly key workstations and printers—should be documented on the building blueprint.
Network support personnel should have a duplicate of the main building blueprint so that they can document any network changes. All network design and implementation personnel should try to ensure that the placement of any key network devices and cabling runs is properly marked on the blueprints (see Figure 6.3). This documentation is vital to a network baseline analyst and to any troubleshooting personnel.
This documentation will be vital to a network baseline analyst or any troubleshooting personnel in the future when troubleshooting ongoing network problems within an enterprise infrastructure.
Often during a protocol analysis session, an analyst can locate a physical or network layer address that identifies a problem device. Even if the analyst identifies the device via the network baseline session, the network support personnel must be able to locate the actual device within the facility.
Even if the address appears to be active on the main file server within a location and the device is active on the network, it can sometimes be a challenge to locate the actual internetwork hub where the device is connected. And even if the network blueprint references the specific location of the internetwork hub, it may be necessary to follow a specific cable run throughout the facility to find the device (in a particular office or cubicle, for example).
In this particular case, an analyst with a detailed building blueprint can refer to the blueprint and determine the location of the address or device in question more rapidly. The analyst may then be able to quickly find the device and review its configuration (to hopefully determine why errors captured via the network baseline session generated). The detailed blueprint enables the analyst to isolate a network problem more rapidly.
Configuration documentation of servers or station devices within a facility is also vital to network troubleshooting and network baselining. Critical internal documentation includes hardware and software builds of a network file server or a main workstation in a facility.
The discussion now focuses on the important LAN file server or workstation configuration information as it relates to a network baseline study.
When performing a network baseline session, it is important to review the configuration of any and all problem devices (identified as such during trace analysis). When reviewing a file server or a workstation, certain information is critical.
When performing a protocol analysis session, if a server is found to show an extremely slow response time, an analyst should immediately review the server's configuration. Certain server configuration information is critical (for example, the type of NIC as well as the card's software driver). The analyst should identify the physical network address of the server along with any network layer address information, such as an IP address. Certain hardware configuration information is also relevant, such as the memory allocation of the server (from an original hardware design standpoint). The analyst should review the server operating system parameters and active monitoring screens for the memory used throughout an operational cycle. By doing so, an analyst might find a memory-related problem (such as maximum use) in a server. Such a memory problem might be causing an excessive utilization of the server process modes and eventually causing slow response times (for attached users attempting to access the server). The analyst must also review other memory parameters, such as blocks of memory in use and blocks of memory free. It is also important to monitor processor utilization; the design or the hardware build of the server (such as the type of bus design) can affect processor utilization.
The analyst should monitor all utilization metrics for average and peak transitions of server usage. To do so, the analyst can closely monitor the configuration hardware build of the server and then monitor server statistical screens (perhaps by using a network operating system monitoring program). In a Novell server environment, the analyst can use a Novell monitoring program; in a Windows NT environment, the analyst can use a Performance Monitor program.
Other critical statistics for file servers include original cache buffers and total cache buffers utilized. Some server environments, such as Novell, have unique statistics that must be monitored, such as packet received buffers. Minimum and maximum server configuration settings can sometimes be adjusted; doing so enables you to fine-tune a server so that it performs more rapidly. A server usually has a minimum and maximum number of assigned connections as well. An analyst must review these configurations as well.
An area of importance in the server configuration is the amount of disk drive allocation available for maximum use and the amount of disk drive actually used (see Figure 6.4).
Figure 6.4. A simple way to document a server configuration for access during a network baseline study.
When reviewing a server environment, it is also important to consider the types and number of applications balanced or configured against a server. Quite often, after a network has been designed and implemented and a server layout configuration has been planned, new application deployment causes the applied user-connected configuration to increase rapidly.
In light of this, it is important for an analyst to understand that, from a baseline perspective, specific data may show that a network server is operating in a slow or over-maximized condition. In such a circumstance, the server may start to show slow response time or slow interpacket delta response time or general long acknowledgment time when responding to workstations attempting to access the server. When this type of error occurs, the analyst may be able to quickly work with the network support team to review the server's configuration, to identify suspect areas of the configuration, and to adjust certain settings to improve performance. In certain cases, it may be possible to immediately reconfigure the server; in other cases, it may be necessary to add hardware components to the server along with software updates to improve the server's performance.
Assume, for example, a server configured for basic word processing– or spreadsheet-type programs. For the first several months of the initial implementation, the server appears to operate quite well. Three to four months into the server's rollout cycle, the server starts to show slow performance when users access the server. The problem appears to be site wide and many users complain about performance issues. A baseline analyst can deploy a network analyzer in the main computer room and closely monitor the server. After setting a filter on the server, the baseline analyst can then monitor the server's response or delta time and the overall effective file throughput(EFT) as well as the general operation. If the server appears to show slow response time and extremely low EFT, the analyst can review the server's configuration. If the analyst determines that the server is highly utilized related to memory and utilization parameters, the analyst can search for a hardware configuration issue. If the number of actual user connections appears to have increased (relative to the assigned users), this may indicate that the problem partially relates to an under-balanced server (relative to the number of user connections applied).
Another error condition might result after new applications are deployed on the server (a new Transmission Control Protocol(TCP) application, for example). The server's original design might not have anticipated a new application's operational effect on the server's own operation. Assume, for example, that the analyst determines that the server is operating at 50% capacity with regard to the new TCP application. The baseline analyst may then be able to more closely identify the problem. When performing a protocol analysis session, the analyst might find TCP window errors (size exceeded, size frozen parameters, and TCP window not updating, for example). This could indicate that the server's TCP window (discussed later in this book) is not configured appropriately to deal with the actual application usage demanded by the user community.
Although a server may have adequate hardware resources (memory, disk space, and processor configurations, for example) to handle a new application, certain configurations may need to be changed to accommodate new demand. (For example, simple TCP configurations such as window size may have to be increased, for instance from 16KB to 32KB, to facilitate a more fluent TCP stream for all the new users accessing the new application.) The previous examples show just a few possible misconfigurations and the importance of network documentation to a network baseline exercise.
Site workstations throughout a facility have similar types of parameters that call for review. Such workstation parameters include memory, hardware configuration build, processor type, NIC configuration and driver type, as well as other parameters such as the Network Operating System(NOS) operating shell and certain drivers that enable users to access specific server environments (for example, Novell and Windows NT).
The important thing to note here is that a baseline analyst must always remember to immediately document any protocol analysis results that show anomalies and then forward them for baseline analysis review. If an analyst determines that a particular device needs configuration review (during the baseline analysis process or during the final reporting process), the analyst must contact the network support personnel who support that particular device. The analyst must also immediately check the network documentation for items such as a file server or a workstation. Properly documented information enables the analyst to more rapidly identify a reconfiguration or an adjustment parameter or possibly an additional design implementation required to resolve network issues. This is a key tie-in between network analysis and network documentation, which must be clearly noted.
The discussion now turns to the importance of documenting any adjustments to a network configuration (through network maintenance or service, for example).
During the mid-1960s and through the 1970s, it was always important to document all maintenance and service to mainframes and mini-hosts. A network service or consultative technician usually documented any maintenance to the main host. Just as in those early days of computing, we should still clearly note all service in a maintenance or service log. Relevant information must include service problems and their solutions. This information must be updated for a new configuration or a new application. As LANs and WANs became more widely implemented during the 1980s and 1990s, minor network service calls or adjustments to certain areas were often not recorded (because of the rapid deployment cycle of LANs and WANs to support enterprise applications).
It was not a major factor due to the amount of notes deployed or the importance of the main applications that were configured against the LAN or WAN. LANs and WANs now comprise the core infrastructure of many business operations. Because of this, it is vital to document all network maintenance as well as device upgrades (especially any that involve hardware or software configuration for operating systems as well as even application deployment modules) after each implementation. This documentation should enable analysts to relate any abnormal events to recent changes or modifications to the LAN or WAN.
When an analyst performs a network baseline session, the analyst will more than likely identify errors or anomalies in the trace analysis results that relate to the initial network documentation received prior to the baseline study. The analyst should immediately note the error and contact the network support personnel. Documentation showing recent changes to network devices (a new firmware implementation on a router module, a recent change to a type of switch made during a service call for a software upgrade, or even a new application deployment within a particular area, for example) may enable network support personnel to isolate the cause(s), troubleshoot, and resolve the problem more rapidly.
Network service personnel dealing with LAN and WAN infrastructure issues need ready access to all relevant information (including all "change" information). All such documentation should be kept on a database of some type within the network support area. Many large enterprise internetwork support teams do document all relevant information and make such readily available to service personnel. As the number of nodes being serviced in LAN and WAN environments increases, it is common for the documentation process to be skipped after a final problem resolution. This lack of documentation results because network support personnel are in a reactive mode and have to resolve issues quickly. Because of time constraints or other pressures, quite often the documentation of the network change or the network reconfiguration is not completed (see Figure 6.5).
No matter what the situation, this step should not be skipped, and all changes and implementation or software upgrades in any LAN or WAN area should be clearly documented.
A simple approach that can be implemented within an enterprise internetwork support team is called "change control." The change control process involves submitting a planned request for a network modification or previous emergency change already applied to a board of individuals who monitor, approve, and document changes. Many large companies have implemented this approach, but many times a gap exists between the time when the change is made and when it is actually documented. When performing a network baseline session, an analyst should always keep an eye out for this type of occurrence.
An analyst should always keep in mind that when protocol trace analysis results show certain physical, network layer, or application events that do not appear to be normal, it may be possible that recent changes on the network have not yet been documented. A baseline analyst should focus on properly taking notes while paging through the trace and performing the processes discussed earlier in this book. The analyst should then take the documentation immediately to the network support team to review the occurrence. If the analyst thinks that the protocol analysis results from a network baseline study show a change related to a particular process evident in the network traffic flow, this event should then be communicated to the network support team. The network support team may be able to identify a recent change in the service log and relay to the analyst that the change is verified and that the event is normal.
Assume, for example, that a protocol analyst runs an analyzer in a main computer room and filters on a certain router. If the router appears to show a routing protocol update utilizing a routing protocol such as Open Shortest Path First (OSPF) and the analyst is not familiar with the protocol being configured (as noted in the original network documentation), this would be a notation that the analyst would quickly make. The notation could be as simple as this: Router 22A is generating OSPF updates on a certain frequency. During a follow-up session with the network support team, the analyst could quickly note that a router was recorded as generating OSPF and that the other routers throughout the facility are using Routing Information Protocol (RIP) on standard 30-second intervals. Because RIP updates are based on a distance vector routing protocol type (as discussed later in this book) and OSPF is a link state–based routing protocol (also discussed later in this book), the two routing protocol types would be identified as possibly incompatible but may not be configured for a fine-tuned routing update cycle. The network support team could review the routers and then relay to the analyst that they are aware of a recent server log entry for the OSPF modification and that the site team will be updating other routers in the facility to OSPF (see Figure 6.6).
Figure 6.6. How detailed information related to a network modification can be entered into a service log.
This process enables the baseline analyst to modify how the network baseline sampling session related to this event will be reviewed. This event could then be logged as an anomalous event that is not of major concern, and the baseline analyst could then move on to further network analysis focus items more critical and relevant to the session. This is just one example of the type of event where the network service or maintenance logs or change control logs could prove extremely helpful.
All network service implementations and network changes should be fully documented in a logbook or database within the facility. On large internetwork infrastructures, the database or custom program approach works best for the documentation review. Within certain NOS environments, such as Novell and Windows NT, various third-party applications are available for this process.
The key point is that change and modification information must be documented. In the computer room of critical servers, hosts, and other devices such as routers and switches, it may even be advantageous to include a logbook close to the device in the computer room so that it can be referenced out upon the change. The logbook could serve as the physical entry point and could be reviewed on a weekly basis and updated in a change control program and automated database.
The following section discusses the key topology documentation vital to a network baseline session.
When performing a network baseline session, it is always beneficial to have network diagrams or topology information available prior to the session. This information enables an analyst to quickly decide how the network baseline plan for deploying a network analyzer should be built. Later in this book, you learn some of the key data-acquisition planning processes required for a full network baseline study. For the purposes of this discussion, it is important to emphasize that topology documentation is critical to planning a baseline process.
When planning a baseline study, a key item to consider is the position of analyzers for a network baseline session. Such consideration and determination requires an understanding of the network topology.
Prior to a network baseline study, an analyst should always attempt to gather any network documentation that shows the topology diagram of the LAN and WAN areas of the network. Other important information includes the network protocols and operating system documentation, along with router and switch configurations within a facility. This section discusses these key items.
When performing a network baseline, the LAN layout must be documented. On a LAN diagram, it is important to note items such as the number of nodes configured and how they interconnect to a specific area within each site. With regard to the user area, it is important to understand that in each user area of the LAN a specific number of users may connect to a hub, switch, or router within a main closet that is closest to the user community accessing the network. On certain technical layout documents, this may be identified as a user closet or an Intermediate Distribution Facility (IDF). The user closet or IDF area may have a device such as a switch or hub that connects all the users through a cabling scheme to that closet. It is vital to document and update the number of users connected to that device, and then to specify the type of device in the configuration that connects the user community in that area. This particular IDF point will most likely have a cabling path that links to a main computer room or other areas of the internetwork, such as a WAN location router. The key is that the link from the main user IDF link up to the main computer room or a Main Distribution Facility (MDF) should be clearly, yet simply shown on the diagram as an uplink or cabling channel to the main computer room or MDF.
The main computer room or MDF may have a set of main hubs, switches, or routers that serve as central devices connecting all the user closets throughout a large enterprise infrastructure; these devices must be documented. The MDF devices may interconnect to a critical WAN router that connects to several other LAN locations (such as 10–20 LAN locations linked through a WAN).
On the highest level diagram of a global network, the main computer room or MDF router used for WAN connections should show a channel link, such as a Frame Relay, or a dedicated WAN link to other LAN locations. A flat layout diagram can show the links to the WAN sites. The WAN site can be clearly, yet simply identified on the diagram and the type of router or switch that connects to the WAN can also be shown. With this type information in hand, the analyst can review a one-page document that diagrams the global enterprise internetwork.
Consider, for example, a main computer that connects three user-area IDF closets. The main high-level diagram would most likely show an MDF room with a centralized router/switch linking down to the multiple IDF closet areas. The link down to each closet area would be clearly diagrammed and the IDF closet areas would show a switch, router, or hub that services the particular user area. The number of users in each IDF could be noted as IDF downlink runs (showing 24 or 48 users connected to an IDF closet area, for example). This information follows across the one-page diagram and shows all three user areas as within the one LAN site. If the centralized MDF computer room also houses main servers, these could also be placed on the high-level diagram. The main computer room could show the interconnection to the 10 WAN network sites by showing the type of WAN link symbol and the type of WAN router or switch at the remote sites. The remote site could be named on the high-level diagram. Such a high-level global diagram can show a company's local area internetwork (see Figure 6.7).
Figure 6.7. A diagram of a one-city location internetwork can be documented for reference during a network baseline study.
A further breakdown of each area of the network into separate subdiagrams could prove beneficial. If one user IDF area (User Area 1) uses a hub within the computer room that is based on a switched platform, the main diagram header would be "User Area 1." The diagram would show the user hub area (1) and the links down to the 24 or 48 users within the user area. The user connections could be clearly shown on the diagram. This type of diagram could then be duplicated for all three IDF layouts.
A MDF subdiagram could further document the main computer room. A detailed diagram could show the main computer room or MDF housing the servers and also show the main internal router switch within the computer room that links to the three user areas along with the link to the WAN router within the main MDF area. Any critical file servers located within the facility could also be indicated on a main computer room or MDF subdiagram (see Figure 6.8).
A WAN network diagram could also prove beneficial to an analyst dealing with a large infrastructure. A WAN topology diagram (for a Frame Relay network, for example) could show extensive detail of a Frame Relay internetwork. All the sites could be illustrated on a one-page diagram. Each WAN site could show the type of router in a simple picture format along with the assignment of addressing formats, such as the IP address and the location of the device in the WAN. The type of Frame Relay link could then be identified and the inter-switching system cloud of the Frame Relay link related to the Frame Relay cloud could be shown on a one-page diagram. All the WAN network sites could be tied together in a logical layout. The allocation of the assignment for the Frame Relay link could also be identified, such as the data-link control identifier (DLCI). Each site could also have a standard bandwidth allocation as well as a committed and burst allocation for Frame Relay. The bandwidth allocation on the Frame Relay channels could also be identified on a one-page diagram (see Figure 6.9).
Figure 6.9. Documentation of a global cross-city location can be documented for review during a network baseline study.
When reviewing other topology information, it is important to keep in mind that device operating systems may be relevant or active on the routers or switches and that these may affect operation and performance. Some servers may be running various protocol stacks while other servers are running compatible or different protocol stacks that relate to the computing channels or application profiles. Descriptive protocol notes should always accompany any devices placed on a diagram.
A server noted as Server 1, for example, could have the application profile noted (Lotus Notes, Word, or any other type of active application, for example). The active protocols on the NICs could also be diagramed (for instance, TCP active on NIC 1 or Novell protocols active, such as IPX and SPX, on NIC 2).
At times, certain channels of the network, such as WANs and LANs, may be used for certain protocol dataflow. In such cases, the network channels could be diagrammed on the network and could show the protocol types intended and defined to the network channel.
In WAN designs, it is common to separate certain protocol types, especially in large computing enterprise internetworks such as TCP/IP and Novell. In some cases, it may be necessary to have separate Frame Relay Assembler Dissembler (FRAD) channels for protocol or application separation. In this type of situation, the WAN diagram should reference the protocol communication across the channel. These few examples illustrate the importance of documenting network protocols with a network diagram.
When considering critical network passthrough devices, such as switches or routers, it is important to accurately document the configuration of a bridge, switch, or router.
Multiple interface cards within a switch or router may connect to different segments in the LAN or WAN infrastructure. Each segment connected to routers and switches should be identified by the physical and any network layer address assigned, such as an IP address.
Other parameters may also be important, such as cut-through or store-and- forward switching in the switching environment.
In the router environment, other parameters are important such as routing protocol update frequency, keep alive timing, buffer size, maximum transmission unit size, encapsulation type, queuing strategy, interface statistics such as input and output rate, as well as packet conditions that relate to physical conditions such as resets, collisions, and general queuing operations.
Proper documentation of switching, routing, and internetwork hub devices facilitates rapid cause isolation and troubleshooting when performing a network baseline session (see Figure 6.10).
Often you will detect delays when analyzing and filtering on the switches and routers in the computer room during a network analysis session. Clear router or switch configuration information assists in determining whether the particular device has a parameter that may be limiting the maximum transmission unit (MTU) type or the maximum frame size forwarded, or it may show a parameter problem related to packet loss or packet drop.
During a protocol analysis session, for example, an analyst may encounter excessive broadcast traffic levels in a certain user area. If the broadcast traffic level is centered on Novell and AppleTalk and appears to show inbound broadcast traffic from an exterior WAN location that has packet traffic flowing inbound to the specific area being monitored but has no correlation for devices or servers used in this area, an abnormal condition may be indicated. If the frame-per-second rate of the broadcast is in the storm category area, the switch or hub in the main IDF user closet in question may not be configured to filter out the protocol traffic from the other sites.
In this case, the configuration may not prevent the IDF users from experiencing unneeded inbound broadcast packet storms from exterior protocols. By performing the proper protocol analysis session, identifying the issue, and then contacting the network support team, you may be able to reference the documentation related to the switch in the IDF closet. If the switch is found to have a backdated version of software that is not compliant with broadcast filtering or Network Layer 3 routing, it would be wise to consider this switch for a Network Layer 3 routing or broadcast domain control implementation via virtual LAN configuration.
The important thing to note here is that through network baselining you can identify issues and take notes that you can present to the network support team for their reference. Upon referencing the documentation, it may be immediately clear that the version of a switch or a particular router configuration does not allow for network layer 3 filtering, and this may be the heart of the problem. Obviously, if everything is clearly documented in the switch and router area, you can more rapidly isolate the concern.
This chapter has discussed the importance of network documentation as it relates to network baselining and network troubleshooting. Many programs enable database logging of key physical network addresses and network location information for devices and operational configuration. Other programs enable you to create extremely useful visual documents (such as diagrams). VISIO is one such extremely robust program that relates to network topology and LAN and WAN documentation. Many large enterprise internetworks throughout the global networking environment use this program. The VISIO program is easy to configure and use and extremely important for network documentation. The program enables you to implement most of the key network LAN and WAN channel links currently used in topology and protocol environments of large infrastructure enterprises. The program enables you to configure the different types of switches, bridges, and routers used throughout the infrastructure. Other programs on the market also enable you to create this type of documentation.
It is important for an analyst to know that prior to a network baseline study, network documentation will be valuable. If no network documentation is available (such as from a LAN or WAN topology program), the analyst may feel less inclined to properly plan a network baseline session. At the very least, prior to a baseline session the analyst should walk through a facility and review the placement of devices and determine how the placement relates to the available network documentation. Even such a limited scenario assists the analyst in planning a proper baseline study from a data-acquisition positioning standpoint. Data acquisition planning procedures are discussed in more detail later in this book.
For the record, certain documentation related to the placement of devices within a facility is critical. Accurate building blueprints are definitely required for critical network troubleshooting processes.
Information related to server, workstation, switch, router, and hub internal configurations is extremely valuable to the network baselining and troubleshooting process. During the network baseline process, an analyst may encounter many conditions where the protocol analysis results identify slow performance or anomalies in traffic flow. It is very important that the documentation for file servers, critical workstations, printers, hubs, switches, and routers be available for review after isolation of problems during a protocol analysis session.
In closing, the LAN and WAN diagrams are among the highest level and most important type of diagrams required for network baselining. When reviewing the discussions on network topologies and protocols presented later in this book, keep in mind that network documentation plays an important part when performing an accurate network baseline session in a rapid manner and when isolating problems through cause analysis and when troubleshooting with a protocol analyzer.
Throughout this book, and specifically in chapter 7, you will explore some of the unique case studies that have been encountered throughout my consulting career in the industry as a lead baseline analysis in the LAN Scope analysis team. The LAN Scope analysis team has studied more than 8500 networks in 11 years. The case studies presented are relevant to many network topology and protocol configurations. It is likely that you will find at least one or two of these case studies relevant to your networking environment.
These case studies present some of the benefits and "real world" experiences that were encountered through network baselining and protocol analysis by my work with the LAN Scope analysis team.
Detailed methods in reviewing protocol types such as Windows NT, Novell, TCP/IP, and other main protocols are presented in this material. A detailed discussion on network topology specific analysis techniques for various topologies such as Ethernet, Token Ring, FDDI, ATM, and WAN infrastructures proceeds.
Real world network baselining processes such as data acquisition planning, data acquisition, and final network baseline report development discussions help to wrap up the book.