Compressing Frame Relay Data on a Subinterface

Problem

You want to configure your router to do Frame Relay compression on a subinterface.

Solution

Cisco offers several different types of compression with Frame Relay. You can opt to compress only the TCP headers as follows:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0
Central(config-if)#encapsulation frame-relay
Central(config-if)#frame-relay ip tcp header-compression passive
Central(config-if)#exit
Central(config)#end
Central#

This command also works at the subinterface level:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-subif)#frame-relay ip tcp header-compression passive
Central(config-subif)#exit
Central(config)#end
Central#

There are also two different payload compression options. The first uses the FRF.9 Frame Relay compression standard:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-if)#frame-relay payload-compression frf9 stac
Central(config-if)#exit
Central(config)#end
Central#

And the second uses Cisco's proprietary packet-by-packet compression:

Central#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Central(config)#interface Serial0.1 point-to-point
Central(config-if)#frame-relay payload-compression packet-by-packet
Central(config-if)#exit
Central(config)#end
Central#

Discussion

The nice thing about the first example in this recipe is that with the passive keyword, the router sends packets with compressed TCP headers only if it receives packets with compressed headers. So if you have a variety of remote sites, some of which have routers that don't support header compression, this can be a useful configuration option. You need to configure the device on at least one end without the passive keyword:

Branch1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Branch1(config)#interface Serial0
Branch1(config-if)#encapsulation frame-relay
Branch1(config-if)#frame-relay ip tcp header-compression
Branch1(config-if)#exit
Branch1(config)#end
Branch1#

Note that Cisco recommends shutting down the interface before changing this feature. It is not dangerous, but with some routers you need to reset the interface to ensure that it picks up the new configuration. The cleanest way to do this is to shut it down before making the change, and then bring it back up when you are done.

For the payload compression examples, it is critical to configure the same compression on both ends. This is a subinterface level command, so you can configure each PVC to use compression or not, according to what the device on the other end supports.

In both cases, by default the router will do the compression in a Compression Service Adapter (CSA), if one exists. If the router doesn't have a CSA, then it will use a Versatile Interface Processor (VIP-2) card instead. And, if it doesn't have either of these hardware options, then it will do the compression in software using the router's CPU. Some external Frame Relay Access Devices (FRAD) also include FRF.9 compression, but it is unlikely that you will find a FRAD the supports Cisco's packet-by-packet compression.

The FRF.9 compression command can also take several different options that allow you to force different hardware options. For example, you can force the router to use a particular CSA as follows:

Central(config-if)#frame-relay payload-compression frf9 stac csa 1

Or, if you want to force the router to do the compression in its CPU, you can use the software keyword:

Central(config-if)#frame-relay payload-compression frf9 stac software

The stac keyword in all of these FRF.9 examples specifies the standard Stacker algorithm. In fact, this is the only option available for FRF.9 compression.

In general, we recommend using FRF.9 rather than packet-by-packet compression because it is an open standard, while packet-by-packet will only work with Cisco equipment. There is no noticeable performance difference between the two compression types. Cisco introduced its own packet-by-packet compression method before the FRF.9 standard was available, and continues to support it primarily for backward compatibility.

You can see statistics on the header compression with the following command:

Router#show frame-relay ip tcp header-compression
 DLCI 100 Link/Destination info: point-to-point dlci
 Interface Serial1:
 Rcvd: 220 total, 219 compressed, 0 errors
 0 dropped, 0 buffer copies, 0 buffer failures
 Sent: 482 total, 481 compressed,
 17001 bytes saved, 229749 bytes sent
 1.7 efficiency improvement factor
 Connect: 16 rx slots, 16 tx slots, 1 long searches, 1 misses
 99% hit ratio, five minute miss rate 0 misses/sec, 0 max

Router#