This document addresses Frequently Asked Questions (FAQ) on the Quality
of Service (QoS) features of the Catalyst 2948G-L3, Catalyst 4908G-L3, and
WS-X4232-L3 module (line card) for the Catalyst 4000 switch.
Technical Tips Conventions for more information on document
Which QoS features do the Layer 3 (L3) Catalyst switches support?
A. They support input classification based on the IP precedence of the
incoming packet, output scheduling based on Weighted Round-Robin (WRR) scheme,
egress policing (per-port output rate-limiting), ingress policing (per-port
input rate-limiting), and output traffic shaping (per-port).
What is the minimum software required for QoS on the Layer 3 (L3)
A. The QoS feature of output scheduling based on IP precedence is
supported as of the first Cisco IOS® Software Release 12.0(7)W5(15a). Support
of per-port rate-limiting and output shaping features began with Cisco IOS
Software Release 12.0(10)W5(18e). Cisco IOS Software Release 12.0(10)W5(18e)
contains a bug, Cisco bug ID
registered customers only)
that can affect rate-limit features. The problem is fixed in Cisco IOS Software
Can the Layer 3 (L3) Catalyst switches mark or rewrite IP precedence Type
of Service (ToS) bits in an IP packet?
A. No, but they do honor them and use them for input classification and
Are there any restrictions on the ports to which the per-port traffic
conditioning can be applied?
A. Yes, you can apply these features only on physical ports (all ports in
Catalyst 2948G-L3 and Catalyst 4908G-L3). Hence, you cannot configure per-port
traffic conditioning features on the virtual interfaces such as Fast
EtherChannel (FEC), Gigabit EtherChannel (GEC), Bridge-Group Virtual Interface
(BVI), or subinterfaces. However, you can apply these features on Layer 2 (L2)
bridged ports in addition to the Layer 3 (L3) routed ports.
On the WS-X4232-L3 module (line card), these features cannot be applied
on the L2 10/100 ports. They can be applied on two L3 routed ports (Gigabit
Ethernet 1 and Gigabit Ethernet 2), as well as the internal ports (Gigabit
Ethernet 3 and Gigabit Ethernet 4), which are connected to the backplane. L2
ports on the 4232-L3 module and the other L2 ports on the Catalyst 4000 switch
support input classification and output scheduling. For more information about
these features, refer to the Catalyst 4000 QoS Configuration Guide.
Internetwork Packet Exchange (IPX) routing cannot be enabled when the
per-port traffic conditioning feature is enabled on any port, nor can the
per-port traffic conditioning feature be enabled when IPX routing is
Does the per-port output rate-limiting apply to all (IP and non-IP)
traffic destined for output on the applied port?
A. Yes, it applies to all traffic except traffic originating from the CPU
or traffic that is process switched by the CPU. Access Control List (ACL)-based
classification or class-based classification is also not supported.
Does the per-port input rate-limiting apply to all (IP and non-IP)
traffic received on the applied port?
A. Yes, it applies to all traffic except high-priority traffic, such as
routing updates or Bridge Protocol Data Units (BPDUs), destined to the CPU.
Access Control List (ACL)-based classification or class-based classification is
also not supported.
Can I disable Internetwork Packet Exchange (IPX) routing and transition
to the per-port traffic shaping feature without power cycling the
A. Yes, but transitioning between IPX routing and per-port traffic
conditioning involves dynamic downloading of new binaries to the network
processor. It is best to perform this dynamic downloading under light traffic
Can I enable per-port traffic shaping for the first time without user
A. No, when you enable per-port traffic shaping for the first time, it
involves the dynamic downloading of new binaries to the network processor. It
causes the link to bounce momentarily and stabilize once the downloading is
complete. This download affects all ports, not just the port in which the
per-port traffic shaping feature is enabled. It is recommended that you perform
this procedure during a scheduled downtime. The following sample output shows
the actual switch console output when traffic shaping is enabled:
2948GL3-A(config)#interface fastethernet 5
2948GL3-A(config-if)#traffic-shape rate 1000000 512000
Changing all linecard binary images to support Port QOS.
2w4d: Loading Shared CAM ISL ucode image on [FastEthernet2]No active
members in this bvi, shutting down
2w4d: %STANDBY-6-STATECHANGE: Standby: 1: BVI1 state Standby -> Init
2w4d: Downloading micro code on [FastEthernet4].
2w4d: %LINK-3-UPDOWN: Interface BVI1, changed state to down
2w4d: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed
state to down
2w4d: Loading Shared CAM ISL ucode image on [FastEthernet6]No active
members in this bvi, shutting down
2w4d: %STANDBY-6-STATECHANGE: Standby: 2: BVI2 state Standby -> Init
2w4d: Downloading micro code on [FastEthernet8].
2w4d: %LINK-3-UPDOWN: Interface FastEthernet2, changed state to up
2w4d: %LINK-3-UPDOWN: Interface FastEthernet1, changed state to up
!--- Output suppressed.
Can the rate-limiting feature be used on ports configured to be in a
A. Yes, rate-limiting can be applied to any physical ports; however, it
cannot be applied to any virtual interfaces.
Can the Access Control Lists (ACLs) or class maps be used to define the
traffic that needs to be rate-limited or shaped?
A. No, ACLs or class maps are not supported with rate-limiting. All
traffic, except the process-switched or CPU-bound traffic, is subjected to the
rate-limiting or shaping on the interface to which it is applied, in the
Can the input rate-limiting and output rate-limiting be applied on the
A. Yes, however, output traffic shaping and output rate-limiting cannot be
applied on the same interface.
Do Layer 3 (L3) Catalyst switches support asymmetrical ingress and egress
A. Yes, you can specify different rates in each direction in the per-port
rate-limiting QoS configuration.
Why is it that, when I issue the show interface fastethernet
x rate-limit command, I get no output?
A. The show interface fastethernet x rate-limit
command is a generic Cisco IOS command; it is not supported on the Catalyst
Layer 3 (L3) switches because the rate-limiting is being done on the microcode
level. Traffic shaping is done on the traffic that is going out of a port. In
this case, the output of the show interface command
can be used to obtain information about the rate obtained after shaping.
Similarly, for egress rate-limit, the show interface
command can be used. For ingress rate-limiting, switches do not have any
counters on the port to check the final rate received. To check the conformance
of the feature, you need to set up the traffic to go out through another port
and see the output counters on that port. For example, the traffic enters from
port Fast Ethernet 1 and leaves through Fast Ethernet 2. To determine the
ingress rate obtained from the rate-limit on Fast Ethernet 1, you need to see
the output rate obtained on Fast Ethernet 2. The other option is to use
monitoring tools to see the rate obtained.
Why is it that I get a lower performance for TCP traffic with
A. TCP applications behave poorly when packets are dropped as a result of
rate-limiting, due to the inherent windowing scheme used in flow control. You
can adjust the burst size parameter or rate parameter to obtain the required
What is the typical value of burst size to be used for rate-limiting on
Layer 3 (L3) switches?
A. L3 switches implement an approximation of the single token bucket
algorithm in firmware, and a reasonable burst size for the range of traffic
rates is about 20,000 bytes. The burst size should be chosen to include at
least one maximum-size packet. With each arriving packet, the policing
algorithm determines the time between this packet and the last packet, and
calculates the number of tokens generated during the elapsed time. It then adds
this number of tokens to the bucket and determines whether the arriving packet
conforms to or exceeds the specified parameters.
How does the input or ingress classification
A. Four hardware queues are supported on the egress of a port. Packets are
classified by input based on the three IP precedence bits, where the Least
Significant Bit (LSB) is a "don't care." See this table:
Default Weighted Round-Robin (WRR) Weight
000 & 001
010 & 011
100 & 101
110 & 111
Input classification is not supported for non-IP protocols. No input
scheduling algorithm is supported on the input besides FIFO.
How does the output or egress scheduling work?
A. The egress side of the interface has four hardware queues, as described
in How does the input or ingress classification
work?. When there is congestion, the packets are transmitted on the
outgoing interface based on the Weighted Round-Robin (WRR) algorithm between
the four hardware queues. Bandwidth is not explicitly reserved for these four
queues. Each of them is assigned a different WRR-scheduling weight, which
determines the way the queues share the interface bandwidth. The WRR weight is
user-configurable; you can assign a different WRR weight for each queue. The
default values are shown in the table in How does the
input or ingress classification work?. The higher the WRR weight, the
higher the effective bandwidth for that particular queue.
Can the QoS output scheduling be changed on an interface
A. Yes, Weighted Round-Robin (WRR) scheduling can be configured at a
system level and on an interface level. The interface-level configuration
overrides the system-level configuration for that specific interface.
Does the Weighted Round-Robin (WRR) work on an interface configured to be
in a bridge group?
A. No, WRR is implemented only for routed IP packets based on the two bits
of IP precedence.
Is Class Based Weighted Fair Queuing (CBWFQ) or Low Latency Queuing (LLQ)
supported in the Layer 3 (L3) Catalyst switches?
A. No, modular QoS Command-Line Interface (CLI) features like CBWFQ and
LLQ are not supported in the L3 Catalyst switches.
Do the Layer 3 (L3) Catalyst switches implement any congestion avoidance
mechanisms such as Weighted Random Early Detection
A. No, congestion avoidance mechanisms such as WRED are not
Do the Layer 3 (L3) Catalyst switches support IEEE 802.1p classification
or Class of Service (CoS) classification?
A. No, 802.1p or Layer 2 (L2) CoS-based classifications are not supported.
10/100 ports on the WS-X4232-L3 module do support them since they are L2 ports,
but the CoS value is not retained if the packet is routed through the
Is the Layer 2 (L2) Class of Service (CoS) value retained for packets
routed through the WS-X4232-L3 module?
A. Even though the routed ports on the WS-4232-l3 module do not support L2
CoS, the rest of the 10/100 ports support L2 CoS-based input classification and
output scheduling. These features are also supported on all other Ethernet
modules (line cards) on the Catalyst 4000 switch. Frames received with CoS
values are trusted on the inbound port, but the CoS value is lost when it is
routed through the WS-X4232-L3 module to an egress port in a different VLAN.
CoS value is retained when the outbound port is in the same VLAN as the inbound
port and is configured for trunking.
Does the Cisco Catalyst 4000 Series Layer 3 module (WS-X4232-L3) support
A. No, the WS-X4232-L3 module does not support Policy Routing. Because
this module shares the same codebase with other routing devices, it would
accept the route-map commands, but the configuration
does not have any effect on the routing decisions.