Compression and VPN (comp-lzs)

Unanswered Question
Feb 24th, 2004
User Badges:


We are in the process of enabling site to site VPN encryption between Cisco 7200 (central site) and 3700 (branch site).

We are using GRE/IPSEC tunnels, we are using comp-lzs in our transform sets to take care of compressing.

Our sites has low speed links (64 and 128 kbps), before enabling the GRE/IPSEC tunnels, we were using compress stac on our serial links and it was very effective and almost brought the traffic to half its size.

The problem is that the comp-lzs compression within the transform set seems to be not effective, as once we enable the GRE/IPSEC tunnels the utilization on the serial links reaches almost 100%.

Do you have any hints that would make the comp-lzs compression effective.

Thanks in advance


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
m.singer Mon, 03/01/2004 - 07:30
User Badges:
  • Bronze, 100 points or more

Try changing the order of encapsulating in GRE and encryption.

aacole Tue, 03/02/2004 - 06:03
User Badges:
  • Bronze, 100 points or more


I'm trying the comp-lzs compression on a VPN link with a view to using it generally, I'm using the Cisco 4.0.3(D) client.

I found that it dosent seem to offer much benefit at all, and on higher speed links cripples the CPU in the router. Although the router has a base performance encryption card fitted the compression is performed in the software, hence the performance hit.

When you have the compression enabled are you seeing improved performance compared to running the GRE/IPSec link without compression?

ammart Wed, 03/03/2004 - 00:59
User Badges:


As for performance, I am doing both Encryption and Compression in the software and I have no performance issues.

I guess in your case you should either upgrade the Router or get a card that would handle compression as well.


ammart Tue, 03/02/2004 - 22:50
User Badges:


I should have updated this one earlier.

I have already opened a case with TAC related to this issue, also I have done extensive testing and I am satisfied with the results, which also complied with the feedback from TAC.

The comp-lzs is the only option we have to compress IPSEC traffic, once enabled in the Transform-set, packets will be compressed and then encrypted.

To run compression after encryption would be useless as compressing encrypted packets would actually increase their size.

An example of running compression after encryption would be to turn on the compress stac on the serial while running IPSEC.

An example of compressing before encryption would be to run comp-lzs in the transform-set, as I said, this is the only compression option we have for IPSEC.

The comp-lzs process uses the same stacker algorithm as the stacker compression on the serial, the only difference is that comp-lzs does not compress packets below 128 bytes while compress stac can do that.

Any packet below 128 bytes would be send not compressed.

In my case, we found that one of the heavy applications we are running has most of its packets below 128 bytes, as a result of that, this application was not compressed after running IPSEC, and so our links got over utilized. Of course, this same application used to be successfully compressed before running IPSEC, and that is because the compress stac on the serial can compress packets below 128 bytes.

So, when planning for IPSEC with comp-lzs, it would be important to know about the nature of the traffic you are dealing with, it would help setting the expectations.

I hope that was useful




This Discussion