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).
For more information on document conventions, see the Cisco Technical Tips Conventions.
There are no specific prerequisites for this document.
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.
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 7500 Series
|| Cisco 7200, 3600, 2600 and Other Non-VIP Platforms
| Supported shaping mechanisms
|| Distributed Traffic Shaping (DTS)
|| Frame Relay Traffic Shaping (Frame Relay TS)
| Configuration command
|| shape command in a policy-map
|| frame-relay traffic-shaping on a main interface, map-class configuration commands to specify shaping parameters
| Requires Distributed Cisco Express Forwarding (dCEF)
|| Yes (Verify with the show cef linecard command)
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.
| Sample Configuration of CBWFQ on Cisco 7200, 3600, 2600 Series
!--- Create a policy-map and apply the bandwidth !--- command to a class.
encapsulation frame-relay IETF
!--- Enable Frame Relay TS.
interface Serial0/0.1 point-to-point
frame-relay interface-dlci 100
!--- 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:
Frame relay output service policy is not
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.
| Sample Configuration of DTS With a Hierarchical Policy
ip cef distributed
match < >
!--- Define match-on criteria.
match < >
!--- Define match-on criteria.
bandwidth < >
!-- Define value in kbps or percent.
priority < >
!--- Define value in kbps or percent.
ip route-cache distributed
int s0/0/0.1 point-to-point
ip address a.b.c.d
frame-relay interface-dlci xxx
map-class frame-relay cisco
service-policy output SHAPE
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.
|| Cisco 7500 Series
|| Cisco 7200, 2600/3600 Series, and Other Platforms
| Main Interface
|| Configure a service policy on the main interface
|| Supported only if Frame Relay TS is not enabled and the queueing mechanisms apply to a single interface pipe.
|| Configure a servicepolicy on the subinterface.
|| Configure a service policy within a Frame Relay map-class and enable per-VC queueing with the frame-relay traffic-shaping command. You can apply the map-class to the subinterface.
| VC Level
|| Configure a service-policy within a Frame Relay map-class and enable per-VC queueing with the frame-relay traffic-shaping command. You can apply the map-class to the VC.
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).
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.