QoS on VPN

outer header. In this scenario, all QoS-related parameters are attached to the VPN interface. Note that the VPN interface is a virtual interface without any bandwidth attached to it so certain QoS operations may not be applied here, namely, scheduling packets. But, other QoS parameters which can be applied include:

Classification

Marking packets

Policing packets

Buffer management

Shaping on the VPN interface

QoS provides prioritization for low-latency packets. QoS on virtual tunnel has no fixed bandwidth so there is no enforcement of bandwidth sharing. In conjunction with the per policy shaper, QoS on VPN may provide bandwidth sharing within the specified bandwidth for the global shaper.

QoS marks the ToS byte of the inner header before it is copied to the outer header. To make marking available to the outer header, you must configure the VPN interface to copy the ToS byte with the copy-toscommand. Note that ToS byte copying occurs independently of the QoS process. The ToS byte may be copied without even configuring QoS on the VPN interface.

QoS on a Virtual Interface Example

In the following example, as shown topologically in Figure 12-6, trusted networks 101.0.0.0 and

102.0.0.0are connected by a VPN site-to-site tunnel, established between XSR Remote 1 and XSR Central over Serial interface 1/0:0. Tunnel traffic consists of latency-sensitive RTP traffic and best- effort FTP traffic.

Since the serial interface is a point of congestion, you should prioritize the RTP traffic and allocate 20% of the link bandwidth for the FTP traffic during congested periods. Other traffic that may traverse Serial 1 is allocated the remaining bandwidth (totaling 80%). You will reserve 100 Kbps of the link for RTP assuming that that will be maximum requirement for RTP. In this example, QoS is defined only in the direction of Remote1 to Central. For a complete solution, QoS should be applied on the XSR Central Serial interface as well.

It is clear that by applying QoS on Serial 1/0:0 (after encryption), you will not be able to distinguish RTP packets from the FTP. One way to solve this problem is to mark packets with distinct DSCP values before they are encrypted, on the virtual interface, and copy the ToS bits to the outer header. Traffic is classified with the policy map Vpn applied on the VPN interface. policy map Vpn marks RTP packets with DSCP 46 and FTP with DSCP 18. On the output Serial port, policy map Ser distinguishes RTP and FTP packets from the tunnel using the DSCP byte on the outer header which provides proper traffic management.

XSR User’s Guide 12-19

Page 301
Image 301
Enterasys Networks X-PeditionTM manual QoS on a Virtual Interface Example