At a high-level, there are basically two compression techniques supported on serial links on Cisco routers:
Stacker - Based on the Lempel-Ziv (LZ) algorithm, this method provides the best compression, particuarly in the case of varying data, but at the cost of more CPU usage.
Predictor - Attempts to predict the next bits to be transmitted based on history. Does not compress as well as Stacker, but is lighter on CPU usage.
These two high-level technologies are implemented for payload compression through:
Stacker - Obvious; uses LZ algorithm mentioned above, supported on both PPP and HDLC. This is the only compression method supported on HDLC.
Predictor - Again, obvious; only supported on PPP.
MPPC - A Microsoft algorithm (Microsoft Point to Point Compression); implemented in Cisco devices for interoperability to Microsoft clients. Cannot be used router-to-router, only router-to-Microsoft OS. Uses LZ / Stacker compression. I'm not going to talk about this one further because I have no convenient way to lab it.
LZS - I only know this exists because it's on the menu. I had a terribly hard time finding details about this, either in my CCIE study guides, the Cisco documentation, or other blogs. It's obviously LZ-based, but it doesn't seem anyone uses it! If you have details I'm lacking, please reply to the post. Also not going to talk about this one any further.
Frame Relay Packet-by-Packet - Cisco proprietary, uses LZ algorithm, but uses a per-packet dictionary. Pre-FRF9
Frame Relay Data Stream - Cisco proprietary, uses LZ algorithm, but uses the same dictionary across all packets. Pre-FRF9
Frame Relay FRF9 - Industry standard; enabled per DLCI or per sub-interface. Uses LZ algorithm. Requires IETF LMI.
So here's how we apply all these things.
Stacker (PPP or HDLC):
interface serial0/0
compress stac
R1#show compress
Serial0/0
Software compression enabled
uncompressed bytes xmt/rcv 0/0
compressed bytes xmt/rcv 0/0
Compressed bytes sent: 0 bytes 0 Kbits/sec
Compressed bytes recv: 0 bytes 0 Kbits/sec
1 min avg ratio xmt/rcv 0.000/0.000
5 min avg ratio xmt/rcv 0.000/0.000
10 min avg ratio xmt/rcv 0.000/0.000
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 0
Received bytes: Compressed = 0 Uncompressed = 0
Predictor (PPP only):
interface serial0/0
encap ppp
compress predictor
Serial0/0
Software compression enabled
uncompressed bytes xmt/rcv 0/0
compressed bytes xmt/rcv 0/0
Compressed bytes sent: 0 bytes 0 Kbits/sec
Compressed bytes recv: 0 bytes 0 Kbits/sec
1 min avg ratio xmt/rcv 0.000/0.000
5 min avg ratio xmt/rcv 0.000/0.000
10 min avg ratio xmt/rcv 0.000/0.000
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 0
Received bytes: Compressed = 0 Uncompressed = 0
A nifty way to test this, particuarly predictor, is to make a consistent pattern and check the stats:
R1# ping 2.2.2.2 data EEEE
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
Packet has data pattern 0xEEEE
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/21/40 ms
R1#show compress
Serial0/0
Software compression enabled
uncompressed bytes xmt/rcv 1351/1351
compressed bytes xmt/rcv 325/331
Compressed bytes sent: 325 bytes 0 Kbits/sec ratio: 4.156
Compressed bytes recv: 331 bytes 0 Kbits/sec ratio: 4.081
1 min avg ratio xmt/rcv 1.631/1.732
5 min avg ratio xmt/rcv 1.631/1.732
10 min avg ratio xmt/rcv 1.631/1.732
no bufs xmt 0 no bufs rcv 0
resyncs 0
Now for the frame relay options.
I've converted our "lab" to back-to-back frame-relay in advance. DLCIs are both 50, pointing at each other.
First, Cisco packet-by-packet:
int s0/0
frame-relay map ip 172.16.0.2 50 payload-compression packet-by-packet
R1#ping 172.16.0.2 repeat 10 data EEEE
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
Packet has data pattern 0xEEEE
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/6/28 ms
R1#show frame-relay map
Serial0/0 (up): ip 172.16.0.2 dlci 50(0x32,0xC20), static,
Payload Compression packet-by-packet
R1#show compress Serial0/0
Software compression enabled
uncompressed bytes xmt/rcv 7000/7000
compressed bytes xmt/rcv 2763/2814
Compressed bytes sent: 2763 bytes 0 Kbits/sec ratio: 2.533
Compressed bytes recv: 2814 bytes 0 Kbits/sec ratio: 2.487
1 min avg ratio xmt/rcv 2.293/2.347
5 min avg ratio xmt/rcv 2.199/2.164
10 min avg ratio xmt/rcv 2.199/2.164
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stac Stats:
Transmit bytes: Uncompressed = 0 Compressed = 2763
Received bytes: Compressed = 2814 Uncompressed = 0
Then, Cisco data-stream:
int serial0/0
frame-relay map ip 172.16.0.2 50 CISCO payload-compression data-stream stac
R1(config-if)#do show frame-relay map
Serial0/0 (up): ip 172.16.0.2 dlci 50(0x32,0xC20), static,
CISCO
Payload Compression data-stream
And finally, IETF FRF9:
int serial0/0
frame-relay map ip 172.16.0.2 50 IETF payload-compression FRF9 stac
R1#show frame-relay map
Serial0/0 (up): ip 172.16.0.2 dlci 50(0x32,0xC20), static,
IETF
Payload Compression FRF9
Now let's delve into header compression.
There's TCP header compression and RTP header compression. As best I can tell, they can both be used in conjuction with payload compression and with each other.
They don't work with FRF9, you have to be using Cisco LMI if attempting to use over frame-relay.
TCP header compression...
... on PPP:
interface serial0/0
ip tcp header-compression
R1#telnet 172.16.0.2
Trying 172.16.0.2 ... Open
Password required, but none set
[Connection to 172.16.0.2 closed by foreign host]
R1#show ip tcp header-compression
TCP/IP header compression statistics:
Interface Serial0/0 (compression on, VJ)
Rcvd: 9 total, 7 compressed, 0 errors, 0 status msgs
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 19 total, 15 compressed, 0 status msgs, 0 not predicted
523 bytes saved, 396 bytes sent
2.32 efficiency improvement factor
Connect: 16 rx slots, 16 tx slots,
4 misses, 0 collisions, 0 negative cache hits, 15 free contexts
78% hit ratio, five minute miss rate 0 misses/sec, 0 max
... on frame-relay:
interface serial0/0
frame-relay ip tcp header-compression
R1#show frame-relay ip tcp header-compression
DLCI 50 Link/Destination info: ip 172.16.0.2
Interface Serial0/0 DLCI 50 (compression on, VJ)
Rcvd: 56 total, 52 compressed, 0 errors, 0 status msgs
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 95 total, 81 compressed, 0 status msgs, 0 not predicted
2848 bytes saved, 1234 bytes sent
3.30 efficiency improvement factor
Connect: 256 rx slots, 256 tx slots,
10 misses, 5 collisions, 0 negative cache hits, 256 free contexts
89% hit ratio, five minute miss rate 0 misses/sec, 0 max
Of note, show ip tcp header-compression works exactly the same with frame relay.
An extra parameter that can optionally be used it passive:
interface serial0/0
frame-relay ip tcp header-compression passive
passive will send header compression only if it receives it. Obviously, one side needs to not be passive.
And another configuration option to be aware of is how to limit the number of compression sessions:
interface serial0/0
frame-relay ip tcp compression-connections 32
Don't forget to double the number of flows. TCP connections in particular will always be two-way, and if you want 16, you specify 32.
RTP compression:
interface serial0/0
frame-relay ip rtp header-compression
frame-relay ip rtp compression-connections 16
R1# show ip rtp header-compression
RTP/UDP/IP header compression statistics:
Interface Serial0/0 (compression off, IPHC, NON TCP)
Rcvd: 0 total, 0 compressed, 0 errors, 0 status msgs
0 dropped, 0 buffer copies, 0 buffer failures
Sent: 0 total, 0 compressed, 0 status msgs, 0 not predicted
0 bytes saved, 0 bytes sent
Connect: 16 rx slots, 16 tx slots,
0 misses, 0 collisions, 0 negative cache hits, 16 free contexts
You can also shortcut on frame-relay if you want both rtp & tcp header compression:
frame-relay map ip 172.16.0.2 50 compress
Also, this debug is very useful for frame-relay compression:
debug compress
It will show the "handshake" for compression between the two ends of the circuit. Unfortunately it's relatively useless for compression on PPP or HDLC links.
That's about all you need to know!
Cheers,
Jeff
No comments:
Post a Comment