From: Bob Sinclair (bsinclair@netmasterclass.net)
Date: Mon Nov 14 2005 - 15:53:16 GMT-3
Hi Kevin,
If I am reading your output correctly, it actually seems to be saying that
all traffic is being dropped. Perhaps it is because you are generating so
much traffic and the prioritized traffic is so low. Or maybe it behaves
differently when the traffic is generated on the same box that has the policy.
In any case, the answer is in the IOS, and I applaud you for actually labbing
it up.
I redid my test as shown below and got the predicted results. One difficulty
is coming up with a predictable traffic stream using a simple ping. Here is
my try:
C3550------10Mbps-FA--------R1-----128Kbps Serial-----R2 -----2Mbps
Serial-----R4-----10Mbps Eth-----R6
With the topology above, I generate pings on C3550 to R6. The serial link
R1-R2 turns the c3550 pings into a fairly predictdable 128K flow.
My policy is applied outbound on R4 E0 as follows:
R4#sh access-l
Extended IP access list 101
permit icmp any any (20374 matches
R4#sh policy-map int
Ethernet0
Service-policy output: POLICY (1045)
Class-map: ICMP (match-all) (1047/2)
18000 packets, 25445500 bytes
30 second offered rate 128000 bps, drop rate 0 bps
Match: access-group 101 (1051)
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 64 (kbps) Burst 1600 (Bytes)
(pkts matched/bytes matched) 3/2942
(total drops/bytes drops) 0/0
Class-map: class-default (match-any) (1055/0)
495 packets, 43683 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any (1059)
Here is the flow coming in R4 S1:
R4#sh int s1 | inc input rate
5 minute input rate 128000 bits/sec, 11 packets/sec
Here is the flow going out R4 E0:
R4#sh int e0 | inc output rate
30 second output rate 129000 bits/sec, 11 packets/sec
And here is the flow arriving on R6 E0:
R6#sh int e0 | inc input rate
30 second input rate 129000 bits/sec, 11 packets/sec
So, It looks to me like R4 is allowing 128K, even though it has priority set
to 64.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427
www.netmasterclass.net
----- Original Message -----
From: kevin gannon
To: Bob Sinclair
Cc: simon hart ; ccielab@groupstudy.com
Sent: Monday, November 14, 2005 11:50 AM
Subject: Re: Priority Queuing question
Not sure if its a valid test but I used the simple config below:
class-map match-all ANY
match access-group 188
!
!
policy-map PQ
class ANY
priority 8
!
interface FastEthernet0/1
ip address 11.11.11.33 255.255.255.0
service-policy output PQ
max-reserved-bandwidth 100
Then I do a "ping 11.11.11.1 size 1800 timeout 0 repeat 99999" on
the saeme router and I see that traffic if being dropped. However
the offered rate is below 100Mb/s and I am seeing drops the ethernet
policy. Am I missing something ?
R3#show policy-map int f 0/1
FastEthernet0/1
Service-policy output: PQ
Class-map: ANY (match-all)
164366 packets, 151874184 bytes
30 second offered rate 7135000 bps, drop rate 7135000 bps
Match: access-group 188
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 8 (kbps) Burst 200 (Bytes)
(pkts matched/bytes matched) 164366/151874184
(total drops/bytes drops) 164366/151874184
Class-map: class-default (match-any)
215 packets, 20158 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any
R3#
I rember that the behaviour changed somewhere in 12.1 I think.
Maybe someone could clarify ?
Thanks & Regards
Kevin
On 11/14/05, Bob Sinclair <bsinclair@netmasterclass.net> wrote:
> Simon,
>
> Perhaps I misunderstood your comment, but just to be clear: the MQC
priority
> command will police prioritized flows only under conditions of
congestion.
> But the flows will take all the bandwidth they require otherwise. As long
as
> the bandwidth is available, the priority command does not police. If
you
> want to set a hard cap on prioritized traffic, you will need to add a
police
> command. Some (othterwise) very good documentation is wrong on this
point.
> Try labbing it up.
>
> HTH,
>
> Bob Sinclair
> CCIE #10427, CCSI 30427
> www.netmasterclass.net
>
> ----- Original Message -----
> From: simon hart
> To: steven richards ; ccielab@groupstudy.com
> Sent: Monday, November 14, 2005 10:37 AM
> Subject: RE: Priority Queuing question
>
>
> Hi Steven,
>
> The commands below will guarantee 128kbps and no more, there is no
burst
> above 128kbps.
>
> The priority command has two functions, one is to prioritise the
packets
> assigned to this queue, that is they will be the first out of the
> interface.
> The second function is to police the packets to the bandwidth required.
>
> Now the show policy map
>
> Bandwidth 128 (kbps) Burst 3200 (Bytes)
>
> is showing you what the committed burst rate is, not the excess burst.
>
> MQC tc in this scenario defaults to 200ms, therefore 128000 *.2 =
25600.
> Convert to bytes 25600 /8 = 3200 bytes. Therefore for each 200ms, the
> policer will allow 25600 bits to be sent, and thus 128kbps no more no
less
>
> HTH
>
> Simon
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> steven richards
> Sent: 14 November 2005 04:34
> To: ccielab@groupstudy.com
> Subject: Priority Queuing question
>
>
> Hello,
>
> I am trying to use priority queueing beacuse I am interested in
guarenteing
> a certain amount of bandwidth, withought going over the guereenteed
> bandwidth. One thing I noticed is that with configuring priority
queueing
> there appears to be a burst automatically configured. Is there a way to
> just
> configure priority queueing withought that autoconfugred burst ?
>
> Thanks,
>
>
>
> R2#show policy-map interface e0/0
> Ethernet0/0
>
> Service-policy output: QOS
>
> Class-map: PREC2 (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: ip precedence 2
> Queueing
> Strict Priority
> Output Queue: Conversation 264
> Bandwidth 128 (kbps) Burst 3200 (Bytes) <----- Burst
automatically
> configured ?
> (pkts matched/bytes matched) 0/0
> (total drops/bytes drops) 0/0
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's
FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.0/167 - Release Date:
11/11/2005
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.362 / Virus Database: 267.13.0/167 - Release Date:
11/11/2005
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:06 GMT-3