Re: Input queues on 3560

The problem with that command is that you will only see drop increments
with oversubscription. The ideal would be if the service policy counters
worked on Catalyst but not sure when Cisco will get around to that. It has
been a while.

On Fri, Sep 7, 2012 at 2:35 PM, gs gs <gs4me2me_at_gmail.com> wrote:

> What confuse me, and I cannot find good explanation of this command is 4
> queues, so I was thinking it is not the one:)
>
>
>
> Anyway, I will test to see if counters increases for all queues.
>
>
>
>
> On Fri, Sep 7, 2012 at 11:11 PM, marc edwards <renorider_at_gmail.com> wrote:
>
>> #sh platform port-asic stats drop
>>
>> Port-asic Port Drop Statistics - Summary
>> ========================================
>> RxQueue Drop Statistics Slice0
>> RxQueue 0 Drop Stats Slice0: 0
>> RxQueue 1 Drop Stats Slice0: 0
>> RxQueue 2 Drop Stats Slice0: 0
>> RxQueue 3 Drop Stats Slice0: 0
>> RxQueue Drop Statistics Slice1
>> RxQueue 0 Drop Stats Slice1: 0
>> RxQueue 1 Drop Stats Slice1: 0
>> RxQueue 2 Drop Stats Slice1: 0
>> RxQueue 3 Drop Stats Slice1: 0
>>
>> ...omitted
>>
>> Port-asic Port Drop Statistics - Details
>> ========================================
>> RxQueue Drop Statistics Slice0
>> Queue 0 DropThreshold 0 0 DropThreshold 1 0 DropThreshold 2 0
>> Queue 1 DropThreshold 0 0 DropThreshold 1 0 DropThreshold 2 0
>> Queue 2 DropThreshold 0 0 DropThreshold 1 0 DropThreshold 2 0
>> Queue 3 DropThreshold 0 0 DropThreshold 1 0 DropThreshold 2 0
>> RxQueue Drop Statistics Slice1
>> Queue 0
>> DropThreshold 0 0
>> DropThreshold 1 0
>> DropThreshold 2 0
>> Queue 1
>> DropThreshold 0 0
>> DropThreshold 1 0
>> DropThreshold 2 0
>> Queue 2
>> DropThreshold 0 0
>> DropThreshold 1 0
>> DropThreshold 2 0
>> Queue 3
>> DropThreshold 0 0
>> DropThreshold 1 0
>> DropThreshold 2 0
>>
>>
>>
>> On Fri, Sep 7, 2012 at 1:37 PM, gs gs <gs4me2me_at_gmail.com> wrote:
>>
>>> Yuri thanks,
>>>
>>>
>>>
>>> I agree, just my final question is how to see it? To see what marked
>>> traffic enters what ingress queues.
>>>
>>>
>>>
>>> For example let assume that we have 48 port switch, and as I can recall
>>> all ports share the same bandwidth of switch ring which is for example
>>> 16Gbps. In the same time from all ports came traffic of 500Mbps which is
>>> 24Gbps overall traffic that enters the switch, and there will be some
>>> drops, and what I want to know is any way on 3560 to see which queue is
>>> experienced that drop to further configure buffers, threshold or bandwidth
>>> ratio to save critical traffic.
>>>
>>>
>>>
>>> Is it possible on 3560 anyway?
>>>
>>>
>>> On Fri, Sep 7, 2012 at 10:13 PM, Yuri Bank <yuribank_at_gmail.com> wrote:
>>>
>>>> You can influence the ingress queue that traffic enters, such as by
>>>> doing what you're doing. The traffic gets policed and marked before
>>>> hitting the ingress queue.
>>>>
>>>> -Yuri
>>>>
>>>> On Fri, Sep 7, 2012 at 12:55 PM, gs gs <gs4me2me_at_gmail.com> wrote:
>>>> > So it means that we mark traffic on ingress interface for egress
>>>> interface?
>>>> > And cannot influence on switch in which queue will traffic go on
>>>> ingress
>>>> > interface?
>>>> >
>>>> > Thanks!
>>>> >
>>>> >
>>>> >
>>>> > On Fri, Sep 7, 2012 at 9:43 PM, Yuri Bank <yuribank_at_gmail.com> wrote:
>>>> >>
>>>> >> The packets are coming in with DSCP 46, and based on what you're
>>>> >> saying, 'show mls qos interfacce statistics' reflects this correctly.
>>>> >>
>>>> >> The order of operations is as follows:
>>>> >>
>>>> >> packet is classified as DSCP 46 (show mls qos int stats), it then
>>>> gets
>>>> >> remarked to dscp 24, and then enters the ingress queue.
>>>> >>
>>>> >> Take a look at this diagram:
>>>> >>
>>>> >>
>>>> >>
>>>> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps7078/prod_qas0900aecd805bacc7.html
>>>> >>
>>>> >> -Yuri
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Fri, Sep 7, 2012 at 11:56 AM, gs gs <gs4me2me_at_gmail.com> wrote:
>>>> >> > Marc, thanks!
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > In output you send also doesn t exist information for ingress
>>>> queues,
>>>> >> > only
>>>> >> > for egress (output queues enqueued: and output queues dropped).
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > I asking that because I have some testing and notice illogical
>>>> stuff
>>>> >> > based
>>>> >> > on what I read in documentation that marking is done before
>>>> queuing and
>>>> >> > scheduling.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12
>>>> >> > .2_58_se/configuration/guide/swqos.html#wp1157616
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > This is the scenario:
>>>> >> >
>>>> >> > SW1 trunk SW2 trunk SW3
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > From SW1 come packet with DSCP 46
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On SW2 is configuration:
>>>> >> >
>>>> >> > interface FastEthernet0/2
>>>> >> >
>>>> >> > description TO SW1
>>>> >> >
>>>> >> > switchport tr en dot1q
>>>> >> >
>>>> >> > switchport mode trunk
>>>> >> >
>>>> >> > service-policy input MATCH_ANY
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > class-map match-all MATCH_ALL
>>>> >> >
>>>> >> > match access-group name MATCH_ALL
>>>> >> >
>>>> >> > !
>>>> >> >
>>>> >> > policy-map MATCH_ALL
>>>> >> >
>>>> >> > class MATCH_ALL
>>>> >> >
>>>> >> > set ip dscp cs3
>>>> >> >
>>>> >> > !
>>>> >> >
>>>> >> > ip access-list extended MATCH_ALL
>>>> >> >
>>>> >> > permit ip any any
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > With sh mls qos int f0/2 st I see increasing counters for DSCP 46,
>>>> not
>>>> >> > for
>>>> >> > DSCP 24
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > On egress interface toward SW3 packet leaving SW2 with CoS 3, DSCP
>>>> 24
>>>> >> > which
>>>> >> > is ok.
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > So, how I can confirm that on ingress interface packet is
>>>> classified
>>>> >> > based
>>>> >> > on DSCP 24 and not on DSCP 46?
>>>> >> >
>>>> >> >
>>>> >> > On Fri, Sep 7, 2012 at 7:40 PM, marc edwards <renorider_at_gmail.com>
>>>> >> > wrote:
>>>> >> >
>>>> >> >> This is 3750 but should have same architechture. You can use:
>>>> >> >>
>>>> >> >> usscsw333idf2-1#sh mls qos interface gigabitEthernet 1/0/1
>>>> statistics
>>>> >> >> GigabitEthernet1/0/1 (All statistics are in packets)
>>>> >> >>
>>>> >> >> dscp: incoming
>>>> >> >> -------------------------------
>>>> >> >>
>>>> >> >> 0 - 4 : 17766 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 5 - 9 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 10 - 14 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 15 - 19 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 20 - 24 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 25 - 29 : 0 352235 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 30 - 34 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 35 - 39 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 40 - 44 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 45 - 49 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 50 - 54 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 55 - 59 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 60 - 64 : 0 0 0 0
>>>> >> >> dscp: outgoing
>>>> >> >> -------------------------------
>>>> >> >>
>>>> >> >> 0 - 4 : 24151 0 0 0
>>>> >> >> 16
>>>> >> >>
>>>> >> >> 5 - 9 : 0 0 0 157255
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 10 - 14 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 15 - 19 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 20 - 24 : 0 0 0 0
>>>> >> >> 20
>>>> >> >>
>>>> >> >> 25 - 29 : 0 1 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 30 - 34 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 35 - 39 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 40 - 44 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 45 - 49 : 0 4 0 2122388
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 50 - 54 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 55 - 59 : 0 0 0 0
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 60 - 64 : 0 0 0 0
>>>> >> >> cos: incoming
>>>> >> >> -------------------------------
>>>> >> >>
>>>> >> >> 0 - 4 : 373384 0 0 2
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 5 - 7 : 0 0 0
>>>> >> >> cos: outgoing
>>>> >> >> -------------------------------
>>>> >> >>
>>>> >> >> 0 - 4 : 7171779 0 0 5942
>>>> >> >> 0
>>>> >> >>
>>>> >> >> 5 - 7 : 172 8078588 4467035
>>>> >> >> output queues enqueued:
>>>> >> >> queue: threshold1 threshold2 threshold3
>>>> >> >> -----------------------------------------------
>>>> >> >> queue 0: 2 0 0
>>>> >> >> queue 1: 9043444 670498 4467547
>>>> >> >> queue 2: 0 0 0
>>>> >> >> queue 3: 0 0 5542430
>>>> >> >>
>>>> >> >> output queues dropped:
>>>> >> >> queue: threshold1 threshold2 threshold3
>>>> >> >> -----------------------------------------------
>>>> >> >> queue 0: 0 0 0
>>>> >> >> queue 1: 0 0 0
>>>> >> >> queue 2: 0 0 0
>>>> >> >> queue 3: 0 0 0
>>>> >> >>
>>>> >> >> Policer: Inprofile: 0 OutofProfile: 0
>>>> >> >>
>>>> >> >> Is this what you are looking for?
>>>> >> >>
>>>> >> >> On Fri, Sep 7, 2012 at 4:30 AM, gs gs <gs4me2me_at_gmail.com> wrote:
>>>> >> >>
>>>> >> >>> Is there any way to see on 3560 switches in which input queue
>>>> packets
>>>> >> >>> are
>>>> >> >>> placed?
>>>> >> >>>
>>>> >> >>> Like for egress queues: sh platform port-asic stats enqueue f0/1
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> Thanks
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> Blogs and organic groups at http://www.ccie.net
>>>> >> >>>
>>>> >> >>>
>>>> >> >>>
>>>> _______________________________________________________________________
>>>> >> >>> Subscription information may be found at:
>>>> >> >>> http://www.groupstudy.com/list/CCIELab.html
>>>> >> >
>>>> >> >
>>>> >> > Blogs and organic groups at http://www.ccie.net
>>>> >> >
>>>> >> >
>>>> _______________________________________________________________________
>>>> >> > Subscription information may be found at:
>>>> >> > http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Sep 07 2012 - 18:58:12 ART