OK so you think it behaves luke CBWFQ in that regard? That nakes sense, but... this can lead to underutilization of the resources.
Yeah this is so much fun :-). Endless! :-)
-- Marko Milivojevic - CCIE #18427 Senior Technical Instructor - IPexpert Free CCIE Training: http://bit.ly/vLecture Mailto: markom_at_ipexpert.com Telephone: +1.810.326.1444 Community: http://www.ipexpert.com/communities :: Sent from my phone. Apologies for errors and brevity. :: On Aug 7, 2011, at 12:43, Paul Negron <negron.paul_at_gmail.com> wrote: > You raise a valid point. I believe after having this discussion with > Wendell, we agreed that the traffic that could not be sent into a time > interval was sent in the next time interval. > > I believe I had this discussion with Narbik some time ago as well. > > I agree.:-) > QOS provides only more questions that is not backed up by documentation. > > It has been a subject that has occupied my time since I worked on StrataCom > gear, some years back. > > Enjoy the scenery man!!!! > > Paul > -- > Paul Negron > CCIE# 14856 CCSI# 22752 > Senior Technical Instructor > > > >> From: Marko Milivojevic <markom_at_ipexpert.com> >> Date: Sun, 7 Aug 2011 12:30:04 -0700 >> To: Paul Negron <negron.paul_at_gmail.com> >> Cc: gp <gs4me2me_at_gmail.com>, Carlos G Mendioroz <tron_at_huapi.ba.ar>, >> <ccielab_at_groupstudy.com> >> Subject: Re: shape on 3560 >> >> Addition of PQ on Cats completely messes things up for other queues >> and understanding what happens in them. >> >> Even without PQ in the mix, Carlos raises a valid question. Alas, one >> which is impossible to answer. >> >> He's right in saying that shaped queues get a priority in comparison >> to shared. However, this priority is only reflected in the bandwidth >> allocation part. They carve up the total available bandwidth. Whatever >> is left for allocation after shaped queues is carved up by shared >> queues. >> >> Now, when it comes to dequeueing part, this is when things are truly >> interesting. Carlos mentioned a case when the whole port is >> oversubscribed and suggested how the queues will be used. I agree and >> very much disagree with what he wrote. The problem is - it all depends >> on several things a) time interval; b) number of packets in each >> queue; c) size of each individual packet. >> >> Remember the old CIR = Bc / Tc formula. Well, it still applies. We can >> only send so many bytes in each time interval to satisfy to total >> transmission rate. >> >> Now, what happens when we oversubscribe the port *and* the queues. >> Will packet be transmitted if there are available tokens in the >> bucket, but not enough to send the packet? In, for example CQ, the >> answer is yes. in CBWFQ and HQF, the answer is no. How about SRR? >> Cisco doesn't document this (at least I couldn't find it), but this is >> important. Now, what happens if, for example, we run out of bytes in >> an interval to send due to dequeueing method used... Where does the >> next interval start? Q1, or the next queue where the previous interval >> stopped? Again, something Cisco doesn't document, but is rather >> important. >> >> Analyzing QoS is immensely fun topic to me. I think it's an essence of >> networking, but I'll stop now :-). I have some wonderful sequoia trees >> to see! >> >> -- >> Marko Milivojevic - CCIE #18427 >> Senior Technical Instructor - IPexpert >> >> FREE CCIE training: http://bit.ly/vLecture >> >> Mailto: markom_at_ipexpert.com >> Telephone: +1.810.326.1444 >> Web: http://www.ipexpert.com/ >> >> On Sun, Aug 7, 2011 at 12:04, Paul Negron <negron.paul_at_gmail.com> wrote: >>> I agree with Marko on this one. >>> >>> The Delay cannot be verified to be 40/30/30 since you cannot measure how >>> many packets from the Priority Q are actually being serviced in relation to >>> the WFQ scheduler that only spits out one packet at a time. >>> >>> Also, what delay are you referencing for a 40/30/30 share. Queuing delay >>> only? >>> >>> What about CPU, Serialization which change pending the packet size. Sure, >>> Serialization delay is almost non-existent with Ethernet designs but it is >>> still there. Thus, you cannot guarantee effective throughput. >>> >>> Paul >>> >>> -- >>> Paul Negron >>> CCIE# 14856 CCSI# 22752 >>> Senior Technical Instructor >>> >>> >>> >>>> From: gp <gs4me2me_at_gmail.com> >>>> Reply-To: gp <gs4me2me_at_gmail.com> >>>> Date: Sun, 7 Aug 2011 20:16:40 +0200 >>>> To: 'Carlos G Mendioroz' <tron_at_huapi.ba.ar>, 'Marko Milivojevic' >>>> <markom_at_ipexpert.com> >>>> Cc: <ccielab_at_groupstudy.com> >>>> Subject: RE: shape on 3560 >>>> >>>> So queue which is shaped has guaranteed bandwidth in relation to shared >>>> queues? >>>> >>>> Gp >>>> >>>> >>>> -----Original Message----- >>>> From: Carlos G Mendioroz [mailto:tron_at_huapi.ba.ar] >>>> Sent: Sunday, August 07, 2011 8:05 PM >>>> To: Marko Milivojevic >>>> Cc: gp; <ccielab_at_groupstudy.com> >>>> Subject: Re: shape on 3560 >>>> >>>> Marko, >>>> you say that all queues have guaranteed BW but not delay. >>>> I don't fully understand that. >>>> >>>> Are you saying that the delay for a packet of some class is not bounded? >>>> If not, delay is also guaranteed. >>>> >>>> If you have 3 queues, one with 50Mb shape and the other two 1/3 the BW >>>> on a 100 Mb link, anything below congestion (and below 50Mb) will be >>>> just served, but if the 3 queues try to get 40Mb, what will be the >>>> effective throughput of each ? >>>> I would say 40/30/30. >>>> >>>> -Carlos >>>> >>>> Marko Milivojevic @ 07/08/2011 14:22 -0300 dixit: >>>>> All queues are guaranteed bandwidth, but not the delay. SRR is round-robin >>>>> alghoritm. Shaped queues are assigned bandwidth first and whatever remains >>>>> is >>>>> used by shared queues, but servicing the data in queues is always equal >>>>> between all the queues. >>>>> >>>>> When you enable PQ, Q1 is serviced until empty and only then Q2-4 are >>>>> processed according to the SRR configuration and remaining bandwidth in the >>>>> time interval. >>>>> >>>>> -- >>>>> Marko Milivojevic - CCIE #18427 >>>>> Senior Technical Instructor - IPexpert >>>>> >>>>> Free CCIE Training: http://bit.ly/vLecture >>>>> >>>>> Mailto: markom_at_ipexpert.com >>>>> Telephone: +1.810.326.1444 >>>>> Community: http://www.ipexpert.com/communities >>>>> >>>>> :: Sent from my phone. Apologies for errors and brevity. :: >>>>> >>>>> >>>>> On Aug 7, 2011, at 2:42, "gp" <gs4me2me_at_gmail.com> wrote: >>>>> >>>>>> I read somewhere that shaped queue is processed before shared. >>>>>> Unfortunately >>>>>> cannot find it:) >>>>>> >>>>>> Is it possible to guaranteed some traffic bandwidth to be processed before >>>>>> other with limit in task that it cannot be mapped in priority queue >>>>>> because >>>>>> some other traffic more important is mapped to priority queue? >>>>>> >>>>>> For example: >>>>>> Q1 - traffic X - priority >>>>>> Q2 - traffic XY - less important than traffic X, more important than >>>>>> traffic >>>>>> XYZ >>>>>> Q3&Q4 - traffic XYZ >>>>>> >>>>>> >>>>>> Regards, >>>>>> Gp >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Marko Milivojevic [mailto:markom_at_ipexpert.com] >>>>>> Sent: Saturday, August 06, 2011 10:46 PM >>>>>> To: gp >>>>>> Cc: ccielab_at_groupstudy.com >>>>>> Subject: Re: shape on 3560 >>>>>> >>>>>> Sharing and shaping has nothing to do with priority queueing. I.e. >>>>>> shaped traffic is not processed before shared - it's only limited to >>>>>> certain percentage of the traffic, while shared queues are simply >>>>>> guaranteed a minimum. >>>>>> >>>>>> You can configure shaping as a percentage of negotiated speed, of >>>>>> course. By default 100% of interface bandwidth (negotiated speed) is >>>>>> available for all queues. If you want to limit Q2 to say, 33% you can >>>>>> configure it as "srr-queue bandwidth shape 0 3 0 0". However, if you >>>>>> want to limit it to say 5 Mb/s REGARDLESS of the negotiated speed, >>>>>> this cannot be done on 3560, as this is a policing and policing is not >>>>>> available in the outbound direction on 3560. >>>>>> >>>>>> -- >>>>>> Marko Milivojevic - CCIE #18427 >>>>>> Senior Technical Instructor - IPexpert >>>>>> >>>>>> FREE CCIE training: http://bit.ly/vLecture >>>>>> >>>>>> Mailto: markom_at_ipexpert.com >>>>>> Telephone: +1.810.326.1444 >>>>>> Web: http://www.ipexpert.com/ >>>>>> >>>>>> On Sat, Aug 6, 2011 at 13:19, gp <gs4me2me_at_gmail.com> wrote: >>>>>>> Thank you Marko for explanation, it helps. >>>>>>> >>>>>>> What confusing me if I have a task to guaranteed some traffic for example >>>>>>> 10Mbps on giga interface on switch, and I cannot use priority queue, so I >>>>>>> want to send that traffic before packet in shared queue in way to put it >>>>>>> in >>>>>>> shaped queue which will be served before shared queues. >>>>>>> >>>>>>> The problem is that I donb t know what type of interface will be >>>>>>> connected >>>>>>> to my switch (1Gbps or 100M) and that is value from which will be >>>>>>> calculated value for shaping on particular queue. >>>>>>> >>>>>>> For example: >>>>>>> Negotiated speed = 1Gbps >>>>>>> Srr-queue bandwidth shape 0 100 0 0 >>>>>>> Queue 2 will be shaped to 100Mbps >>>>>>> >>>>>>> Negotiated speed = 100Mbps >>>>>>> Srr-queue bandwidth shape 0 100 0 0 >>>>>>> Queue 2 will be shaped to 10Mbps >>>>>>> >>>>>>> In other way as I understand there is no way to hard code shape value >>>>>>> regarding to negotiated speed? >>>>>>> >>>>>>> Regards, >>>>>>> Gp >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Marko Milivojevic [mailto:markom_at_ipexpert.com] >>>>>>> Sent: Saturday, August 06, 2011 7:42 PM >>>>>>> To: gp >>>>>>> Cc: ccielab_at_groupstudy.com >>>>>>> Subject: Re: shape on 3560 >>>>>>> >>>>>>> It will be using the bandwidth available to the SRR. >>>>>>> >>>>>>> Cat2#sh mls qos interface fa0/18 queueing >>>>>>> FastEthernet0/18 >>>>>>> Egress Priority Queue : disabled >>>>>>> Shaped queue weights (absolute) : 25 0 0 0 >>>>>>> Shared queue weights : 25 25 25 25 >>>>>>> The port bandwidth limit : 100 (Operational Bandwidth:100.0) <<<<<<< >>>>>>> The port is mapped to qset : 1 >>>>>>> >>>>>>> See the "port bandwidth limit" line - that's the BW available to the >>>>>>> SRR. It is derived from the negotiated speed by default, but can be >>>>>>> limited using "srr-queue bandwidth limit" command on the interface. >>>>>>> >>>>>>> Now, let's see if configured bandwidth influences this in any way: >>>>>>> >>>>>>> interface FastEthernet0/18 >>>>>>> bandwidth 50000 >>>>>>> ! >>>>>>> >>>>>>> Cat2(config-if)#do sh mls qos int fa0/18 qu >>>>>>> FastEthernet0/18 >>>>>>> Egress Priority Queue : disabled >>>>>>> Shaped queue weights (absolute) : 25 0 0 0 >>>>>>> Shared queue weights : 25 25 25 25 >>>>>>> The port bandwidth limit : 100 (Operational Bandwidth:100.0) >>>>>>> The port is mapped to qset : 1 >>>>>>> >>>>>>> Doesn't look like it does. If I change the bandwidth limit. >>>>>>> >>>>>>> interface FastEthernet0/18 >>>>>>> bandwidth 50000 >>>>>>> srr-queue bandwidth limit 25 >>>>>>> ! >>>>>>> >>>>>>> Cat2(config-if)#do sh mls qos int fa0/18 qu >>>>>>> FastEthernet0/18 >>>>>>> Egress Priority Queue : disabled >>>>>>> Shaped queue weights (absolute) : 25 0 0 0 >>>>>>> Shared queue weights : 25 25 25 25 >>>>>>> The port bandwidth limit : 25 (Operational Bandwidth:27.28) >>>>>>> The port is mapped to qset : 1 >>>>>>> >>>>>>> Whenever in doubt - ask IOS :-) >>>>>>> >>>>>>> -- >>>>>>> Marko Milivojevic - CCIE #18427 >>>>>>> Senior Technical Instructor - IPexpert >>>>>>> >>>>>>> FREE CCIE training: http://bit.ly/vLecture >>>>>>> >>>>>>> Mailto: markom_at_ipexpert.com >>>>>>> Telephone: +1.810.326.1444 >>>>>>> Web: http://www.ipexpert.com/ >>>>>>> >>>>>>> On Sat, Aug 6, 2011 at 01:18, gp <gs4me2me_at_gmail.com> wrote: >>>>>>>> Hello experts, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> When doing shaping on 3560 interface does reference bandwidth is >>>>>>>> configured >>>>>>>> bandwidth with bandwidth command or negotiated speed? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For example the switch port is connected on Fast Ethernet router >>>>>>>> interface >>>>>>>> and I configured bandwidth 1000000 on switch port. >>>>>>>> >>>>>>>> With srr-queue bandwidth shape 0 100 0 0, will queue 2 be shaped on 10 >>>>>>>> or >>>>>>>> 1 >>>>>>>> Mbps? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> >>>>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina >>>> >>>> >>>> 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.netReceived on Sun Aug 07 2011 - 12:46:01 ART
This archive was generated by hypermail 2.2.0 : Thu Sep 01 2011 - 06:05:56 ART