Enterprise QoS Solution Reference Network Design Guide

Site-to-Site V3PN QoS Considerations
6-18
Figure 6-13 Anti-Replay Operation
69
Outside
Window
Enterprise QoS Solution Reference Network Design Guide
64-Packet 64 Packet Anti-Replay Sliding Sliding Window Window
68 4 64 65 66 67
3
Anti-Replay
Drop
Chapter 6 IPSec VPN QoS Design
Anti-Replay drops can be eliminated in a pure IPSec tunnel design (no encrypted IP GRE tunnel) by
creating separate security associations for voice and data; voice and data packets must match a separate
line in the access list referenced by the crypto map. This is implemented easily if the IP phones are
addressed by network addresses (such as private RFC 1918 addresses) separate from the workstations.
However, if IPSec tunnel mode (with an encrypted IP GRE tunnel) is used for a converged network of
voice and data, Anti-Replay drops impact data packets instead of voice packets because the QoS policies
prioritize voice over data.
Consider the effect of packet loss on a TCP-based application: TCP is connection oriented and
incorporates a flow-control mechanism within the protocol. The TCP application cannot see why a
packet was dropped. A packet dropped by a service policy on a congested output interface is no different
to the application than a packet lost by an Anti-Replay drop. From a network perspective, however, it
would be more efficient to drop the packet before sending it over the WAN link (where bandwidth is the
most expensive, only to have it dropped by the Anti-Replay mechanism on the receiving IPSec VPN
router), but the location or nature of the packet loss is immaterial to the TCP driver.
Anti-Replay drops of data traffic flows are usually in the order of 1 percent to 1.5 percent on IPSec VPN
links that experience sustained congestion and have queuing engaged (without any additional policy
tuning).
Output drops on the output WAN interface, however, tend to be few, if any, and certainly are far fewer
than those dropped by Anti-Replay. This is because Anti-Replay triggers packet drops more aggressively
than the output service policy, which is a function of the size of the output queues and the number of
defined classes.
By default, each CBWFQ class receives a queue with a length of 64 packets. This can be verified with
the show policy interface verification command. Meanwhile, the receiving IPSec peer has a single
64-packet Anti-Replay window (per IPSec Security Association) with which to process all packets from
all LLQ and CBWFQ bandwidth classes.
So, it stands to reason that the Anti-Replay mechanism on the receiving VPN router will be more
aggressive at dropping packets delayed by QoS mechanisms preferential to VoIP than the service policy
at the sending router. This is because of the size mismatch of the queue depth on the sender’s output
interface (multiple queues of 64 packets each) compared to the width of the receiver’s Anti-Replay
window (a single sliding window of 64 packets per SA). As more bandwidth classes are defined in the
policy map, this mismatch increases. As mentioned, this is an inefficient use of expensive WAN/VPN
bandwidth because packets are transmitted only to be dropped before decryption.
The default value of 64 packets per CBWFQ queue is designed to absorb bursts of data traffic and delay
rather than drop those packets. This is optimal behavior in a non-IPSec–enabled network.
Version 3.3