CoS Queuing for Tunnels Overview

Benefits of CoS Queuing for Tunnel Interfaces

CoS queuing enabled for tunnel interfaces has the following benefits:

• Segregates tunnel traffic.

  Each tunnel can be shaped so that a tunnel with low-priority traffic cannot flood other tunnels that carry high-priority traffic.

  Traffic for one tunnel does not impact traffic on other tunnels.

• Controls tunnel bandwidth.

  Traffic through various tunnels is limited to not exceed a certain bandwidth.

  For example, suppose you have three tunnels to three remote sites through a single WAN interface. You can select CoS parameters for each tunnel such that traffic to some sites gets more bandwidth than traffic to other sites.

• Customizes CoS policies.

  You can apply different queuing, scheduling, and shaping policies to different tunnels based on user requirements. Each tunnel can be configured with different scheduler maps, different queue depths, and so on. Customization allows you to configure granular CoS policy providing for better control over tunnel traffic.

• Prioritizes traffic before it enters a tunnel.

  For example, CoS queuing avoids having low-priority packets scheduled ahead of high-priority packets when the interface speed is higher than the tunnel traffic speed. This feature is most useful when combined with IPsec. Typically, IPsec processes packets in a FIFO manner. However, with CoS queuing each tunnel can prioritize high-priority packets over low-priority packets. Also, each tunnel can be shaped so that a tunnel with low-priority traffic does not flood tunnels carrying high-priority traffic.

Configuring CoS on Logical Tunnels

CoS has four typical scenarios that allow connection with remote sites using secure tunnels. However different secure tunnels may connect using different reth interfaces to different Network Providers (NP). For a specific NP, limited uplink bandwidth may be used to prioritize high-priority business and to avoid blindly dropping traffic at the NP side. Currently CoS does not support queuing across physical interfaes (IFD). Having a shared policer does not work as well as queuing, the policer may drop high-priority traffic regardless of priority. To support queuing on an IFD to enable CoS features to prioritize queuing and shaping requires logical tunnel (LT) and NP configuration.

You must define a pair of logical tunnels that are one-to-one mapped to NPs and redirect traffic with routing to the LT interface before encrypting the traffic through a secure tunnel.

For example, configure lt-0/0/0.0 and lt-0/0/0.1 to connect inet 0 and NP1 (virtual router) and configure a static route to redirect traffic to NP1 as lt-0/0/0.0 next-hop. Because NP1 has 10mbps bandwidth for upstream traffic, lt-0/00.0 can be configured with 10mbps of bandwidth shaping. See Figure 1.

Figure 1: CoS Solutions Using Logical Tunnels

How CoS Queuing Works

Figure 2 shows CoS-related processing that occurs for traffic entering and exiting a tunnel. For information on flow-based packet processing, see the Flow-Based and Packet-Based Processing User Guide for Security Devices.

Figure 2: CoS Processing for Tunnel Traffic

Limitations on CoS Shapers for Tunnel Interfaces

When defining a CoS shaping rate on a tunnel interface, be aware of the following restrictions:

• The shaping rate on the tunnel interface must be less than that of the physical egress interface.

• The shaping rate only measures the packet size that includes the Layer 3 packet with GRE or IP-IP encapsulation. The Layer 2 encapsulation added by the physical interface is not factored into the shaping rate measurement.

• The CoS behavior works as expected only when the physical interface carries the shaped GRE or IP-IP tunnel traffic alone. If the physical interface carries other traffic, thereby lowering the available bandwidth for tunnel interface traffic, the CoS features do not work as expected.

• You cannot configure a logical interface shaper and a virtual circuit shaper simultaneously on the router. If virtual circuit shaping is desired, do not define a logical interface shaper. Instead, define a shaping rate for all the virtual circuits.