CoS Queuing for Tunnels
A tunnel interface in a J Series device running JUNOS Software supports many of the same CoS features as a physical interface. A tunnel interface is a virtual or logical interface on a J Series device. It creates a virtual point-to-point link between two J Series devices at remote points over an IP network.
For example, you can configure CoS features for generic routing encapsulation (GRE) and IP-IP tunnel interfaces. Tunneling protocols encapsulate packets inside a transport protocol.
GRE or IP-IP tunnels are used with services like IPsec and NAT to set up point-to-point VPNs. JUNOS Software allows you to enable CoS queuing, scheduling, and shaping for traffic exiting through these tunnel interfaces. For an example of configuring CoS Queuing for GRE tunnels, see Example: Configuring CoS for GRE/IPIP tunnels.
Benefits of CoS Queuing on Tunnel Interfaces
On a J Series device, CoS queuing enabled for tunnel interfaces allows you to
- Segregate tunnel traffic.
Each tunnel can be shaped so that a tunnel with low-priority traffic cannot swamp other tunnels that carry high-priority traffic.
Traffic for one tunnel does not impact traffic on other tunnels.
- Control 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.
- Customize 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.
- Prioritize 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 swamp tunnels carrying high-priority traffic.
How CoS Queuing Works
Figure 95 shows CoS-related processing that occurs for traffic entering and exiting a tunnel. For information on flow-based packet processing, see the JUNOS Software Security Configuration Guide
Figure 95: CoS Processing for Tunnel Traffic
Limitations on CoS Shapers for Tunnel Interfaces
On a J Series device, 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 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.