Qos On A Virtual Interface Example - Enterasys Security Router X-PeditionTM User Manual

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-tos command. 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
102.0.0.0 are 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.
Figure 12-6, trusted networks 101.0.0.0 and
QoS on VPN
XSR User's Guide 12-19