I think I may of found the issue, looks like incoming queue based on DSCP trust will only work for some lan cards
"Congestion avoidance—If you configure an Ethernet LAN port to trust CoS or DSCP, QoS classifies the traffic on the basis of its Layer 2 CoS value or its Layer 3 DSCP value and assigns it to an ingress queue to provide congestion avoidance. Layer 3 DSCP-based queue mapping is available only on WS-X6708-10GE ports." -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of P.A Sent: Wednesday, August 18, 2010 3:02 PM To: 'Peter Rathlev' Cc: [email protected] Subject: Re: [c-nsp] incoming queue Peter, see below for more info. But I have "mls qos trust dscp" on most interfaces, "mls qos trust cos" will only work on trunks and I'm using routed/access ports. I did issue mls qos trust cos on one of the access ports but that didn’t cause cos 5 to be mapped to pri queue 2 for incoming. On http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11_538840.html See 12.4 WS-X6548-RJ-45 for queue defaults and its not what mine defaults to. interface FastEthernet2/25 switchport switchport mode access no ip address mls qos trust cos Interface FastEthernet2/25 queueing strategy: Weighted Round-Robin Port QoS is enabled Trust state: trust COS Extend trust state: not trusted [COS = 0] Default COS is 0 Queueing Mode In Tx direction: mode-cos Transmit queues [type = 1p3q1t]: Queue Id Scheduling Num of thresholds ----------------------------------------- 1 WRR 1 2 WRR 1 3 WRR 1 4 Priority 1 WRR bandwidth ratios: 100[queue 1] 150[queue 2] 200[queue 3] queue random-detect-min-thresholds ---------------------------------- 1 70[1] 2 70[1] 3 70[1] queue random-detect-max-thresholds ---------------------------------- 1 100[1] 2 100[1] 3 100[1] WRED disabled queues: queue thresh cos-map --------------------------------------- 1 1 0 1 2 1 2 3 4 3 1 6 7 4 1 5 Queueing Mode In Rx direction: mode-cos Receive queues [type = 1p1q0t]: Queue Id Scheduling Num of thresholds ----------------------------------------- 1 Standard 0 2 Priority 1 queue-limit ratios: 100[queue 1] 0[queue 2] queue thresh cos-map --------------------------------------- 1 1 0 1 2 3 4 5 6 7 2 1 Packets dropped on Transmit: BPDU packets: 0 queue thresh dropped [cos-map] --------------------------------------------------- 1 1 0 [0 1 ] 2 1 0 [2 3 4 ] 3 1 0 [6 7 ] 4 1 0 [5 ] Packets dropped on Receive: BPDU packets: 0 queue thresh dropped [cos-map] --------------------------------------------------- 1 1 0 [0 1 2 3 4 5 6 7 ] Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 48 SFM-capable 48-port 10/100 Mbps RJ45 WS-X6548-RJ-45 SAL0751QS8S 2 48 SFM-capable 48-port 10/100 Mbps RJ45 WS-X6548-RJ-45 SAL0749Q6TF 5 2 Supervisor Engine 720 (Active) WS-SUP720-3BXL SAL09158YJ2 6 2 Supervisor Engine 720 (Hot) WS-SUP720-3BXL SAL1028UPGH 8 0 2 port adapter FlexWAN WS-X6182-2PA SAD04320GGC Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 000e.83ae.db90 to 000e.83ae.dbbf 5.2 6.3(1) 8.5(0.46)RFW Ok 2 000e.38c3.c550 to 000e.38c3.c57f 5.2 6.3(1) 8.5(0.46)RFW Ok 5 0013.7f0a.61c4 to 0013.7f0a.61c7 4.3 8.1(3) 12.2(18)SXF1 Ok 6 0016.4708.2460 to 0016.4708.2463 5.3 8.5(3) 12.2(18)SXF1 Ok 8 00d0.d3a7.d58a to 00d0.d3a7.d5c9 1.3 12.2(18)SXF1 12.2(18)SXF1 Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 5 Policy Feature Card 3 WS-F6K-PFC3BXL SAL09148UPH 1.6 Ok 5 MSFC3 Daughterboard WS-SUP720 SAL091272QD 2.3 Ok 6 Policy Feature Card 3 WS-F6K-PFC3BXL SAL1113K5Q8 1.8 Ok 6 MSFC3 Daughterboard WS-SUP720 SAL1113K5JF 2.6 Ok System image file is "disk0:s72033-advipservicesk9_wan-mz.122-18.SXF14.bin" Thanks, Paul -----Original Message----- From: Peter Rathlev [mailto:[email protected]] Sent: Wednesday, August 18, 2010 1:27 PM To: P.A Cc: [email protected] Subject: Re: [c-nsp] incoming queue I'm not sure I can answer, but you could probably help youself by supplying a bit more information. A shot in the dark: Did you enable "mls qos trust cos" on the port? (Beware that this propagates to every port on the same ASIC.) But on what device (incl. relevant modules) and what IOS version are you having this problem? On Wed, 2010-08-18 at 12:07 -0400, P.A wrote: > hi, i read on cisco's site Where? (URL?) > that the default cos mapping for this receive > queue is cos 5 mapped to priority queue 2, but when i do a show queuing im > not seeing that mapping on the receive queue. when I try to map cos 5 to > receive queue 2, How? (Copy of configuration session?) > I only have an option for queue id 1. I'm guessing 6500/7600 of some kind from the output at the bottom of your mail. This kind of queuing only works with "mls qos trust cos" configured on the interface. Without this it seems to just ignore the configuratton. The "rcv-queue" seems to give you a warning about this. Example on 6500 12.2SXF, Gi4/1 on a WS-X6516-GBIC card (the only thing I could find with incoming priority-queuing): Router(config)#int gi4/3 Router(config-if)#rcv-queue cos-map 1 1 0 1 2 3 4 Propagating cos-map configuration to: Gi4/1 Gi4/2 Gi4/3 Gi4/4 Gi4/5 Gi4/6 Gi4/7 Gi4/8 Warning: rcv cosmap will not be applied in hardware. To modify rcv cosmap in hardware, all of the interfaces below must be put into 'trust cos' state: Gi4/1 Gi4/2 Gi4/3 Gi4/4 Gi4/5 Gi4/6 Gi4/7 Gi4/8 Router(config-if)# > On the outgoing queue > all is fine but for the incoming queue I don't have what cisco says should > be the default, cos 5 mapped to input queue 2.anyone know what the issue is? > I also read somewhere Where? (URL?) > that the incoming default queue mappings are enabled > on a trunk interface only. On an interface without "mls qos trust cos" everything ends up in queue 1 threshold 1, but that's another thing. An access port would have what kind of queueing if not the default? I would guess any kind of queueing would be the "default" queueing. And every port will do _some_ kind of queueing, even if it's just putting everything in the same one queue with no differentiating threholds and taildropping. -- Peter _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
