Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Few questions regarding QOS

Hello All, I do really need a help on understanding some points on QOS. Given the below configuration

---------

R1#sh run policy-map COS-OUT-SHAPED-Gi0/0.15

Building configuration...

Current configuration : 124 bytes

!

policy-map COS-OUT-SHAPED-Gi0/0.15

class class-default

  shape average 6000000

  service-policy COS-OUT-Gi0/0.15

!

end

R1#sh run policy-map COS-OUT-Gi0/0.15

Building configuration...

Current configuration : 454 bytes

!

policy-map COS-OUT-Gi0/0.15

class DSCP-OUT-RT               <<<<<<<< Voice class

  priority 2448 307000

  police 2456000 307000 307000 conform-action set-dscp-transmit 46 exceed-action drop  violate-action drop

class DSCP-OUT-D1

  bandwidth remaining percent 60

     random-detect dscp-based aggregate

     random-detect exponential-weighting-constant 9

     random-detect dscp values 26 minimum-thresh 39 maximum-thresh 117 mark-prob 20

     random-detect dscp values 28 minimum-thresh 19 maximum-thresh 38 mark-prob 20

  service-policy COS-OUT-D1-Gi0/0.15   <<<< Those are just remarking service-policy so no big deal

class DSCP-OUT-D2

  bandwidth remaining percent 30

    random-detect dscp-based aggregate

    random-detect exponential-weighting-constant 9

    random-detect dscp values 18 minimum-thresh 61 maximum-thresh 122 mark-prob 20

    random-detect dscp values 20 minimum-thresh 34 maximum-thresh 68 mark-prob 20

  service-policy COS-OUT-D2-Gi0/0.15

class DSCP-OUT-D3

  bandwidth remaining percent 9

     random-detect dscp-based aggregate

     random-detect exponential-weighting-constant 9

     random-detect dscp values 10 minimum-thresh 78 maximum-thresh 156 mark-prob 20

     random-detect dscp values 12 minimum-thresh 51 maximum-thresh 102 mark-prob 20

  service-policy COS-OUT-D3-Gi0/0.15

!

end

-----------

Now my questions

1 - If customer is sending Data traffic with rate over 6 Mg will voice traffic be impacted or not ?

2 - Given the WRED parameters above or any other WRED just the concept , now if let's say D3 starts sending traffic with rate above 9 % of bandwidth Cisco allows it to be granted more bandwidth if there are available bandwidth in the other classes ... so my question is when will WRED mechanism gets triggered and starts dropping random packets ... or also in other words  minimum-thresh 78 .. The number 78 what's this number exactly a function of.

Everyone's tags (1)
16 REPLIES

Few questions regarding QOS

Hello.

Could you please provide sh policy-map int ... out to see exact values applied per class?

My concern is "priority 2448 307000" (why do you need this burst size?) and "shape average 6000000" without bc value (could lead to longTc, as a result voice could be delayed -> jitter).

In general:

1) Voice won't be impacted unless it's trying to consume more than 2.4M

2) minimum-threshold is about mean queue length, as far as packets are leaving the queue fast enough and mean queue length does not reach min-threshold (and queue size if big enough), WRED won't affect traffic flow.

mean/average queue length is calculated as:

http://upload.wikimedia.org/math/f/7/8/f78b99c3acdfd943b83065ffc323b6ca.png

o - is old (previous calculation) mean value;

c - current queue size;

n - exponential weight.

New Member

Re: Few questions regarding QOS

Hello Mikhailovsky, Thanks alot for your feedback ... below is the output of the show policy-map interface command.

Now the point in our scenario here for voice class

Shaping Tc = 4 msec ? and that during congestion can hold voice packets long enough in the shaping queue to be delayed .. I also agree that Tc = 1 second for voice is pretty high

R1#show policy-map interface GigabitEthernet0/0.15 out

GigabitEthernet0/0.15

  Service-policy output: COS-OUT-SHAPED-Gi0/0.15

    Class-map: class-default (match-any)

      1092335700 packets, 164159193029 bytes

      30 second offered rate 109000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/443958/0

      (pkts output/bytes output) 1091892062/163408460116

      shape (average) cir 6000000, bc 24000, be 24000

      target shape rate 6000000

      Service-policy : COS-OUT-Gi0/0.15

        queue stats for all priority classes:

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/0/0

          (pkts output/bytes output) 681873638/53435643102

        Class-map: DSCP-OUT-RT (match-any)

          681873638 packets, 53432399602 bytes

          30 second offered rate 64000 bps, drop rate 0 bps

          Match: access-group name DSCP-OUT-RT

            23864233 packets, 1916592950 bytes

            30 second rate 0 bps

          Match: ip dscp ef (46)

            658009382 packets, 51515804418 bytes

            30 second rate 64000 bps

          Priority: 2448 kbps, burst bytes 307000, b/w exceed drops: 0

          police:

              cir 2456000 bps, bc 307000 bytes, be 307000 bytes

            conformed 681873642 packets, 53435645360 bytes; actions:

              set-dscp-transmit ef

            exceeded 0 packets, 0 bytes; actions:

              drop

            violated 0 packets, 0 bytes; actions:

              drop

            conformed 64000 bps, exceed 0 bps, violate 0 bps

        Class-map: DSCP-OUT-D1 (match-any)

          18992406 packets, 3318131662 bytes

          30 second offered rate 0 bps, drop rate 0 bps

          Match: ip dscp af31 (26)

            18992405 packets, 3318131662 bytes

            30 second rate 0 bps

          Match: ip dscp af32 (28)

            0 packets, 0 bytes

            30 second rate 0 bps

          Queueing

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/2797/0

          (pkts output/bytes output) 18989609/3314687455

          bandwidth remaining 60% (2131 kbps)

          Service-policy : COS-OUT-D1-Gi0/0.15

            Class-map: DSCP-OUT-D1INP (match-all)

              18988005 packets, 3317788384 bytes

              30 second offered rate 0 bps, drop rate 0 bps

              Match: not access-group name DSCP-OUT-SAA

              Match: ip dscp af31 (26)

              police:

                  cir 2136000 bps, bc 267000 bytes, be 267000 bytes

                conformed 18950041 packets, 3264424529 bytes; actions:

                  transmit

                exceeded 8188 packets, 11423065 bytes; actions:

                  set-dscp-transmit af32

                violated 29776 packets, 41940790 bytes; actions:

                  set-dscp-transmit af32

                conformed 0 bps, exceed 0 bps, violate 0 bps

            Class-map: class-default (match-any)

              4401 packets, 343278 bytes

              30 second offered rate 0 bps, drop rate 0 bps

              Match: any

        Class-map: DSCP-OUT-D2 (match-any)

          8350015 packets, 9847058982 bytes

          30 second offered rate 13000 bps, drop rate 0 bps

          Match: ip dscp af21 (18)

            8350015 packets, 9847058982 bytes

            30 second rate 13000 bps

          Match: ip dscp af22 (20)

            0 packets, 0 bytes

            30 second rate 0 bps

          Queueing

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/0/0

          (pkts output/bytes output) 8350015/9614261592

          bandwidth remaining 30% (1065 kbps)

          Service-policy : COS-OUT-D2-Gi0/0.15

            Class-map: DSCP-OUT-D2INP (match-all)

              8349659 packets, 9847029098 bytes

              30 second offered rate 13000 bps, drop rate 0 bps

              Match: not access-group name DSCP-OUT-SAA

              Match: ip dscp af21 (18)

              police:

                  cir 1072000 bps, bc 134000 bytes, be 134000 bytes

                conformed 8346224 packets, 9609038478 bytes; actions:

                  transmit

                exceeded 1783 packets, 2692330 bytes; actions:

                  set-dscp-transmit af22

                violated 1652 packets, 2494520 bytes; actions:

                  set-dscp-transmit af22

                conformed 13000 bps, exceed 0 bps, violate 0 bps

            Class-map: class-default (match-any)

              356 packets, 29884 bytes

              30 second offered rate 0 bps, drop rate 0 bps

              Match: any

        Class-map: DSCP-OUT-D3 (match-any)

          228837546 packets, 85332347392 bytes

          30 second offered rate 9000 bps, drop rate 0 bps

          Match: ip dscp af11 (10)

            228837207 packets, 85332100294 bytes

            30 second rate 9000 bps

          Match: ip dscp af12 (12)

            339 packets, 247036 bytes

            30 second rate 0 bps

          Queueing

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/440737/0

          (pkts output/bytes output) 228396809/84798625289

          bandwidth remaining 9% (319 kbps)

          Service-policy : COS-OUT-D3-Gi0/0.15

            Class-map: DSCP-OUT-D3INP (match-all)

              225991869 packets, 85098183768 bytes

              30 second offered rate 8000 bps, drop rate 0 bps

              Match: not access-group name DSCP-OUT-SAA

              Match: ip dscp af11 (10)

              police:

                  cir 320000 bps, bc 40000 bytes, be 40000 bytes

                conformed 190569143 packets, 35751650461 bytes; actions:

                  transmit

                exceeded 1607999 packets, 2160593173 bytes; actions:

                  set-dscp-transmit af12

                violated 33814727 packets, 47185940134 bytes; actions:

                  set-dscp-transmit af12

                conformed 8000 bps, exceed 0 bps, violate 0 bps

            Class-map: class-default (match-any)

              2845677 packets, 234163624 bytes

              30 second offered rate 0 bps, drop rate 0 bps

              Match: any

        Class-map: class-default (match-any)

          154282420 packets, 12229309004 bytes

          30 second offered rate 21000 bps, drop rate 0 bps

          Match: any

          queue limit 64 packets

          (queue depth/total drops/no-buffer drops) 0/424/0

          (pkts output/bytes output) 154281997/12245241200

Few questions regarding QOS

Hello.

I guess 4ms for parent class is good; I would say that even 10ms is good.

I would say that 307,000 bytes for bc is a really high value. Not sure why is it in use... it might be some logic behind?!!

But it says, that on the link of 6M voice could solely allocate whole link for 400 ms and then send no traffic for 600 ms! I'm not sure that you are expecting such a behavior!

I think, that for voice class, Tc could be about 20 ms.

Not sure why do you need be for policer, if exceed action is drop (monitoring?)

New Member

Few questions regarding QOS

MikhailovskyVV wrote:

Not sure why do you need be for policer, if exceed action is drop (monitoring?)

I don't see why there's a policer in DSCP-OUT-RT in the first place. It can never match (priority is already policing the excess traffic). If it's there to just force the DSCP to EF, wouldn't it be more readable to use a set statement? Unless, of course, I know nothing about the hardware platform and this is black magic which performs better on certain metal^Wsilicon.

Confused,

Andre.

Super Bronze

Re: Few questions regarding QOS

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

abpsoft wrote:

MikhailovskyVV wrote:

Not sure why do you need be for policer, if exceed action is drop (monitoring?)

I don't see why there's a policer in DSCP-OUT-RT in the first place. It can never match (priority is already policing the excess traffic). If it's there to just force the DSCP to EF, wouldn't it be more readable to use a set statement? Unless, of course, I know nothing about the hardware platform and this is black magic which performs better on certain metal^Wsilicon.

Confused,

Andre.

Actually, on many platforms the implicit policer only polices against packets being queued in the LLQ, not just passing through the LLQ class.

New Member

Few questions regarding QOS

I believe the main role of the policer is to avoid voice packets from exceeding their bandwidth even if the other classes for data are empty.... Am not sure why was it configured to have priority also performing bandwidth restrictions while it's already there in the policing command.

My main question was by any mean could data traffic cause packet drops to voice if user is bursting very large chunk of data traffic ... by theory this should never happen ... i want to confirm the theory part am i correct on this ... or in other words can the shapping buffer get full and start dropping packets regardless if they're voice or not ?

Super Bronze

Re: Few questions regarding QOS

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

In theory, data volume shouldn't ever be adverse to VoIP, with your policy construct.  But, in practice, it may.  (I read your OP as you were asking about "real world".)

Few questions regarding QOS

Hello, Ahmed.

What is the platform/IOS you are using (sh ver)?

@abpsoft, "priority" will drop traffic in case of congestion, but will send in other case. So, "priority" is not allowing to limit maximum bandwidth - that is why we need policer.

New Member

Re: Few questions regarding QOS

MikhailovskyVV wrote:

@abpsoft, "priority" will drop traffic in case of congestion, but will send in other case. So, "priority" is not allowing to limit maximum bandwidth - that is why we need policer.

Ah yep. Joseph and Ahmed stated the same. I remembered that wrongly - I was under the impression that priority comes with a built-in hard dropping policer. But it's just a starvation protector in that it will drop only during congestion and otherwise just pass traffic (without ensuring LLQ). In the words of the docs:

In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested.

Thanks for clearing my confusion and sorry for the sidetracking,

Andre.

Super Bronze

Re: Few questions regarding QOS

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

#1 "It depends"

on such as:

Why are you shaping?  (I.e. what's downstream that you're shaping for?)

Is the send 6 Mbps at L2 or L3, and which is the shaper counting?

What is the Bc/Tc, and does that matter (which it often does for VoIP)?

What's the tx-ring fifo queue set to?

Does the shaper manage any queues other than the child policy's?

Is the IOS implemenation working correctly?

#2 WRED looks as a moving average of number of packets in queue when it's about to add another packet to queue.  If adding the packet, places the moving average into the min..max or greater than max ranges, then WRED does its "thing".  (Since WRED uses moving averages, in theory, in could tail drop a new packet even though the queue is physically empty or not consider it for drop even though actually queue depth is way beyond max.

New Member

Few questions regarding QOS

Hello Joseph,

I just want to really understand this for the WRED part ... consider for instance i had bandwidth command on D3 class set that D3 queue gets bandwidth 3 Mb/s and the whole link bandwidth is 10 Mb/s ... what happens if the link is clear and no other data classes are sending traffic , as Cisco say this class can take bandwidth from other classes ... in my practical experience i get to see the case where the class D3 sends up to 7 Mb/s or even more with no WRED drops and sometimes you get it sending at 4 Mb/s and getting drops....

So how does the WRED knows the total link utilization and how does it calculate the queue size itself to determine it's threshold

Thanks alot for your previous reply

Super Bronze

Re: Few questions regarding QOS

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

In answer to your question about no drops at 7 Mbps but drops at 4 Mbps, that's because WRED is tracking queue depths down at the millisecond level and your "7 Mbps" or "4 Mbps" is over what time interval?

Basically, microsbursts can lead to drops while longer term bandwidth utilization shows far from 100% utilization.  If fact, if there's enough microburst dropping, the drops may drive down the average bandwidth utilization.  (BTW, in theory, with straight FIFO, you can have no drops at 100% utilization, while at a 1% utilization have a 99% drop rate.  [I normally don't rant on the subject, how useless measuring bandwidth utilization, alone, is.])

Re: Few questions regarding QOS

BTW, in theory, with straight FIFO, you can have no drops at 100% utilization, while at a 1% utilization have a 99% drop rate.  [I normally don't rant on the subject, how useless measuring bandwidth utilization, alone, is.])

Joseph, sorry to sound stupid, I'm having trouble understanding this. That at microbursts, could you possible explain this further?

Thanks in advance, I really appreciate it.

Super Bronze

Re: Few questions regarding QOS

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

John, question is not stupid.

What I think you're asking about, bandwidth vs drops, isn't related to microbursts.

Imagine a router with only two interfaces, same bandwidth.  As ingress bandwidth cannot exceed egress bandwidth, 100% in would be 100% out, i.e. no queuing on egress.  So, we show 100% bandwidth utilization, but that's bad, right?

Now imagine a switch with 100 (10 Mbps) Ethernet interfaces and with one 10g Ethernet interface.  Further imagine the 10g interface only has a queue/buffer of 1.  Lastly, imagine a frame/packet arrives on all 100 Ethenet intefaces at the same time.  (Not likely in real world, but concept is important.)  10g interface can only buffer 1 frame/packet, everything else is discarded.  So, we show, on 10g interface, only 1% bandwidth utilization, so that's good, right?

Re: Few questions regarding QOS

Joseph,

Thanks fo the reply, that makes complete sense. For instance, if I have 10 (10Mbps) ports, on Switch A, and

a one Gigabit Ethernet port going to Switch B as an uplink. No the output queue on this Gigabit Ethernet port

has only queue1, that has a queue_depth of 1. If they all send at the same time, it wil send one, and if it's running

FIFO will drop the rest. So from that ports point of view (The one Gigabit Ethernet) port, will show 10 percent

utilization. So if you're looking at the interface statistics, you thinking, man, that port isn't being hit that hard, which

is completely untrue, unless you look at the drops which should show.

I hope I got that right.

Super Bronze

Re: Few questions regarding QOS

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Thanks fo the reply, that makes complete sense. For instance, if I have 10 (10Mbps) ports, on Switch A, and

a one Gigabit Ethernet port going to Switch B as an uplink. No the output queue on this Gigabit Ethernet port

has only queue1, that has a queue_depth of 1. If they all send at the same time, it wil send one, and if it's running

FIFO will drop the rest. So from that ports point of view (The one Gigabit Ethernet) port, will show 10 percent

utilization. So if you're looking at the interface statistics, you thinking, man, that port isn't being hit that hard, which

is completely untrue, unless you look at the drops which should show.

I hope I got that right.

You got it exactly right!!!

Consider another situation.  You show 10% utilization and no drops in case where you have  a gig LAN interface which connects to a router with 1 Mbps WAN interface.  When you see 10% utilization (of the WAN interface) across, say, 5 minutes, is it 1 packet every 1/10 of 5 minutes, i.e. one packet every 30 seconds, or continuous packets (a microsburst), for 100,000 bits, at gig, that queue up and are transmitted for 30 seconds, and then no more for the remaining 4 minutes and 30 seconds?  So, with 10% utilization and no drops, again, everything is okay?

PS:

"There are lies, damned lies, and statistics." - Mark Twain

PPS:

Actually, statistics can be useful, if you really understand what they are telling you.

521
Views
15
Helpful
16
Replies
CreatePlease login to create content