From: Pavel Bykov (slidersv@gmail.com)
Date: Wed Oct 01 2008 - 00:23:02 ART
Sorry, i got carried away with the "show policy-map"... Just couple days ago
I was complaining that there is no way to see what packet fell into which
queue on the output of a switch and then I wrote this.
With the limiting of expedite queue... that I was surprised about. Should
have read the documentation - will definitely do so.
Anyway, since 400K seems to be still awfully suspicious, since default shape
of queue 1 is 1/25, and QoS is end to end, I would check all PHB's on other
equipment (e.g. traffic generator's output interface - input interface -
output interface - input interface .... - all the way to the destination)
Regards,
On Wed, Oct 1, 2008 at 3:27 AM, Hobbs <deadheadblues@gmail.com> wrote:
> Pavel, Thank you for reply:
>
> 1) According to DocCD, the PQ overrides the shaping parameter. And if you
> see in Petr's example, he has 50 on the queue 1 also. I am following Petr's
> example. Here is from the DocCD:
>
> "If the egress expedite queue is enabled, it overrides the SRR shaped and
> shared weights for queue 1."
>
>
> http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_44_se/command/reference/cli1.html#wp3281502
>
> In addition when I use this command "srr-queue bandwidth shape 0 0 0 0"
> bw is still limited to 400K. That's why I thought something else is holding
> up queue 1. But I showed you my config already of SW1 - all global mls qos
> settings are at defaults (maps, buffers, etc)
>
> 2) I let the ping run well more than 5 minutes for accurate stats. 30
> second intervals (which I have done since) makes no difference.
>
> 3) There is no policy-map on SW f0/13 - it's a switch with srr-queue
> enabled.
>
> I'm just looking for some suggestions, this is why I posted the question.
> From what I understand PQ overrides shaping parameter. Even if it wasn't and
> I put shaping at 0 to disable it, this is the latest example:
>
> SW1:
> interface FastEthernet0/13
> load-interval 30
> speed 10
> srr-queue bandwidth share 33 33 33 1
> srr-queue bandwidth shape 0 0 0 0
> priority-queue out
>
> R2:
> R2#show policy-map interface
> Ethernet0/0
>
> Service-policy input: TRACK
>
> Class-map: PREC1 (match-all)
> 67878 packets, 102767292 bytes
> 30 second offered rate 1070000 bps
> Match: ip precedence 1
>
> Class-map: PREC3 (match-all)
> 67800 packets, 102649200 bytes
> 30 second offered rate 1070000 bps
> Match: ip precedence 3
>
> Class-map: PREC5 (match-all)
> 25238 packets, 38210332 bytes
> 30 second offered rate 398000 bps
> Match: ip precedence 5
>
> Class-map: class-default (match-any)
> 184 packets, 113712 bytes
> 30 second offered rate 0 bps, drop rate 0 bps
> Match: any
> R2#
>
> I'll be the first to admit that I am doing something inconsistent, believe
> me, I want to find the solution. Right now I don't see what I am doing
> wrong.
>
> thanks
>
>
> On Tue, Sep 30, 2008 at 6:55 PM, Pavel Bykov <slidersv@gmail.com> wrote:
>
>> Hobbs.... I see a bit of missing consistency in your question.
>> 1. You set limits to 20 and 40 percent of bandwidth, which is 2M and 4M,
>> yet the shaping rate of 1st queue is 1/50, which is 200K. May I remind you
>> that the DEFAULT settings as you mentioned are "srr-queue bandwidth shape
>> 25 0 0 0", meaning that PQ (or Queue 1-1) is automatically shaped to 400K by
>> default. So You could alter bandwidth limit all you want but the shaper is
>> the limiting factor here.
>>
>> 2. Petr sent much more data - 143M, and his counters are 30s. Your
>> counters are 5 minutes. Please reduce counter timing (load-interval) on the
>> interface
>>
>> 3. You haven't posted show policy map of interface Fa 0/13 on output,
>> where the queues are located, but only on other side - the router. We should
>> look only at the switch at this point.
>>
>> So instead of overloading PREC5, try overloading PREC1 (queue 2) since
>> this is where bandwidth limit will be felt. At this point you would need to
>> change PQ shaping limit in order to see any difference.
>>
>>
>> Regards,
>>
>> --
>> Pavel Bykov
>> -------------------------------------------------
>> Stop the braindumps!
>> http://www.stopbraindumps.com/
>>
>>
>>
>> On Tue, Sep 30, 2008 at 9:47 PM, Hobbs <deadheadblues@gmail.com> wrote:
>>
>>> Thanks Petr. Here is my SW1 config. Below I have 2 examples (limit 20 and
>>> 40). Also, I think PQ may not be the issue, but rather queue 1 itself.
>>> When
>>> I disabled PQ, I was still limited to 400K...I'm running Version
>>> 12.2(25)SEE4...I wonder if this code has an internal limit on the queue.
>>> When I change R5 to be cos 3 (and this queue 3)...it can send faster (I
>>> notice the latency on pings is a lot lower too).
>>>
>>> 1) bw limit of 20, PQ enabled
>>> 2) bw limit of 40, PQ enabled
>>>
>>> 1) bw limit of 20, PQ enabled
>>>
>>> SW1#show run
>>> Building configuration...
>>>
>>> Current configuration : 1658 bytes
>>> !
>>> version 12.2
>>> no service pad
>>> service timestamps debug uptime
>>> service timestamps log uptime
>>> no service password-encryption
>>> !
>>> hostname SW1
>>> !
>>> no aaa new-model
>>> ip subnet-zero
>>> no ip domain-lookup
>>> !
>>> mls qos
>>> !
>>> !
>>> no file verify auto
>>> spanning-tree mode pvst
>>> spanning-tree extend system-id
>>> !
>>> vlan internal allocation policy ascending
>>> !
>>> !
>>> interface FastEthernet0/1
>>> mls qos cos 1
>>> mls qos trust cos
>>> !
>>> interface FastEthernet0/2
>>> !
>>> interface FastEthernet0/3
>>> mls qos cos 3
>>> mls qos trust cos
>>> !
>>> interface FastEthernet0/4
>>> !
>>> interface FastEthernet0/5
>>> mls qos cos 5
>>> mls qos trust cos
>>> !
>>> interface FastEthernet0/6
>>> !
>>> interface FastEthernet0/7
>>> !
>>> interface FastEthernet0/8
>>> !
>>> interface FastEthernet0/9
>>> !
>>> interface FastEthernet0/10
>>> !
>>> interface FastEthernet0/11
>>> !
>>> interface FastEthernet0/12
>>> !
>>> interface FastEthernet0/13
>>> load-interval 30
>>> speed 10
>>> srr-queue bandwidth share 33 33 33 1
>>> srr-queue bandwidth shape 50 0 80 0
>>> srr-queue bandwidth limit 20
>>> priority-queue out
>>> !
>>> interface FastEthernet0/14
>>> shutdown
>>> !
>>> interface FastEthernet0/15
>>> shutdown
>>> !
>>> interface FastEthernet0/16
>>> shutdown
>>> !
>>> interface FastEthernet0/17
>>> shutdown
>>> !
>>> interface FastEthernet0/18
>>> shutdown
>>> !
>>> interface FastEthernet0/19
>>> shutdown
>>> !
>>> interface FastEthernet0/20
>>> shutdown
>>> !
>>> interface FastEthernet0/21
>>> shutdown
>>> !
>>> interface FastEthernet0/22
>>> !
>>> interface FastEthernet0/23
>>> !
>>> interface FastEthernet0/24
>>> shutdown
>>> !
>>> interface GigabitEthernet0/1
>>> !
>>> interface GigabitEthernet0/2
>>> !
>>> interface Vlan1
>>> no ip address
>>> shutdown
>>> !
>>> ip classless
>>> ip http server
>>> ip http secure-server
>>> !
>>> !
>>> !
>>> control-plane
>>> !
>>> !
>>> line con 0
>>> exec-timeout 0 0
>>> logging synchronous
>>> line vty 0 4
>>> no login
>>> line vty 5 15
>>> no login
>>> !
>>> end
>>>
>>> Here is R2 the meter, PREC1 will eventually approach almost 1M: PREC3 is
>>> 125K, because I shaped it with value 80. No matter what bw limit I use,
>>> R5
>>> always is topped at 400K (moves between 396-400).
>>>
>>> R2#show policy-map interface
>>> Ethernet0/0
>>>
>>> Service-policy input: TRACK
>>>
>>> Class-map: PREC1 (match-all)
>>> 53704 packets, 81307856 bytes
>>> 5 minute offered rate 919000 bps
>>> Match: ip precedence 1
>>>
>>> Class-map: PREC3 (match-all)
>>> 6925 packets, 10484450 bytes
>>> 5 minute offered rate 124000 bps
>>> Match: ip precedence 3
>>>
>>> Class-map: PREC5 (match-all)
>>> 22281 packets, 33733434 bytes
>>> 5 minute offered rate 398000 bps
>>> Match: ip precedence 5
>>>
>>> Class-map: class-default (match-any)
>>> 139 packets, 85902 bytes
>>> 5 minute offered rate 0 bps, drop rate 0 bps
>>> Match: any
>>>
>>> 2) bw limit of 40, PQ enabled
>>>
>>> SW1(config)#int f0/13
>>> SW1(config-if)#srr-queue bandwidth limit 40
>>>
>>> Clear stats on R2, and then after a new set of pings, Q1 is chewing up
>>> the
>>> rest of the bw:
>>>
>>> R2#show policy-map interface
>>> Ethernet0/0
>>>
>>> Service-policy input: TRACK
>>>
>>> Class-map: PREC1 (match-all)
>>> 75556 packets, 114391784 bytes
>>> 5 minute offered rate 1050000 bps
>>> Match: ip precedence 1
>>>
>>> Class-map: PREC3 (match-all)
>>> 8864 packets, 13420096 bytes
>>> 5 minute offered rate 125000 bps
>>> Match: ip precedence 3
>>>
>>> Class-map: PREC5 (match-all)
>>> 28540 packets, 43209560 bytes
>>> 5 minute offered rate 399000 bps
>>> Match: ip precedence 5
>>>
>>> Class-map: class-default (match-any)
>>> 150 packets, 92700 bytes
>>> 5 minute offered rate 0 bps, drop rate 0 bps
>>> Match: any
>>>
>>>
>>> I am using all the deault mls qos settings....could it be my buffers in
>>> queue 1 holding me back? I noticed when I took of PQ, it was still at
>>> 400K...Here is my map btw
>>>
>>> SW1#show mls qos maps cos-output-q
>>> Cos-outputq-threshold map:
>>> cos: 0 1 2 3 4 5 6 7
>>> ------------------------------------
>>> queue-threshold: 2-1 2-1 3-1 3-1 4-1 1-1 4-1 4-1
>>>
>>>
>>> SW1#
>>>
>>> t
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Sep 30, 2008 at 12:46 PM, Petr Lapukhov <
>>> petr@internetworkexpert.com
>>> > wrote:
>>>
>>> > Could you post your full configuration? I just ran a quick simulation
>>> and
>>> > it works just as it usually worked for me: PQ steals all the bandwidth.
>>> E.g.
>>> > between Prec 0 and Prec 5 traffic:
>>> > interface FastEthernet0/1
>>> > speed 10
>>> > srr-queue bandwidth limit 20
>>> > priority-queue out
>>> >
>>> > Rack1R1#show policy-map interface fastEthernet 0/0
>>> > FastEthernet0/0
>>> >
>>> > Service-policy input: METER
>>> >
>>> > Class-map: PREC0 (match-all)
>>> > 23 packets, 34822 bytes
>>> > 30 second offered rate 1000 bps
>>> > Match: ip precedence 0
>>> >
>>> > Class-map: PREC5 (match-all)
>>> > 22739 packets, 34426846 bytes
>>> > 30 second offered rate 1956000 bps
>>> > Match: ip precedence 5
>>> >
>>> > If you change the speed limit to 30% the situation becomes as
>>> following:
>>> >
>>> > Rack1R1#show policy-map interface fastEthernet 0/0
>>> > FastEthernet0/0
>>> >
>>> > Service-policy input: METER
>>> >
>>> > Class-map: PREC0 (match-all)
>>> > 136 packets, 205904 bytes
>>> > 30 second offered rate 1000 bps
>>> > Match: ip precedence 0
>>> >
>>> > Class-map: PREC5 (match-all)
>>> > 96488 packets, 146082832 bytes
>>> > 30 second offered rate 2716000 bps
>>> > Match: ip precedence 5
>>> >
>>> > That is, the PQ claims all bandwidth again.
>>> >
>>> > HTH
>>> > --
>>> > Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice)
>>> > petr@internetworkexpert.com
>>> >
>>> > Internetwork Expert, Inc.
>>> > http://www.InternetworkExpert.com
>>> > Toll Free: 877-224-8987
>>> > Outside US: 775-826-4344
>>> >
>>> > 2008/9/30 Hobbs <deadheadblues@gmail.com>
>>> >
>>> >> Hello,
>>> >>
>>> >> I know this is lengthy but I am completely stumped. I have been
>>> reading
>>> >> and
>>> >> labbing some of the examples of 3560/3550 qos on IE's blog and I have
>>> run
>>> >> into some interesting issues in my lab.
>>> >>
>>> >> R1----\
>>> >> R3----[SW1]----[SW2]-----R2
>>> >> R5----/
>>> >>
>>> >> All ports set to 10M. R1=cos1, R3=cos3, R5=cos5, default cos-output-q
>>> map.
>>> >>
>>> >> R2 has a policy with classes that match precedence (1,3,5) applied to
>>> its
>>> >> interface to meter the rate of each class.
>>> >> On each router I run this command: "ping 192.168.0.2 rep 1000000 size
>>> >> 1500"
>>> >> to generate a bunch of traffic. This works great.
>>> >>
>>> >> Whenever I have priority-queue out on f0/13, cos 5 is always limited
>>> to
>>> >> 400,000K no matter if I have a "srr-queue bandwidth limit" or not. In
>>> >> addition, the other queues eat up the rest of the bandwidth (unless I
>>> >> shape
>>> >> them of course). In other words, priority queuing is NOT starving the
>>> >> other
>>> >> queues.
>>> >>
>>> >> Any other settings I need to check? From what I understand share/shape
>>> >> parameters on queue 1 don't matter when priority queue is on, and in
>>> fact
>>> >> they don' t affect it - 400K is always the limit!
>>> >>
>>> >> thanks,
>>> >>
>>> >> the blog is here for reference:
>>> >>
>>> >>
>>> http://blog.internetworkexpert.com/2008/06/26/quick-notes-on-the-3560-egress-queuing/
>>> >>
>>> >>
>>> >> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
-- Pavel Bykov ------------------------------------------------- Stop the braindumps! http://www.stopbraindumps.com/Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Nov 01 2008 - 15:35:18 ARST