Catalyst G-L3 Series Switches and WS-X4232-L3 Layer 3 Modules QoS FAQ
Available Languages
Contents
Introduction
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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Q. 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).
Q. What is the minimum software required for QoS on the Layer 3 (L3) Catalyst switches?
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 CSCds82323
( registered customers only) , that can affect rate-limit features. The problem is fixed in Cisco IOS Software Release 12.0(14)W5(20).
(
Q. 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 output scheduling.
Q. 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 enabled.
Q. 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.
Q. 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.
Q. Can I disable Internetwork Packet Exchange (IPX) routing and transition to the per-port traffic shaping feature without power cycling the switch?
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 conditions.
Q. Can I enable per-port traffic shaping for the first time without user interruption?
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.
Q. Can the rate-limiting feature be used on ports configured to be in a bridge group?
A. Yes, rate-limiting can be applied to any physical ports; however, it cannot be applied to any virtual interfaces.
Q. 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 direction specified.
Q. Can the input rate-limiting and output rate-limiting be applied on the same interface?
A. Yes, however, output traffic shaping and output rate-limiting cannot be applied on the same interface.
Q. Do Layer 3 (L3) Catalyst switches support asymmetrical ingress and egress rate-limiting?
A. Yes, you can specify different rates in each direction in the per-port rate-limiting QoS configuration.
Q. 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.
Q. Why is it that I get a lower performance for TCP traffic with rate-limiting?
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 throughput.
Q. 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.
Q. How does the input or ingress classification work?
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:
IP Precedence Queue Selected Default Weighted Round-Robin (WRR) Weight 000 & 001 0 1 010 & 011 1 2 100 & 101 2 3 110 & 111 3 4 Input classification is not supported for non-IP protocols. No input scheduling algorithm is supported on the input besides FIFO.
Q. 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.
Q. Can the QoS output scheduling be changed on an interface level?
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.
Q. 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.
Q. 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.
Q. Do the Layer 3 (L3) Catalyst switches implement any congestion avoidance mechanisms such as Weighted Random Early Detection (WRED)?
A. No, congestion avoidance mechanisms such as WRED are not supported.
Q. 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 WS-X4232-L3 module.
Q. 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.
Q. Does the Cisco Catalyst 4000 Series Layer 3 module (WS-X4232-L3) support Policy Routing?
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.
Related Information
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)