[c-nsp] incoming queue

P.A razor at meganet.net
Wed Aug 18 15:01:37 EDT 2010


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:peter at rathlev.dk] 
Sent: Wednesday, August 18, 2010 1:27 PM
To: P.A
Cc: cisco-nsp at puck.nether.net
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





More information about the cisco-nsp mailing list