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.
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?
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...