Real-time traffic Analysis Over Frame Relay

In large-scale data networks, there are circumstances when all network components appear to be operational, but traffic flows are not proceeding as expected. Sometimes the trouble lies in a router; for example, a mis-configured packet filter on a serial interface for a Frame Relay access line can cause packet loss, whereas improperly configured routing and service advertisement protocols are frequently sources of unwanted WAN traffic. The complex nature of constructing and implementing rule sets for packet filtering and routing lends itself to human error, and problems of this nature are not easily ascertained using a conventional SNMP NMS. This problem is compounded in a multi-organization network: as an information service provider, the subject company must routinely deal with situations where the router may not be within the purview of its own ops staff to access and re-configure.

In a LAN environment, these and similar situations are routinely resolved using packet or traffic analysis. Visual UpTime’s Traffic Capture toolset provides daily ops staff with the ability to examine the traffic emanating from and arriving across any Frame relay access line. The features of the Traffic Capture toolset compete with the best of LAN analyzers, and are accessible in a distributed manner. ASE’s can be configured to capture all traffic, or to begin a traffic capture when a frame matching a set of filters is observed. In our opinion, ASE traffic collection is more likely to yield useful snapshot data because the data collected are closer to being instantaneous than can be accomplished through remote polling. Extensive traffic filtering capabilities are provided for UDP/IP and TCP/IP traffic, Novell Netware™ IPX, and SNA (advanced filters here allow for decomposition of SNA messages according to Format ID).

To minimize traffic overhead, captured traffic is stored in a frame buffer at the ASE and summaries are retrieved by the console application on an as-needed basis. Frame and protocol decoding and post-processing performed at the console application allow the ops staff to trace the exact sequence of frames sent from and received over an access line, and to examine the composition of a Frame in detail.

The benefits of such a tool are obvious. Mis-configured equipment connected to WAN services consumes bandwidth unnecessarily, or disrupts service. The sooner the ops staff isolates the problem, the sooner expected performance levels can be restored. By providing centralized access to traffic details at every Frame Relay access line, the Traffic Capture toolset reduces incidences where staff must be dispatched to a remote location to diagnose a problem.

Understanding and Managing traffic flows and behavior

Both delay and loss are perceived as delay by end users. When users complain of that ticker information is slow, ops staff must quickly learn why. But how can the customer isolate the cause of the delay or loss? Are the distribution T1 frame circuits oversubscribed? Is there a sudden and unexpected influx of unexpected traffic from a brokerage site? Have application information flows changed in a way that was not anticipated? Have new information flows been introduced without advance planning?

Providing an immediate, initial response to these questions is another application for the Troubleshooting toolset. The Frame Relay Access Channel Summary Statistics Window graphically depicts the access channel usage as a percentage of access channel speed. The ops staff at the subject company uses this tool to investigate incidences where access channel utilization deviates from the norm. From the same window, the ops staff can identify the most active of the PVC’s on this access channel. The short-term views of traffic per access channel are used to isolate unanticipated increases in traffic over the Frame Relay network, especially traffic emanating from remote sites, where the CIR’s are currently set very low.

An issue for the subject company is the increased use of Frame Relay access by brokerage customers for additional applications services.

Figure 9. FR Access Channel Summary Statistics

Unanticipated traffic, especially "push" applications operating at distribution centers, could cause CIR. to be exceeded on stringently provisioned PVC’s, perhaps to the extent that the broadcast of ticker information is discarded by the FR network. Ops staff can identify the exact times of day and durations over which unanticipated traffic volume is forwarded over a specific PVC.

For some problems, the ops staff may switch to a PVC summary statistics view in the Troubleshooting toolset, to identify which hosts are generating the majority of the traffic ("Top Talkers").. In some cases, this information is used to take measures to suppress the use of the unanticipated application. The information may be passed along to network planning staff, who will be charged with the task of costing and accommodating its use, perhaps by having the CIR for a particular PVC increased.

Figure 10. FR PVC Summary Window

In the FR PVC summary window, a graph also plots PVC throughput according to network layer protocol. While not particularly relevant for this subject company, we believe such information can be extremely valuable to enterprises where latency-sensitive traffic such as SNA and best-effort IP traffic are transmitted over the same PVC’s. With histograms of utilization by protocol, network planners can make informed decisions regarding the amount of bandwidth required to minimize latency for SNA traffic, and apply custom, priority, or weighted fair queueing mechanisms provided in router software to assure that SNA traffic is processed at a higher priority level than IP traffic.

How important is this? Absent a clear understanding of how multiple network protocols coexist and compete for bandwidth share on a PVC and access channel, network planning is largely guesswork. An all-too-frequent reaction to loss and latency is to throw more bandwidth at the problem, by increasing CIR on a PVC, or by creating separate PVC’s for select protocols. Such actions add to the WAN service cost, when all that is necessary in many situations is better tuning of network equipment to utilize existing bandwidth cost-effectively.

next...