Compression is available in the IOS software on virtually every Cisco router. However, despite
its benefits, software-based compression places a significant load on the router’s processor.
Therefore, administrators must weigh the benefits of compression against the potential performance
degradation that could result. In addition, monitoring the router’s CPU is required, that
is, ensuring that the utilization of the CPU does not exceed 65 percent. You can determine the
CPU utilization by viewing it with the show process cpu command. This command will show
you a one-minute and five-minute CPU utilization trend, as shown next, where the router is running
consistently at three percent utilization:
Router1#show process cpu
CPU utilization for five seconds: 3%/3%; one minute: 3%; five minutes: 3%
To configure compression, use the following commands:
encapsulation ppp
compress [predictor | stac | mppc [ignore-pfc]]
Note that both sides of the serial link need to be configured for the same compression
method; different compression protocols are not compatible with each other. Designers should
also consider the type of data that will be used when configuring compression:
Predictor The predictor option provides a useful benefit in that compressed data will not be
recompressed—a process that typically increases the transmitted size and adds substantial delay.
This is a good choice for a mixture of compressed and uncompressed data that will traverse the
link. Predictor can be more memory-intensive than other choices, but it does not burden the
router’s CPU substantially.
Stac Most significantly, the stac compression option is the only supported algorithm for the
CBOS-based router platforms, including the Cisco 700 series. As with other compression mechanisms,
stac substitutes repetitive data sequences with brief, summarized values, which are decoded
on the other end. The specific compression algorithm is called LZW, or Lempel-Ziv-Welch, the
names of the creators.
MPPC Microsoft Point-to-Point Compression (MPPC) is used when receiving compressed
data from Windows clients. With this option, all data is compressed.
In addition, a fourth compression type is available to the designer: TCP header compression.
Invoked with the ip tcp header-compression command, TCP header compression does
exactly that—it compresses only the TCP header information (20 bytes). The specifics of TCP
header compression, which is not unique to PPP, are documented in RFC 1144. This type of
compression reduces the number of bytes required for each TCP packet and provides this reduction
with a minimum amount of overhead. TCP header compression does not impact UDP or
Internet Control Message Protocol (ICMP) packets.
Administrators wishing to offload the route processor from the burdens of compression
computations might wish to use the Cisco 7500 series router with the compression service
adapter. When this card is present, the router will use the hardware-based compression that is
running on this card. If the router contains VIP2 cards, the compression process can be distributed,
which will move the overhead of compression away from the central processor. Interface
functions on the card will be affected, however. Without VIP2 technology or the compression
service adapter, the router will default to software-based compression.
Other Cisco routers support the use of hardware-assisted compression. The 2600, 3700, and
3660 series routers support the use of a compression Advanced Integration Module (AIM) to
offload compression duties from the CPU. Also, the 3620/40 routers support a network module
that offloads PPP and Frame Relay (FRF.9) compression.
NOTE:Compression is generally avoided beyond the 2Mbps level, and ideally, it is
used only for links below 128Kbps. Review your requirements carefully before
selecting the type of compression. If traffic is truly that high, it might be a short
time before additional capacity is necessary anyway.