08-08-2017 06:25 PM - edited 03-08-2019 11:40 AM
Hi everyone,
I'm having some difficulty understanding QoS on Sup2T. In much of the documentation, it is stated that Sup2T support MCQ style QoS configurations (using class-map and policy-map) vs older mls configs.
On a chassis with the following cards:
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 48 CEF720 48 port 1000mb SFP WS-X6848-SFP
3 20 DCEF2T 4 port 40GE / 16 port 10GE WS-X6904-40G
4 20 DCEF2T 4 port 40GE / 16 port 10GE WS-X6904-40G
5 5 Supervisor Engine 2T 10GE w/ CTS (Acti VS-SUP2T-10G
6 20 DCEF2T 4 port 40GE / 16 port 10GE WS-X6904-40G
Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
1 Distributed Forwarding Card WS-F6K-DFC4-A 1.2 Ok
3 Distributed Forwarding Card WS-F6K-DFC4-E 1.2 Ok
4 Distributed Forwarding Card WS-F6K-DFC4-E 1.2 Ok
5 Policy Feature Card 4 VS-F6K-PFC4 1.2 Ok
5 CPU Daughterboard VS-F6K-MSFC5 1.4 Ok
6 Distributed Forwarding Card WS-F6K-DFC4-E 1.2 Ok
From this document (https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-652042.html#_Toc474220195), it states:
"Due to differences in queueing implementation in port ASICs, Modular Quality of Service (MQC)-compliance in PFC3-based Cisco Catalyst 6500/6800 systems is limited to marking and policing. Queuing configuration can map incoming traffic to a specific queue, allowing other functionalities such as trust, global maps, and more. This is configurable through platform-specific command-line interfaces (CLI). PFC4-based Supervisor 2T system removes these limitations by supporting C3PL, which is a policy-driven CLI syntax, for marking, policing, and queueing."
As this is a PFC4, my assumption was that the simple configuration below should work as it does on other platforms (3650/3850, 4500, etc.):
class-map type lan-queuing match-any Internetwork-Ctrl
match dscp cs6
!
class-map type lan-queuing match-any Control-Traffic-Queue
match dscp cs6
match dscp cs3
!
class-map type lan-queuing match-any Priority-Traffic-Queue
match dscp ef
match dscp cs4
!
class-map type lan-queuing match-any Multimedia-Conf-Queue
match dscp af41
!
!
policy-map type lan-queuing QoS-Output-Policy
class Priority-Traffic-Queue
priority
class Control-Traffic-Queue
bandwidth remaining percent 10
class Multimedia-Conf-Queue
bandwidth remaining percent 10
class class-default
bandwidth remaining percent 25
!
However, when I apply the service-policy to an interface, it gives me an error:
"priority command is not supported in output direction for this interface"
I have tried this with and without the "type lan-queuing" configuration, and with and without "platform qos queuing-only" configured.
If I try to use AutoQoS, it results in myriad configurations applied to interface that resemble older mls configurations, such as the following:
interface GigabitEthernet1/1
description -
ip address -
ip flow monitor m1 input
ip ospf network point-to-point
wrr-queue bandwidth 20 100 200
priority-queue queue-limit 5
wrr-queue queue-limit 65 15 15
wrr-queue random-detect min-threshold 1 70 100 100 100 100 100 100 100
wrr-queue random-detect min-threshold 2 70 100 100 100 100 100 100 100
wrr-queue random-detect min-threshold 3 40 40 50 50 60 60 70 70
wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100
wrr-queue random-detect max-threshold 3 70 70 80 80 90 90 100 100
wrr-queue cos-map 2 1 1 2
wrr-queue cos-map 3 5 3 4
wrr-queue cos-map 3 7 6 7
auto qos voip trust
end
What I'm trying to achieve is simply have the 6500 prioritize VoIP traffic as described in the simple policy-map/class-map. Is there a simpler way to achieve this on the Sup2T? I would really prefer to use the "service-policy input/output" syntax vs. the example above, as I have a very hard time deciphering what is happening.
Thanks for any assistance.
08-09-2017 07:28 AM
Check here: https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-652042.html
Section 3.4.2 states:
The line card is capable of port level shaping; however, this will be supported in a post-FCS software release.
Which software are you running at the moment?
08-09-2017 01:17 PM
15.0(1)SY2
I get the same results on the WS-X6848 line cards as well as the WS-X6904 cards.
To me it seems like the current state is halfway between mls qos and MQC. I'm surprised I'm not finding more info on this platform/issue.
08-09-2017 01:37 PM
It might be a software restriction, but I don't know exactly, just guessing.
Check here the release notes for 15.1:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/release_notes.html
Interesting points:
- Hierarchical shaping and two priority queues on WS-X6904-40G-2T
- Global QoS Policy
- Egress Microflow Destination-Only Policing
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide