Configuring CBWFQ on Frame Relay PVCs

Introduction

This document provides sample configurations for configuring Class-Based Weighted Fair Queueing (CBWFQ) on a Frame Relay interface. CBWFQ is enabled with the bandwidth command, as configured in a policy-map with the commands of the modular Quality of Service Command Line Interface (QoS CLI).

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

CBWFQ is supported as of the following Cisco IOS® Software Releases depending on the platform:

• Cisco 7500 Series with Versatile Interface Processors (VIP) (distributed CBWFQ) - 12.1(5)T

• Cisco 7200 Series, 2600/3600 Series, and other non-7500 Series platforms - 12.1(2)T

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

Shaping and Queueing

Queueing is generally used in the context of shaping, which reduces the output rate and thus induces congestion. Use CBWFQ with the following shaping mechanisms and commands depending on your platform.

Cisco 7200, 3600, 2600 Series

Cisco IOS 12.1(2)T introduces support for CBWFQ on the 7200, 2600/3600, and other non-Route Switch Processor (RSP) platforms. (For more information, refer to Low Latency Queueing (LLQ) Over Frame Relay.) On these platforms, CBWFQ on Frame Relay interfaces is always in the context of Frame Relay TS. Use the frame-relay traffic-shaping command to enable Frame Relay TS. You cannot use CBWFQ with Generic Traffic Shaping (GTS) and the shape command on these platforms. A sample configuration is provided below.

 policy-map mypolicy 
  class voice 
   priority 16 
  class priority-data 
   bandwidth 16 

!--- Create a policy-map and apply the bandwidth !--- command to a class. 

! 
 int s0/0 
  encapsulation frame-relay IETF 
  load-interval 30 
  frame-relay traffic-shaping 

!--- Enable Frame Relay TS. 

! 
 interface Serial0/0.1 point-to-point 
  frame-relay interface-dlci 100 
    class frclass 

!--- Apply the map-class to the Frame Relay PVC. 

! 
 map-class frame-relay frclass 
  service-policy output mypolicy 
  frame-relay cir 64000 
  frame-relay bc 640 

!--- Apply the service policy inside the map-class.

Note: If you enable a service policy directly on a main interface and not within a map-class command, you also cannot apply Frame Relay TS directly to the interface. It is important to note that the queueing mechanisms then apply to a single large interface queue rather than to per-Virtual Circuit (VC) queues

In the Cisco 7200 Series, from Cisco IOS Software version 12.0(26)S and later, it is not possible to configure an output service policy in a frame-relay map-class command anymore. Instead the Cisco 7500 configuration should be applied as explained in the following section. A hierarchical policy-map should be configured with shaping in a parent policy and queuing in a child policy. The parent policy should then be attached to either the main or subinterface. If you try to configure a service policy output in the map-class frame-relay command, the following error message will appear:

c7200(config)#map-class frame-relay
	 stef
c7200(config-map-class)#frame-relay cir
	 64000
c7200(config-map-class)#service-policy output
	 aan
Frame relay output service policy is not
	 supported

Cisco 7500 Series

As of Cisco IOS 12.1(5)T, QoS policies must run in distributed mode on the VIP; because the RSP-based QoS is no longer supported. Thus, you must use the shape command and other commands of the modular QoS CLI to implement DTS for Frame Relay interfaces on VIPs on the Cisco 7500 Series. DTS combine GTS and Frame Relay TS. A sample configuration is provided in Configuring Distributed Traffic Shaping and below.

ip cef distributed 
 !  
 class-map 1  
   match < >  

!--- Define match-on criteria.

 class-map 2  
   match < >

!--- Define match-on criteria.

 !  
 policy-map CBWFQ  
   class 1  
     bandwidth < >  
     !-- Define value in kbps or percent.  
   class 2  
     priority < > 
 
!--- Define value in kbps or percent.

 !  
 Policy-map SHAPE  
    class class-default  
     shape average    
     service-policy CBWFQ  
 !  
 int s0/0/0  
   encapsulation frame-relay  
   ip route-cache distributed  
 !  
 int s0/0/0.1 point-to-point  
   ip address a.b.c.d  
   frame-relay interface-dlci xxx  
    class cisco  
 !  
 map-class frame-relay cisco  
   service-policy output SHAPE

Choosing Where to Apply a Service Policy

When configuring CBWFQ, you use the commands of the modular QoS CLI to create a traffic policy-map with multiple traffic classes and one or more QoS features. In current versions of Cisco IOS Software, Frame Relay interfaces support applying a policy-map with the service-policy command to interfaces, subinterfaces, and VCs. Only the correct combinations of policies are now supported. The following table describes specifically where you can apply a QoS policy with traffic shaping.

Known Issues

When configuring CBWFQ on Frame Relay interfaces, note the following caveats:

• After a router is reloaded, the packet match counters of a service policy may not increment when the policy is applied to the main interface. This problem is resolved by ensuring that the Weighted Fair Queueing (WFQ) classification flags are copied from the main interface to the subinterfaces.

• Configuring LLQ and Frame Relay TS concurrently at the physical interface level is not supported. The router removes the service policy from the running configuration after a router reload. The service policy must be attached to the map-class when Frame Relay TS is enabled on the interface. Attempting to configure this combination results in the error message CBWFQ: Not supported on this interface.

• When a service policy with CBWFQ is applied directly to a Frame Relay main interface (such as, non per-VC queuing), the policy may be removed following a router reload if bandwidth statements are configured on a subinterface and a main interface. The router may report log messages similar to the following:

  CBWFQ: Not enough available bandwidth for all classes Available 44 (kbps) 
      Needed 1 00 (kbps)
      CBWFQ: Removing service policy on Serial1/0

  This problem is resolved by changing the behavior of CBWFQ to ignore the notifications when bandwidth at the subinterface is changed, since CBWFQ can be configured outside a Frame Relay map-class only at the main interface level. As a workaround, remove the bandwidth command from the subinterface. If you are using bandwidth on the subinterface to influence the routing metric, use an alternative method like cost, as in Open Shortest Path First (OSPF) or delay, as in Enhanced Interior Gateway Routing Protocol (EIGRP).

Configuration Notes

• When the bandwidth and priority commands calculate the total amount of bandwidth available on an entity, the following guidelines are invoked when the entity is a shaped Frame Relay permanent virtual circuit (PVC):

  • If a Minimum Acceptable Committed Information Rate (minCIR) is not configured, the CIR is divided by two.

  • If a minCIR is configured, the minCIR setting is used in the calculation.

  • The full bandwidth from the above rate can be assigned to bandwidth and priority classes. Thus, the max-reserved-bandwidth command is not supported on Frame Relay PVCs, although you should take care to ensure that the amount of bandwidth configured is large enough to also accommodate Layer 2 (L2) overhead. For more information, refer to What Bytes Are Counted by IP to ATM CoS Queueing?.

• Avoid setting the CIR or minCIR at the access rate. Otherwise, you may see output queues building up and causing big delays in CBWFQ classes. The reason is that the shape rate does not take into account the overhead bytes of the flag and Cyclic Redundancy Check (CRC) fields, so shaping at line rate is actually oversubscribing and will cause interface congestion. There really is no reason to shape at the access rate. You should always traffic shape at 95 percent of the access rate or, more generally, the aggregate shaped rate should always be 95 percent below the access rate.

• When FRF.12 is configured, the output queue size increases to accommodate the same number of bytes that are now fragmented. In other words, you go from a packet queue to a fragment queue.

• WFQ per VC is included in Cisco IOS Software version 12.0(7)T.

• CBWFQ with GTS is included in Cisco IOS Software version 12.1(2)T.

Related Information

• QoS Support Page
• Technical Support - Cisco Systems