You need to keep a few considerations in mind when selecting and implementing a compression
method:
Modem compression Modems can compress data up to four times smaller than its original size.
There are different types of modem compression techniques, so make sure you understand that
modem compression and router software compression are not compatible. However, the modems
at both ends of the connection will try to negotiate the best compression method to use. If compression
is being done at the modem, do not configure the router to also run compression.
Encrypted data Compression happens at the Data Link layer (layer 2), and encryption
functions at the Network layer (layer 3), although the payload is also encrypted, which
includes layer 7. After the application encrypts the data, the data is then sent to the router,
which provides compression. The problem is that encrypted data typically does not have
repetitive patterns, so the data will not compress. The router will spend a lot a processor
time to determine the traffic is not compressible. So, if data is encrypted, do not attempt to
compress it by using a layer 2 compression algorithm.
CPU cycles versus memory The amount of memory that a router must have varies according
to the protocol being compressed, the compression algorithm, and the number of configured
interfaces on the router. Memory requirements will be higher for Predictor than for Stac, but
Stac is typically more processor intensive.
IT Certification CCIE,CCNP,CCIP,CCNA,CCSP,Cisco Network Optimization and Security Tips
Payload Compression
Payload compression, also known as per-virtual-circuit compression, compresses only the payload,
or data portion, of the packet. The header of the packet is not touched.
Link Compression
Link compression, also known as per-interface compression, compresses both the header
and payload section of a data stream. Unlike header compression, link compression is protocol
independent.
The link compression algorithm uses Stac or Predictor to compress the traffic in another link
layer such as PPP or LAPB, ensuring error correction and packet sequencing. Cisco proprietary
HDLC protocol is capable of using Stac compression only.
Predictor Use this approach to solve bottleneck problems caused by a heavy load on the
router. The Predictor algorithm learns data patterns and “predicts” the next character by using
an index to look up a sequence in a compression dictionary. This is sometimes referred to as
lossless because no data will be lost during the compression and decompression process.
Stac This method is best used when bottlenecks are related to bandwidth issues. The Stac
method searches the input data stream for redundant strings and replaces them with a token
that is shorter than the original redundant data string.
If the data flow traverses a point-to-point connection, use link compression. In a link
compression environment, the complete packet is compressed and the switching information
in the header is not available for WAN switching networks. Typical examples are
leased lines or ISDN.
If you use payload compression, you should not use header compression. This
is redundant, and you should configure payload compression only.
In the following example, we turned on LAPB encapsulation with Predictor compression and
set the maximum transmission unit (MTU) and the LAPB N1 parameters:
Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface serial0
Router(config-if)#encapsulation lapb
Router(config-if)#compress ?
predictor predictor compression type
stac stac compression algorithm
Router(config-if)#compress predictor
Router(config-if)#mtu 1510
Router(config-if)#lapb n1 12096
Compression 937
The LAPB N1 represents the number of bits in an LAPB frame, which holds an X.25 packet.
It is set to eight times the MTU size, plus any overhead when using LAPB over leased lines. For
instance, the N1 is specified at 12,080 (that is, 1,510 × 8) plus 16 bits for protocol overhead. The
LAPB N1 parameter can cause major problems if it’s not configured correctly, and most often it
should be left at its default value. Even so, it can be really valuable if you need to set the MTU size.
or data portion, of the packet. The header of the packet is not touched.
Link Compression
Link compression, also known as per-interface compression, compresses both the header
and payload section of a data stream. Unlike header compression, link compression is protocol
independent.
The link compression algorithm uses Stac or Predictor to compress the traffic in another link
layer such as PPP or LAPB, ensuring error correction and packet sequencing. Cisco proprietary
HDLC protocol is capable of using Stac compression only.
Predictor Use this approach to solve bottleneck problems caused by a heavy load on the
router. The Predictor algorithm learns data patterns and “predicts” the next character by using
an index to look up a sequence in a compression dictionary. This is sometimes referred to as
lossless because no data will be lost during the compression and decompression process.
Stac This method is best used when bottlenecks are related to bandwidth issues. The Stac
method searches the input data stream for redundant strings and replaces them with a token
that is shorter than the original redundant data string.
If the data flow traverses a point-to-point connection, use link compression. In a link
compression environment, the complete packet is compressed and the switching information
in the header is not available for WAN switching networks. Typical examples are
leased lines or ISDN.
If you use payload compression, you should not use header compression. This
is redundant, and you should configure payload compression only.
In the following example, we turned on LAPB encapsulation with Predictor compression and
set the maximum transmission unit (MTU) and the LAPB N1 parameters:
Router#config t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface serial0
Router(config-if)#encapsulation lapb
Router(config-if)#compress ?
predictor predictor compression type
stac stac compression algorithm
Router(config-if)#compress predictor
Router(config-if)#mtu 1510
Router(config-if)#lapb n1 12096
Compression 937
The LAPB N1 represents the number of bits in an LAPB frame, which holds an X.25 packet.
It is set to eight times the MTU size, plus any overhead when using LAPB over leased lines. For
instance, the N1 is specified at 12,080 (that is, 1,510 × 8) plus 16 bits for protocol overhead. The
LAPB N1 parameter can cause major problems if it’s not configured correctly, and most often it
should be left at its default value. Even so, it can be really valuable if you need to set the MTU size.
TCP Header Compression
TCP header compression as defined in RFC 1144 compresses only the protocol headers, not the
packet data. TCP header compression lowers the overhead generated by the disproportionately
large TCP/IP headers as they are transmitted across the WAN.
It is important to realize that the layer 2 header is not touched, and only the headers at
layers 3 and 4 are compressed. This enables the layer 2 header to direct that packet across a
WAN link.
You would use the header compression on a network with small packets and a few bytes
of data such as Telnet. Cisco’s header compression supports X.25, Frame Relay, and dial-ondemand
WAN link protocols. Because of processing overhead, header compression is generally
used at lower speeds such as 64Kbps links.
TCP header compression is achieved by using the ip tcp header-compression command:
Router(config)#interface serial0
Router(config-if)#ip tcp ?
compression-connections Maximum number of compressed connections
header-compression Enable TCP header compression
Router(config-if)#ip tcp header-compression ?
passive Compress only for destinations which send compressed headers
The passive parameter is optional and is used to instruct the router to compress the headers
of outbound TCP traffic if the other side is also sending compressed TCP headers. If you don’t
include the passive argument, all TCP traffic will use compressed TCP headers.
packet data. TCP header compression lowers the overhead generated by the disproportionately
large TCP/IP headers as they are transmitted across the WAN.
It is important to realize that the layer 2 header is not touched, and only the headers at
layers 3 and 4 are compressed. This enables the layer 2 header to direct that packet across a
WAN link.
You would use the header compression on a network with small packets and a few bytes
of data such as Telnet. Cisco’s header compression supports X.25, Frame Relay, and dial-ondemand
WAN link protocols. Because of processing overhead, header compression is generally
used at lower speeds such as 64Kbps links.
TCP header compression is achieved by using the ip tcp header-compression command:
Router(config)#interface serial0
Router(config-if)#ip tcp ?
compression-connections Maximum number of compressed connections
header-compression Enable TCP header compression
Router(config-if)#ip tcp header-compression ?
passive Compress only for destinations which send compressed headers
The passive parameter is optional and is used to instruct the router to compress the headers
of outbound TCP traffic if the other side is also sending compressed TCP headers. If you don’t
include the passive argument, all TCP traffic will use compressed TCP headers.
Compression networks
The Cisco IOS provides congestion control on WAN links by adding compression on serial
interfaces. This can ease the WAN bandwidth bottleneck problems by using less bandwidth on
the link. Along with using the different queuing methods discussed earlier in this chapter, one
of the more effective methods of WAN optimization is compression of the data traveling across
the WAN link.
Software compression can significantly affect router CPU performance, and the Cisco rule of
thumb is that the router’s CPU load must not exceed 65 percent when running software compression.
If it does exceed this limit, it would be better to disable any compression running.
Cisco equipment supports the following types of compression:
TCP header compression
Payload compression
Link compression
Microsoft Point-to-Point Compression (MPPC)
By default, Cisco routers transmit data across serial links in an uncompressed format, but by
using Cisco serial compression techniques, you can make more efficient use of your available
bandwidth. It’s true that any compression method will cause overhead on the router’s CPU, but
the benefits of compression on slower links can outweigh that disadvantage.
Figure 30.7 shows the three types of compression used in a Cisco internetworking environment.
FIGURE 3 0 . 7 Cisco serial compression methods
Link compression
Header
compression
Payload compression
PPP, HDLC,
X.25, Frame
Relay, or ATM
header
IP/TCP
header Payload
The compression methods are as follows:
TCP header compression Cisco uses the Van Jacobson algorithm to compress the headers of
IP packets before sending them out onto WAN links.
Payload compression This approach compresses the data but leaves the header intact. Because
the packet’s header isn’t changed, it can be switched through a network. This method is the one
generally used for switching services such as X.25, Switched Multimegabit Data Service (SMDS),
Frame Relay, and ATM.
Link compression This method is a combination of both header and payload compression,
and the data will be encapsulated in either PPP or LAPB. Because of this encapsulation, link
compression allows for transport protocol independence.
Microsoft Point-to-Point Compression (MPPC) protocol This is defined in RFC 2118 and
enables Cisco routers to exchange compressed data with Microsoft clients. You would configure
MPPC when exchanging data with a host using MPPC across a WAN link. The MPPC is not
discussed further in this section.
The Cisco compression methods are discussed in more detail next.
interfaces. This can ease the WAN bandwidth bottleneck problems by using less bandwidth on
the link. Along with using the different queuing methods discussed earlier in this chapter, one
of the more effective methods of WAN optimization is compression of the data traveling across
the WAN link.
Software compression can significantly affect router CPU performance, and the Cisco rule of
thumb is that the router’s CPU load must not exceed 65 percent when running software compression.
If it does exceed this limit, it would be better to disable any compression running.
Cisco equipment supports the following types of compression:
TCP header compression
Payload compression
Link compression
Microsoft Point-to-Point Compression (MPPC)
By default, Cisco routers transmit data across serial links in an uncompressed format, but by
using Cisco serial compression techniques, you can make more efficient use of your available
bandwidth. It’s true that any compression method will cause overhead on the router’s CPU, but
the benefits of compression on slower links can outweigh that disadvantage.
Figure 30.7 shows the three types of compression used in a Cisco internetworking environment.
FIGURE 3 0 . 7 Cisco serial compression methods
Link compression
Header
compression
Payload compression
PPP, HDLC,
X.25, Frame
Relay, or ATM
header
IP/TCP
header Payload
The compression methods are as follows:
TCP header compression Cisco uses the Van Jacobson algorithm to compress the headers of
IP packets before sending them out onto WAN links.
Payload compression This approach compresses the data but leaves the header intact. Because
the packet’s header isn’t changed, it can be switched through a network. This method is the one
generally used for switching services such as X.25, Switched Multimegabit Data Service (SMDS),
Frame Relay, and ATM.
Link compression This method is a combination of both header and payload compression,
and the data will be encapsulated in either PPP or LAPB. Because of this encapsulation, link
compression allows for transport protocol independence.
Microsoft Point-to-Point Compression (MPPC) protocol This is defined in RFC 2118 and
enables Cisco routers to exchange compressed data with Microsoft clients. You would configure
MPPC when exchanging data with a host using MPPC across a WAN link. The MPPC is not
discussed further in this section.
The Cisco compression methods are discussed in more detail next.
Committed Access Rate
Committed access rate (CAR) is an older bandwidth and policing system; however, it is commonly
used in concert with bandwidth management. As noted before, like CBWFQ, committed access
rate can specify a bandwidth guarantee to an application. However, CAR also specifies a hard
upper limit to that application as well. This can be very useful when wanting to reserve bandwidth
for bursty applications. One example of this would be file transfer with Common Internet File System
(CIFS) and other protocols on a circuit with web traffic. An administrator might wish to use
CAR to allocate 128Kbps for HTTP/web traffic, which would have the same impact as saying all
934 Chapter 30 Queuing and Compression
traffic on a T-1 except HTTP/web has over 1,400Kbps available. The advantage is that an administrator
need not define each of the other applications to implement this solution.
CAR has some benefits. However, in many enterprises with a QoS strategy, CBWFQ is
leading the way, and administrators are opting to protect important applications with the
newer technique. You should evaluate CAR and CBWFQ for your specific environment.
used in concert with bandwidth management. As noted before, like CBWFQ, committed access
rate can specify a bandwidth guarantee to an application. However, CAR also specifies a hard
upper limit to that application as well. This can be very useful when wanting to reserve bandwidth
for bursty applications. One example of this would be file transfer with Common Internet File System
(CIFS) and other protocols on a circuit with web traffic. An administrator might wish to use
CAR to allocate 128Kbps for HTTP/web traffic, which would have the same impact as saying all
934 Chapter 30 Queuing and Compression
traffic on a T-1 except HTTP/web has over 1,400Kbps available. The advantage is that an administrator
need not define each of the other applications to implement this solution.
CAR has some benefits. However, in many enterprises with a QoS strategy, CBWFQ is
leading the way, and administrators are opting to protect important applications with the
newer technique. You should evaluate CAR and CBWFQ for your specific environment.
Subscribe to:
Posts (Atom)