Compression/Encryption
Compression/Encryption Guidelines How to use this information The following figures are guidelines only. They assume that no other processor-intensive features are enabled (e.g., queuing, accounting, filtering). The compression guidelines are for payload encryption using the STAC algorithm. The Predictor algorithm should have lower performance guidelines, but I'm not sure how much lower. The encryption guidelines are valid for CET (Cisco Encryption Technology) both 56 and 40 bit keys. There apparently is little performance difference between the two key sizes. The IPSec guidelines are valid for DES, DES/AH and AH. The is no significant difference between these techniques. 3DES numbers provided by Kip Sides 6/1/99. Some of this information was taken from the white paper Network Layer Encryption (July 1997). Design guidelines Under normal conditions, CPU utilization should remain under 65%. When possible, on an RSP2 or higher system (RSP7000, RSP2, RSP4), use the VIP2-40 distributed services for compression/encryption. This frees the RSP to perform other processing tasks. Distributed encryption is available as of 11.2(1) for HDLC and PPP; 11.2(7a)P for Frame Relay. Distributed compression is available as of xx.x(x). For highest performance compression and encryption, use the compression and encryption port adapters. Encryption and compression should not be enabled at the same time. Encrypted data cannot be effectively compressed. Therefore, it is a waste of processor cycles to try to compress encrypted data.
|
Cisco Systems, Inc. Internal Use Only
Last Modified on June 08, 1999
Copyright 1992-1999 © Cisco Systems Inc.