cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1549
Views
0
Helpful
3
Replies

QoS on Sup2T

rinaldok1
Level 1
Level 1

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.

3 Replies 3

patoberli
VIP Alumni
VIP Alumni

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?

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.

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

Review Cisco Networking for a $25 gift card