From: Hobbs (deadheadblues@gmail.com)
Date: Tue Sep 30 2008 - 22:27:42 ART
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."
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
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sat Oct 04 2008 - 09:26:20 ART