Performance Problems

Frame Relay performance problems include flapping links, end-to-end problems, shaping problems, and compression over Frame Relay problems. They are described in detail in this section.

Flapping Links

One of the typical problems of poor performance is that the computers connected to the router lose their connection or experience high delay or slow performance. The issue is related to instability in the second layer and the protocol constantly going up and down. The first step in troubleshooting this problem is to check both sides of the connection. The user's end reports the output in Example 17-30.

Example 17-30. The Status of the Interfaces of the Remote User's Router

 1602-frame#show ip interface brief Interface           IP-Address      OK? Method Status                Protocol Ethernet0           10.70.194.209   YES NVRAM  up                    up Loopback0           unassigned      YES NVRAM  up                    up Serial1             unassigned      YES NVRAM  up                    up Serial1.37          10.70.194.209   YES unset  up                    up 1602-frame# 

Meanwhile, the core router is reporting the output in Example 17-31.

Example 17-31. The Status of the Interfaces of the Core Router

 7026-frame#show ip interface brief Serial4/1:0         unassigned      YES NVRAM  up                    up <output omitted> !This interface - Serial 4/1:0.37 - is the peer of the remote user's ! Serial 1.37 interface in this point-to-point configuration. Serial4/1:0.37      10.68.88.1     YES unset  up                    up Serial4/1:0.41      10.68.88.1     YES unset  up                    up Serial4/1:0.44      10.68.88.1     YES unset  up                    up 

Check the output carefully. If you compare both parts of the history of the PVC (see Chapter 14 to double-check who provides the history information), you can see a significant difference between the time that the PVC is created and the last time the PVC was changed. Enter either of the following commands:

 1602-frame#show frame-relay pvc 72060- frame#show frame-relay pvc 37 

The following PVC information is displayed:

• PVC create time Time the PVC was created

• Last time PVC status changed Time the PVC changed status (active to inactive)

The full display of the output is shown in Example 17-32.

Example 17-32. Checking the History of Serial 1.37 on a Remote User's Router

 1602-frame#show frame-relay pvc 37 PVC Statistics for interface Serial1 (Frame Relay DTE) DLCI = 37, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial1.37   input pkts 708285        output pkts 97790        in bytes 354082477   out bytes 20908266       dropped pkts 0           in FECN pkts 0   in BECN pkts 0           out FECN pkts 0          out BECN pkts 0   in DE pkts 708285        out DE pkts 0   out bcast pkts 22619      out bcast bytes 2437086 ! The next line shows the PVC was created 7w2d ago, but ! flapped 05:05 minutes ago   pvc create time 7w2d, last time pvc status changed 00:05:05 ! There is no process in Frame Relay that requires the ! PVC to go down systematically. 1602-frame# 

In Example 17-32, the first time the end user's router was turned on is 7w2d ago, and for some reason, 00:05:05 hours ago the PVC went down again. If you continue to monitor, you will see this measurement going up and down, which is known as flapping.

NOTE

You can monitor Frame Relay permanent virtual circuit's (PVC's) status better if you use the following commands under the serial 0(1) interface:

 1602-frame(config-if)#logging event ?   dlci-status-change  DLCICHANGE messages   link-status         UPDOWN and CHANGE messages   subif-link-status   Sub-interface UPDOWN and CHANGE messages 1602-frame# 

These command parameters enable you to report any change in the status of the DLCI, link, or subinterface. This way, you can review the log the following day and be precise in your information as to how many times and when the PVC has changed its status. Remember to set the router clock before testing.

You do not need to check if both sides are reacting the same way. You should not forget that the UNI is a local interface. Common sense dictates that whichever connection is flapping is the one experiencing local loop or other problems. This can be resolved by working with the LEC.

End-to-End Problems

End-to-end issues in Frame Relay are related to factors including congestion, overuse or oversubscription of lines, or incorrect or flapping routes. These factors can be recognized by some indicators such as degradation of performance during a particular time of day or after a period of normal operations. Although the routing problems are the subject of a wide variety of Cisco Press books (such as CCIE Professional Development: Advanced IP Network Design, by Retana, Slice, and White [Cisco Press, 1999]), the Frame Relay IOS troubleshooting techniques are the main objective of this section.

NOTE

The enhanced output of #show interfaces serial 1 provides a wealth of information for analysis. One indicator of excessive use is the reliability 255/255. The comparison between "5 minute input rate 0 bits/sec, 2 packets/sec" and "5 minute output rate 0 bits/sec, 0 packets/sec" and their reliability is a sign of excessive use. Every instance of reliability that trends away from 100 percent raises a red flag.

The first end-to-end tool to use is to check the status of the PVC. When traffic shaping is not on and the interface is inactive, the information in Example 17-33 appears on the screen.

Example 17-33. The End-To-End Status of PVC

 7206-frame#show frame-relay pvc <output omitted> DLCI = 65, DLCI USAGE = UNUSED, PVC STATUS = INACTIVE, INTERFACE = Serial3/2:0   input pkts 0                   output pkts 0              in bytes 0   out bytes 0                    dropped pkts 0            in FECN pkts 0   in BECN pkts 0            out FECN pkts 0         out BECN pkts 0   in DE pkts 0                  out DE pkts 0   out bcast pkts 0         out bcast bytes 0   switched pkts 0   Detailed packet drop counters:   no out intf 0            out intf down 0          no out PVC 0   in PVC down 0            out PVC down 0           pkt too big 0   shaping Q full 0         pkt above DE 0           policing drop 0   pvc create time 3w0d, last time pvc status changed 3w0d <output omitted> 

NOTE

Some of the results of this output can also be displayed using #show frame-relay route.

When you want to see the status of any particular PVC, the command requires a DLCI number. Example 17-34 shows a sample of this output and includes all PVCs, with DLCI = 37.

Example 17-34. Verifying the Status of PVCs = 37

 7206-frame#show frame-relay pvc 37 <output omitted> DLCI = 37, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/2:0.37   input pkts 243555        output pkts 253526       in bytes 32877370   out bytes 158986875      dropped pkts 264         in FECN pkts 0   in BECN pkts 0           out FECN pkts 0          out BECN pkts 0   in DE pkts 243555        out DE pkts 0   out bcast pkts 22834     out bcast bytes 6850200   pvc create time 3w2d, last time pvc status changed 3d21h   cir 56000     bc 56000     be 0         byte limit 875    interval 125   mincir 28000     byte increment 875   Adaptive Shaping none   pkts 253265    bytes 158969188 pkts delayed 130549    bytes delayed 130688876   shaping inactive   traffic shaping drops 0   Queuing strategy: fifo   Output queue 0/40, 264 drop, 130549 dequeued <output omitted> 

Besides #show frame-relay pvc, an important troubleshooting tool is #debug frame-relay [packet | events], as shown in Example 17-35.

NOTE

The #debug frame-relay [packet | events] command is chatty, so when conducting remote troubleshooting it is good practice to have two telnet/SSH sessions open. One session should have both the #terminal monitor command and the #debug frame-relay packet command. The second session should have the #undebug all command ready to enter if necessary. Use these commands only if the router's utilization is low (below 25 percent).

Example 17-35. Output from the #debug frame-relay packet Command

 1602-frame#debug frame-relay packet Frame Relay packet debugging is on 1602-frame# 7w3d: Serial1(i): dlci 37(0x853), NLPID 0x3CC(IP), datagramsize 146 incoming (i), dlci 37(0x851), network layer protocol ID = 3CCh, datagramsize 146 7w3d: Serial1(i): dlci 37(0x853), NLPID 0x3CC(IP), datagramsize 146 7w3d: Serial1(i): dlci 37(0x853), pkt type 0x2000, datagramsize 300 7w3d: Serial1.37(o): dlci 37(0x853), NLPID 0x3CC(IP), datagramsize 580 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 580 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 81 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 580 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 66 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 255 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 184 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 184 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 7w3d: Serial1.37: Broadcast on DLCI 37 link 65(CDP) ! The router broadcasts on dlci 37, using link 65 7w3d: Serial1.37(o): dlci 37(0x851), pkt type 0x2000(CDP), datagramsize 312 outgoing (o), dlci 37(0x851), packet type 2000h (CDP), datagramsize 312 7w3d: broadcast dequeue 7w3d: Serial1.37(o):Pkt sent on dlci 37(0x851), pkt type 0x2000(CDP),     datagramsize 312 7w3d: Serial1.37(o): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 427 7w3d: Serial1(i): dlci 37(0x851), NLPID 0x3CC(IP), datagramsize 44 

Refer to the beginning of the output, and you can see two different hexadecimal values for the same DLCI. This is not an error. To understand the output, see Figure 17-9, where the DLCI format is shown. If the format of the DLCI is 2 bytes, the values are shown in Figure 17-9.

Figure 17-9. Determining the DLCI from the #debug frame-relay packet Command

In this example, the DLCI = 37 (decimal) and the next value is also DLCI = 37 (decimal). The two messages differ because of the value of the DE bit (DE = 1 for the 0x853 message and DE = 0 for the x0851 message). In exactly the same way as Q.922 hexadecimal addresses, examples of the conversion include the following: 50 represents 0x0c21, 60 represents 0x0cc1, and 70 represents 0x1401.

Another troubleshooting tool is the chatty #debug frame-relay events command, which helps to analyze the incoming packets. It is a useful command when trying to differentiate between the incoming types of traffic. Another useful command is #debug frame-relay packets to monitor the outgoing and incoming traffic, as shown in Example 17-36.

NOTE

Both commands generate a high volume of output and should only be used in cases where the overall use on the router is lower than usual. Use 7206-frame#show processes cpu to ensure that the CPU utilization for five seconds, one minute, and five minutes is low.

Example 17-36. Debugging the Frame Relay Packets

 7206-frame#debug frame-relay packet Sep  1 08:32:41 PDT: Serial4/2:0.72(o): dlci 72(0x1081), pkt type 0x800(IP),     datagramsize 146 Outgoing (o) packet over serail4/2:0.72 subinterface, using DLCI=72,     packet type IP, datagramsize 146 Sep  1 08:32:41 PDT: Serial4/0:0.76(o): dlci 76(0x10C1), NLPID 0x3CC(IP),     datagramsize 48 Sep  1 08:32:41 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP),     datagramsize 68 Sep  1 08:32:41 PDT: Serial4/0:0.86(o): dlci 86(0x1461), pkt type 0x800(IP),     datagramsize 272 Sep  1 08:32:41 PDT: Serial4/0:0(i): dlci 53(0xC53), pkt type 0x2000,     datagramsize 309 Incoming (i) traffic over DLCI=53, subinterface serial4/0:0,     packet type CDP (0x2000), datagramsize 309 Sep  1 08:32:41 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP),     datagramsize 68 Sep  1 08:32:41 PDT: Serial3/0:0(i): dlci 30(0x4E3), pkt type 0x800,     datagramsize 52 Sep  1 08:32:41 PDT: Serial3/0:0.30(o): dlci 30(0x4E1), pkt type 0x800(IP),     datagramsize 52 Sep  1 08:32:41 PDT: Serial4/2:0.72(o): dlci 72(0x1081), pkt type 0x800(IP),     datagramsize 154 Sep  1 08:32:42 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP),     datagramsize 60 Sep  1 08:32:42 PDT: Serial4/0:0.202(o): dlci 202(0x30A1), pkt type 0x800(IP),     datagramsize 48 Sep  1 08:32:42 PDT: Serial4/0:0.47(o): dlci 47(0x8F1), pkt type 0x800(IP),     datagramsize 1504 Sep  1 08:32:42 PDT: Serial4/0:0.97(o): dlci 97(0x1811), pkt type 0x800(IP),     datagramsize 68 Sep  1 08:32:42 PDT: Serial4/2:0.72(o): dlci 72(0x1081), pkt type 0x800(IP),     datagramsize 140 Sep  1 08:32:42 PDT: Serial3/1:0(i): dlci 118(0x1C61),     pkt encaps 0x0300 0x8000 0x0000 0x2000(CDP), datagramsize 316 

Other messages you can see from this output include the following:

• 0x308 Signaling message, valid with DLCI = 0 (AnnexD)

• 0x309 LMI message of Consortium's DLCI = 1023

The Ethernet-type codes are the following:

• 0x3CC IP, 0x0800 Internet Protocol (IP) in a 10-Mbps network

• 0x201 IP in a 3-Mbps network

• 0x0806 IP Address Resolution Protocol (ARP)

• 0x0808 Frame Relay ARP

• 0x8035 Reverse Address Resolution Protocol (RARP)

• 0x809b Apple EtherTalk

• 0x80f3 AppleTalk ARP

• 0x8038 Spanning tree

• 0x8137 Internetwork Packet Exchange (IPX)

• 0x200 CDP

• 0x9000 Loopback packet

If the encapsulation is HDLC, the possible packet codes are the following:

• 0x1A58 IPX

• 0xFEFE Connectionless Network Service (CLNS)

• 0xEFEF Intermediate System-to-Intermediate System (IS-IS)

• 0x1998 Uncompressed Transmission Control Protocol (TCP) (header compression)

• 0x1999 Compressed TCP (header compression)

• 0x6558 Bridge packets

Another end-to-end troubleshooting command is #show frame-relay map. In point-to-multipoint designs, it is a useful tool to see the end-to-end settings and to check the functionality. The Frame Relay mapping information is shown in Example 17-37 and is explained in Table 17-8.

Example 17-37. End-to-End Settings of DLCI 37

 1602-frame# show frame-relay map <output omitted> Serial1.37 (up): point-to-point dlci, dlci 37(0x25,0x850), broadcast, IETF           status defined, active 1602-frame# <output omitted> ! Or 1602-frame# show frame-relay map <output omitted> Serial 1 is up: ip 121.118.117.111 dlci 37 (0xB1,0x2C10), static, broadcast, CISCO TCP/IP Header Compression (inherited), passive (inherited) <output omitted> ! Or 7206-frame#show frame-relay map Serial3/1:0.120 (down): point-to-point dlci, dlci 120(0x78,0x1C80),     broadcast  status deleted Serial3/1:0.112 (up): point-to-point dlci, dlci 112(0x70,0x1C00),     broadcast, BW = 56000  status defined, active Serial3/1:0.17 (up): point-to-point dlci, dlci 17(0x11,0x410),     broadcast, BW = 128000  status defined, active Serial3/1:0.121 (up): point-to-point dlci, dlci 121(0x79,0x1C90),     broadcast, BW = 56000  status defined, active Serial3/1:0.114 (up): point-to-point dlci, dlci 114(0x72,0x1C20),     broadcast, BW = 56000  status defined, active 

Table 17-8. Output from the show frame-relay map Command (The Lines Can Vary)

Output	Description
Serial 1 up; Serial3/1:0.112 (up)	Identifies a Frame Relay interface (subinterface) and its status (up or down).
ip 121.118.117.111	Destination IP address.
point-to-point dlci	Shows if this design is point-to-point.
dlci 112(0x70,0x1C00)	DLCI that identifies the logical connection, which reaches this interface. This line displays three values: its decimal value (122), the hexadecimal value (0x70), and its value as it appears on the wire (0x1C00).
Static/dynamic	Indicates whether this is a static or dynamic entry.
Cisco/IETF	Indicates the encapsulation type for this entry.
Broadcast	Indicates if it is broadcast/non-broadcast.
status deleted/status definedactive	If the interface is down, it reports a status of deleted. If not, it is defined and active.
BW = 128000	Defines the bandwidth defined for this map.
TCP/IP Header Compression (inherited), passive (inherited)	Indicates whether the TCP/IP header compression characteristics were inherited from the interface or were explicitly configured for the IP map.

Frame Relay Shaping Problems

The traffic shaping feature of Frame Relay is a derivative from the nature of the technology. It is related to the classes of service defined for different types of traffic (see Chapter 16 for more details). If traffic shaping is not configured as part of the initial configuration settings (see the next chapter), they are reported accordingly by the IOS. As previously mentioned, the #show frame-relay pvc DLCI-number, reports if traffic shaping is on and what the status is of this particular PVC. For convenience, the traffic shaping part of the output is described in Table 17-9.

Table 17-9. Lines of Output and Descriptions of Traffic Shaping Parameters (This Section Appears if the Traffic Shaping Map Class Is Applied to This PVC)

Output	Description
Cir	Current CIR, in bits per second.
Bc	Current committed burst size, in bits.
Be	Current excess burst size, in bits.
Limit	Maximum number of bytes transmitted per internal interval (excess plus sustained).
Interval	Interval used internally (can be smaller than the interval derived from Bc/CIR; this occurs when the router determines that traffic flow is more stable with a smaller configured interval).
Mincir	Minimum CIR for the PVC.
Byte increment	Number of bytes that are sustained per internal interval.
Adaptive shaping none	Indicates if the adaptive shaping is ON.
BECN response	Frame Relay has BECN adaptation configured.
Pkts	Number of packets associated with this PVC that went through the traffic shaping system.
Bytes	Number of bytes associated with this PVC that went through the traffic shaping system.
Pkts delayed	Number of packets associated with this PVC that were delayed by the traffic shaping system.
Bytes delayed	Number of bytes associated with this PVC that were delayed by the traffic shaping system.
Shaping	Shaping is active for all PVCs that are fragmenting data; otherwise, shaping is active if the traffic being sent exceeds the CIR for this circuit.
Traffic shaping drops	Number of packets dropped by the traffic shaping process.
Queuing strategy	The queuing strategies can be FIFO, weighted fair, priority queuing, none, or custom.
Output queue 0/40, 264 drop,	The size of the output queue number/maximum slots and number of drops.
130549 dequeued	Number of dequeued packets.

You must know the use of BECNs and forward explicit congestion notifications (FECNs) and their interaction with the Frame Relay switch because a growing number of delays or drops can severely affect performance.

User and Network Reactions to FECNs

The router compares the number of frames in which the FECN bit is set to 1, to the number of frames in which the FECN bit is set to 0 during Tc. If during this period, the number of BECN = 1 > = BECN = 0, the router reduces the throughput to 0.875 of its previous value. Conversely, if the number of frames with BECN = 1 < the number of frames with BECN = 0, the router increases the transmission by 1/16 of its throughput, performing slow start operations. Tc is set to four times the end-to-end transit delay.

The network switch and affiliated software constantly monitors the size of each queue, based on the regeneration cycle. This cycle begins when a queue on an outgoing port goes from idle to busy, and the average queue is computed during the measurement period. When the size exceeds a predefined threshold, the circuit is considered in a state of incipient congestion. At this time, the FECN is set to 1 and remains in this state until the average value is below the threshold. ANSI T1.618 defines an algorithm to compute the average queue length (refer to the ANSI T1.618 standard for more details).

User and Network Reactions to BECNs

If the user receives n consecutive frames with BECN = 1, the traffic from the user is reduced by a step below the current offered rate. This step count (S) is reduced by 0.675 times the throughput, then 0.5 times the throughput, and finally, 0.25 times the throughput. Likewise, traffic can build up after receiving n/2 consecutive frames with BECN = 0, and the rate is then increased by a factor of 0.125 times throughput.

The network applies flow control before the traffic becomes a factor and, therefore, it sets BECN = 1 preemptively.

NOTE

The router knows that the data flowing in its direction is experiencing congestion. It cannot control this process, but it can influence it by delaying the acknowledgments. This can delay the flow of incoming data.

You must pay attention to three significant factors when analyzing the possible traffic shaping issues:

• The ratio between the total number of output packets and out bytes to packets delayed and bytes delayed. The higher the ratio, the better. Ratios under 2:1 should be investigated.

• The number of dropped packets should also be analyzed. Remember that DE = 1 indicates eligibility and does not mean a mandatory drop, even in CIR =0 services. Two lines in the beginning of the output that are indicators of line issues are as follows:

   dropped pkts Queuing strategy: FIFO Output queue 8/40, ...drop, ...dequeued 

  
  

• Buffer misses and other software problems, especially when implementing voice, compression, and multicast can cause problems. The wrong multicast configuration, for example, can shut the interfaces down and have nothing to do with any kind of line or end-to-end Frame Relay problems.

The recommended action list to overcome the performance issues because of traffic shaping includes the following:

• Work with the LEC to resolve the problem.

• Reduce broadcast traffic.

• Implement priority queuing.

• Adjust the hold queues and buffered sizes.

• Use a protocol analyzer to check if any of your devices are generating specific traffic.

• Check for buffer types and sizes to trim their number.

Troubleshooting Compression Over Frame Relay

Before starting to troubleshoot compression, it is useful to follow some preliminary tips (more detailed information about compression is provided in Chapter 16).

Using #show hardware or #show version allows you to check what type of compression is available in the router. A Cisco router enables compression in several ways, depending on the product:

• If the router contains a compression service adapter (CSA), compression is performed in the CSA hardware (hardware compression).

• If a CSA is not available, compression is performed in the software installed on the VIP2 card (distributed compression).

• If a VIP2 card is not available, compression is performed in the router's main processor (software compression).

If hardware compression is available, it is identified in the output in Example 17-38.

Example 17-38. How to Check What Kind of Compression Is Available

 3640-frame#show version Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(1), RELEASE SOFTWARE (fc2) Copyright  1986-2001 by cisco Systems, Inc. Compiled Fri 27-Apr-01 19:23 by cmong Image text-base: 0x60008960, data-base: 0x6131C000 <output omitted> Last reset from power-on Bridging software. X.25 software, Version 3.0.0. Primary Rate ISDN software, Version 1.1. 2 FastEthernet/IEEE 802.3 interface(s) 6 Serial network interface(s) 8 Channelized T1/PRI port(s) ! This line shows that the router 7206 has two ! compression service adapters installed. 2 Compression service adapter(s) 125K bytes of non-volatile configuration memory. 4096K bytes of packet SRAM memory. 

Hardware compression starts in the core router, after the router is rebooted or is turned on. Among the first messages to be displayed (if you are using a console connection) is "Compressor is up" and "Decompressor is up." Subsequently, a message is displayed that indicates that the CSA module or data compression advanced integration module (AIM) has started successfully (see www.cisco.com/univercd/cc/td/doc/pcat/3660__p1.htm). This option is not always available because the router cannot be rebooted every time to see if the compression module is starting. However, you can check the router configuration by using the command in Example 17-39.

Example 17-39. Diagnostic Information for Compression Engine, Installed on Port 2

 7206-frame#show diag 2 Slot 2:         Compression engine 3M Port adapter ! This next line usually shows that the module functions properly.         Port adapter is analyzed         Port adapter insertion time 3w1d ago         EEPROM contents at hardware discovery:         Hardware revision 1.0           Board revision A0         Serial number     6942323       Part number    73-1868-02         Test history      0x0           RMA number     00-00-00         EEPROM format version 1         EEPROM contents (hex):           0x20: 01 18 01 00 00 69 EE 73 49 07 4C 02 00 00 00 00           0x30: 50 00 00 00 99 03 12 00 FF FF FF FF FF FF FF FF 

Before choosing any kind of compression for implementation, it is good to know which one is most appropriate for your particular core router. Because of various reasons (including IOS incompatibility) even if the router configuration is correct, compression might not work properly. As a result, instead of increasing performance, it might degrade it. It is recommended to take a look at the core router's output by using the command 7206-frame#show compress. The number of resyncs or resets usually shows a condition, where the router tries to synchronize the content of the vocabularies on both sides. Initially, this process is very intensive and generates a lot of traffic. However, if the trend of incrementing the counter is almost linear, it is not recommended to use this type of compression.

When you are about to configure compression, it is best to shut down the interfaces or subinterfaces first. Otherwise, you see a significant increase in response time, or possibly no end-to-end connection. Shutting down the interface or subinterface prior to adding or changing compression techniques is not required, but it ensures it is reset for the new data structures, and the two vocabularies start their synchronization from the beginning.

Always remember the scalability factor when applying compression. Cisco proprietary packet-to-packet compression takes about 0.5 percent utilization per DCLI, and FRF9 stac software compression shows 6 percent peak utilization per DLCI in short-term reports. The hardware compression module CSA version 2, provides compression for 256 users, and the router and IOS can support more than one module. The test results over some commonly used file types are provided in Figure 17-10.

Figure 17-10. Test Results of Frame Relay Compression

Don't forget that compression is a traffic-dependant function. If the prevailing type of user traffic is pre-compressed or redundant (IOS images, for example), you cannot expect a high compression ratio from the implementation.

The router reports compression in different ways. As shown earlier in Table 17-8, one of the options for header compression is to use the 7206-frame#show frame-relay map command, which displays the resulting compression and encapsulation characteristics; the IP map has inherited passive TCP/IP header compression. Another option is to use the command 7206-frame#sh frame-relay ip tcp header-compression. The output is displayed in Example 17-40 and an explanation is provided in Table 17-10.

Example 17-40. The Status of Header Compression for DLCI = 37

 7206-frame# show frame-relay ip tcp header-compression DLCI 37          Link/Destination info: ip 10.70.194.209 Interface Serial1: Rcvd:     40 total, 36 compressed, 0 errors           0 dropped, 0 buffer copies, 0 buffer failures Sent:     0 total, 0 compressed           0 bytes saved, 0 bytes sent Connect:  16 rx slots, 16 tx slots, 0 long searches, 0 misses, 0% hit ratio           Five minute miss rate 0 misses/sec, 0 max misses/sec 

Table 17-10. Header Compression Field Descriptions from the #show frame-relay ip tcp header-compression Command

Output	Description
Rcvd	Table of details concerning received packets.
Total	Sum of compressed and uncompressed packets received.
compressed	Number of compressed packets received.
Errors	Number of errors caused by errors in the header fields (version, total length, or IP checksum).
dropped	Number of packets discarded; seen only after line errors.
buffer copies	Number of times a new buffer was needed for the uncompressed packet.
buffer failures	Number of times a new buffer was needed but was not obtained.
Sent	Table of details concerning sent packets.
Total	Sum of compressed and uncompressed packets sent.
compressed	Number of compressed packets sent.
bytes saved	Number of bytes reduced because of the compression.
bytes sent	Actual number of bytes transmitted.
Connect	Table of details about the connections.
rx slots, tx slots	Number of states allowed over one TCP connection. A state is recognized by a source address, a destination address, and an IP header length.
long searches	Number of times the connection ID in the incoming packet was not the same as the previous one processed.
Misses	Number of times a matching entry was not found within the connection table and a new entry had to be entered.
hit ratio	Percentage of times a matching entry was found in the compression tables and the header was compressed.
Five minute miss rate	Miss rate computed over the most recent five minutes and the maximum per-second miss rate during that period.

For payload compression, the show compress command provides the sample output in Example 17-41.

Example 17-41. Compression Statistics per DLCI 37

 3640-frame#show compress <output omitted>       Serial4/1:0 - DLCI: 37          Software compression enabled ! The total amount of data to be transmitted before compression          uncompressed bytes xmt/rcv 1962361561/132244042          compressed   bytes xmt/rcv 498585954/87588960          1  min avg ratio xmt/rcv 0.705/0.705 5  min avg ratio xmt/rcv 0.715/0.718 10 min avg ratio xmt/rcv 0.715/0.722 no bufs xmt 0 no bufs rcv 87 resyncs 448        Additional Stacker Stats: ! The total amount of data to be transmitted after applying compression        Transmit bytes:  Uncompressed = 45109432 Compressed =   348114663        Received bytes:  Compressed =   76914754 Uncompressed =        0 <output omitted> 

In Table 17-11, some of the descriptions of the line-by-line output are shown from the previous command.

Table 17-11. Payload Compression Output from #show compress and Field Descriptions

Output	Description
Serial4/1:0 - DLCI: 37	Identifies a Frame Relay subinterface for software compression.
Software compression enabled	Type of compression.
Uncompressed bytes xmt/rcv 1962361561/132244042	Byte count for sent and received uncompressed data.
Compressed bytes xmt/rcv 498585954/87588960	Byte count for sent and received compressed data.
1 min avg ratio xmt/rcv 0.000/0.000 5 min avg ratio xmt/rcv 0.001/0.001 10 min avg ratio xmt/rcv 0.002/0.001	Ratio of the data throughput gained or lost in the compression routine. Any number less than one indicates that the compression is actually slowing down data throughput. It does not reflect how compressed the data is.
no bufs xmt 0 no bufs rcv 0	Indicates the number of times the compression routine was not able to allocate a transmit or receive buffer to compress or decompress a packet.
resyncs 118	Number of times the compression routine detected that the dictionaries were out of sync and restarted building a dictionary. Line errors are a common cause of restarts.
Additional Stacker Stats: Transmit bytes: Uncompressed = 45109432 Compressed = 348114663 Received bytes: Compressed = 76914754 Uncompressed = 0	The uncompressed value is the amount of data not able to be compressed, which was sent in uncompressed format. The compressed value is the byte-count of the data after it was compressed. The sum of these two values represents the actual number of bytes transmitted on the interface, minus the second layer encapsulation overhead. The compressed value is the byte-count of the compressed data received. The uncompressed value is the amount of data that is received in uncompressed format. The sum of these two values represents the actual byte count received on the interface, minus the Layer 2 encapsulation overhead.

To interpret the transmit output and compression ratio for software compression, there are some simple rules for the calculation.

Based on the information from Example 17-41 and Table 17-11, you can perform the following calculations:

• The total amount of data to be transmitted before you apply the compression routine, based on the following lines, is as follows: 1962361561 + 45109432 = 2007470993:

   uncompressed bytes xmt/rcv 1962361561/132244042 Transmit bytes:  Uncompressed = 45109432 Compressed =   348114663 

  
  

• The total amount of data to be transmitted after you apply the compression based on the following line is 45109432 + 348114663 = 393224095:

   Transmit bytes:  Uncompressed = 45109432 Compressed =   348114663 

  
  

Therefore, the overall data compression ratio is as follows:

2007470993 / 393224095 = 5.1:1

NOTE

The listed numbers do not represent the real compression ratios, but rather they represent a snapshot figure with redundant traffic types. You should not expect compression ratios higher than 2:1 over a long period of usage, with a variety of traffic types.

The precise calculations of the total amount of output in bytes, can be performed by using the results from the #show compress command and by using the number of outgoing/incoming packets from the command #show interfaces serial 1:

1.	Calculate the total number of transmit bytes from the output of the #show compress command.
2.	Multiply the number of outgoing packets from the output of the #show interfaces serial 1 command by 6. (For a 2-byte DLCI frame, the overhead is a 2-byte Flag, a 2-byte Address, and a 2-byte FCS).
3.	Add the two results from the previous steps and the resulting number should match the number of total bytes of output in the serial interface from the output of #show interfaces serial 1.

In the case of hardware compression, the output is similar with one important exception. The compression ratio is calculated by the compression engine, and some of the calculations are not necessary. Example 17-42 shows the hardware compression statistics for DLCI 64.

Example 17-42. Hardware Compression Statistics for DLCI 62

 7206-frame#show compress detail-ccp  Serial4/2:0 - DLCI: 64      Hardware compression enabled      CSA in slot 2 in use        uncompressed bytes xmt/rcv 316009631/178259458        compressed bytes   xmt/rcv 185779090/236163882      Compressed bytes sent:  185779090 bytes   1 Kbits/sec  ratio: 1.700      Compressed bytes recv:  236163882 bytes   1 Kbits/sec  ratio: 0.754 ! Resync represents the number of times the compression routine detected ! that the dictionaries were out of sync and restarted building a dictionary. ! Line errors are a common cause of restarts.        resyncs 7509      last clearing of counters: 1211408 seconds        Additional Stacker Stats:        Transmit bytes:  Uncompressed = 88971017 Compressed =   92164757        Received bytes:  Compressed =   52030283 Uncompressed = 177870511 

NOTE

The compression ratio is lower than in software compression. If you are using the same type of compression (stacker) in both cases, you will notice that the compression ratios differ significantly. Compare the resyncs in both cases. It is obvious that the hardware compression experiences issues and that the constant resync of vocabularies causes poor performance.

Unlike the previously explained precise calculations of the compression parameters, for troubleshooting purposes it is sometimes useful to see if the compression works at all. Some preliminary indicators follow:

• Non-zero values from the #show compress command

• A difference between the five minute rate in the WAN (serial) and local-area network (LAN) (Ethernet) interfaces, as shown in the following example:

   1602-frame#show interfaces serial 1 | include 5 min   5 minute input rate 8000 bits/sec, 9 packets/sec   5 minute output rate 2000 bits/sec, 4 packets/sec 1602-frame#show interfaces ethernet 0 | include 5 min   5 minute input rate 12000 bits/sec, 2 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec 

  
  

• Non-linear increments of the round-trip time (RTT) of the output (using the ping 1602-frame packet_size command) when linearly incrementing the size of the ping packets

For practical purposes, it is convenient to imagine that the compressor-decompressor engine is located between the WAN and LAN interfaces. As soon as the incoming packet hits the WAN interface (serial interface), it gets decompressed and switched to the LAN interface (Ethernet interface) and vice versa. Every outgoing Ethernet packet gets compressed, sent to the serial interface, sent compressed over the serial link, and decompressed by the other party's decompressor.