[j-nsp] FW: strict-high priority queue
Harry Reynolds
harry at juniper.net
Wed Jun 14 12:03:05 EDT 2006
Yes, this might be best.
I get the same commit error with 7.6, but did not realize you had
altered the weight of other classes.
A am considering a PR that results in any configured weight on a SH
queue to be reset to 0, as I have yet to see a good reason for allowing
other than 0.
The general concensous so far is that tech pubs is correct and that SH
should not have a tx-rate set.
Regards
> -----Original Message-----
> From: Eric Van Tol [mailto:eric at atlantech.net]
> Sent: Wednesday, June 14, 2006 8:54 AM
> To: Harry Reynolds; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] FW: strict-high priority queue
>
> Harry, the config does spit out an error if I commit and the
> configured rates are over 100%. However, I had modified the
> be-class queue to use less of a percentage so that all 4
> queues added up to 100%. Unless I'm misinterpreting what
> you're saying, I don't think that was the issue.
> It looks like I might have to open up a JTAC case on this one
> - I wouldn't want you wasting your time troubleshooting this
> if JTAC can do it.
>
> Also, cosd logs don't show anything unusual to me. Just a
> bunch of these about once or twice a day:
>
> Jun 14 10:47:48 main: Detected non-fabric-based chassis Jun
> 14 10:47:48 main: started: check=1, nuke=0 pid=24161 Jun 14
> 10:47:48 read net.link.agg.ae_max_links 8
>
> Thanks,
> evt
>
> -----Original Message-----
> From: Harry Reynolds [mailto:harry at juniper.net]
> Sent: Wednesday, June 14, 2006 11:41 AM
> To: Eric Van Tol; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] FW: strict-high priority queue
>
> Still looking into this. Word back from folks smarter than me
> is that you have exceeded 100% rate total when setting the SH
> class above 35%, which then results in a failure to load the
> configured cos settings, which in turn is like having default cos.
>
> You may want to search the messages log matching on "cosd" to
> see if there are messages that your config is invalid.
>
> It seems that newer code, 8.0B2 for example, will reject such
> a config at commit:
>
>
> [edit class-of-service]
> harry at moe# commit check
> configuration check succeeds
>
> [edit class-of-service]
> harry at moe# show
> drop-profiles {
> non-tcp-low-red {
> fill-level 80 drop-probability 10;
> }
> tcp-high-red {
> fill-level 50 drop-probability 10;
> }
> tcp-low-red {
> fill-level 40 drop-probability 10;
> }
> non-tcp-high-red {
> fill-level 30 drop-probability 30;
> }
> }
> interfaces {
> so-0/0/0 {
> scheduler-map test;
> }
> }
> scheduler-maps {
> test {
> forwarding-class best-effort scheduler be-scheduler;
> forwarding-class network-control scheduler nc-scheduler;
> forwarding-class assured-forwarding scheduler af-scheduler;
> forwarding-class expedited-forwarding scheduler ef-scheduler;
> }
> }
> schedulers {
> be-scheduler {
> transmit-rate percent 50;
> buffer-size percent 50;
> priority low;
> drop-profile-map loss-priority low protocol non-tcp
> drop-profile non-tcp-low-red;
> drop-profile-map loss-priority high protocol tcp
> drop-profile tcp-high-red;
> drop-profile-map loss-priority low protocol tcp
> drop-profile tcp-low-red;
> drop-profile-map loss-priority high protocol non-tcp
> drop-profile non-tcp-high-red;
> }
> nc-scheduler {
> transmit-rate percent 5;
> buffer-size percent 5;
> priority high;
> }
> af-scheduler {
> transmit-rate percent 10;
> buffer-size percent 5;
> priority high;
> }
> ef-scheduler {
> transmit-rate percent 35;
> buffer-size percent 5;
> priority strict-high;
> }
> }
>
> [edit class-of-service]
> harry at moe# set schedulers ef-scheduler transmit-rate percent 40
>
> [edit class-of-service]
> harry at moe# commit check
> [edit class-of-service]
> 'scheduler-maps test'
> Total bandwidth allocation exceeds 100 percent for
> scheduler-map test
> error: configuration check-out failed
>
>
> [edit class-of-service]
> harry at moe# run show version
> Hostname: moe
> Model: m5
> JUNOS Base OS boot [8.0B2]
> JUNOS Base OS Software Suite [8.0B2]
> JUNOS Kernel Software Suite [8.0B2]
> JUNOS Packet Forwarding Engine Support (M5/M10) [8.0B2]
> JUNOS Routing Software Suite [8.0B2]
> JUNOS Online Documentation [8.0B2]
>
>
> I am loading up 7.6R2 in an attempt to verify if it allows
> the commit of
> a config in which explicit SH tx-rate results in > 100% weights being
> assigned.
>
>
> Regards
>
>
>
>
>
>
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> Eric Van Tol
> > Sent: Wednesday, June 14, 2006 7:37 AM
> > To: juniper-nsp at puck.nether.net
> > Subject: Re: [j-nsp] FW: strict-high priority queue
> >
> > Thanks, Harry. I'm on an M20 running 7.5R2.8 and found that
> > when modifying the strict-high queue's transmit-rate
> > percentage above 35%, the queue would suddenly start dropping
> > packets. My strict-high queue is configured for
> > expedited-forwarding of voice traffic and even with only a
> > single 80k G.711 stream, the strict-high would drop packets
> > if configured at 40% transmit-rate. The ef-class queue is
> > using the default drop profile:
> >
> > be-scheduler {
> > transmit-rate percent 50;
> > buffer-size percent 50;
> > priority low;
> > drop-profile-map loss-priority low protocol non-tcp
> > drop-profile non-tcp-low-red;
> > drop-profile-map loss-priority high protocol tcp
> > drop-profile tcp-high-red;
> > drop-profile-map loss-priority low protocol tcp
> > drop-profile tcp-low-red;
> > drop-profile-map loss-priority high protocol non-tcp
> > drop-profile non-tcp-high-red; } nc-scheduler {
> > transmit-rate percent 5;
> > buffer-size percent 5;
> > priority high;
> > }
> > af-scheduler {
> > transmit-rate percent 10;
> > buffer-size percent 5;
> > priority high;
> > }
> > ef-scheduler {
> > transmit-rate percent 35;
> > buffer-size percent 5;
> > priority strict-high;
> > }
> >
> > I've read in a C-vendor book that the serialization process
> > is a determining factor with real-time traffic on T1/E1 links
> > and they don't recommend setting a strict-high queue to more
> > than 33%. It's unclear to me whether this is specific to the
> > C-vendor implementation of low latency queuing or a general
> > rule of thumb.
> >
> > evt
> >
> > -----Original Message-----
> > From: Harry Reynolds [mailto:harry at juniper.net]
> > Sent: Tuesday, June 13, 2006 6:46 PM
> > To: Eric Van Tol; juniper-nsp at puck.nether.net
> > Subject: RE: [j-nsp] FW: strict-high priority queue
> >
> > Alright, so out from the woodwork I crawl.
> >
> > I did a little research and tend to think that the IE book is
> > in need of an update on this regard, and I have made due note.
> >
> > Below is a jni thread (with names/addresses removed) that may
> > shed light on your issue, but I'm not sure because you
> > indicate SH drops occur when you alter transmit-weight. The
> > thread summary is that the rate assigned to a strict-high
> > does not affect the SH queue, but *is* factored into the
> > calculations for the total WRR% available to other queues.
> > This means that changing the rate assigned to a strict-high
> > can have an impact on drop performance for the other queues,
> > and in this regard the IE book is misleading. At the same
> > time, the thread I've pasted indicates that one should assign
> > the expected rate to the SH queue, which is at odds with the
> > tech pub example you cite. I will ping the developers to see
> > if they can set the record straight. You may want to post
> > additional details such as SW/HW version, as your description
> > of loss in the SH class does not match any expected behaviors
> > I am aware of.
> >
> >
> > Regards
> >
> > Harry
> >
> >
> > [scrubbed thread]
> >
> > My experience was, that transmit rate for SHP queue has
> > influence on behavior of ... rest of queues.
> >
> > To be more detail:
> >
> > - SHP queue has effectively no limits and can consume all
> > bandwidth of interface, but:
> >
> > - if you have other queue marked as high prority (not
> > strict), as long as this queues are positive (in bandwidth)
> > scheduler consider transmit rate of SHP and all HP when they
> > decide from which queue packet should be taken. When HP and
> > SHP queues goes to deficit, then SHP is still served by
> > scheduler, as they will be in positive.
> >
> > - The other site effect is when you use transmit rate
> > percentage. If you not specify rate for SHP, then trans mit
> > rate of remaining queues will be aligned to 100%, then
> > effective guaranteed rate will be too high, because SHP
> > traffic volume is not taken to account.
> >
> > So, my advice:
> >
> > - Specify transmit rate for SHP queues at level of expected
> > traffic volume,
> > - Use policer to avoid 100% of bandwidth eated by SHP traffic
> > (if applicable).
> > - in addition for SHP use HP queues for NetControll traffic.
> >
> >
> > X x x x x x
> > Professional Services Consultant
> >
> > Juniper Networks
> >
> > -----Original Message-----
> > From: xxxxxxxx
> > Sent: 03 May 2006 20:18
> > To: xxxxxx
> > Subject: Re: FW: [q] transmit rate for the strict high queue
> >
> > > Could you please comment, what the semantics is for the
> > transmit rate
> > > assigned to the strict high queue (M/T)?
> > > In other words, what happens if I change the rate on the
> > strict high
> > > queue?
> >
> > My understanding is that when using a strict high queue we
> > essentially add 100% to whatever transmit-rate is specified.
> > This makes the rate meaningless (and you might as well not
> > include one) since it will never be below 100% and as such
> > will never be negative.
> >
> > [/thread]
> >
> >
> > > -----Original Message-----
> > > From: juniper-nsp-bounces at puck.nether.net
> > > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> > Eric Van Tol
> > > Sent: Tuesday, June 13, 2006 3:20 PM
> > > To: juniper-nsp at puck.nether.net
> > > Subject: [j-nsp] FW: strict-high priority queue
> > >
> > > Sorry for the duplicate post, but I haven't gotten any
> > feedback on the
> > > questions presented below. I was hoping this would be
> > something that
> > > could be answered here, since some of the authors of the
> > Sybex books
> > > are members of the list.
> > >
> > > Thanks,
> > > evt
> > >
> > > Subject: [j-nsp] strict-high priority queue
> > >
> > > Hi all,
> > > I've been doing some testing with QoS configs and
> according to the
> > > following page:
> > >
> > > http://www.juniper.net/techpubs/software/junos/junos76/swconfi
> > > g76-cos/ht
> > > ml/cos-scheduler-maps9.html
> > >
> > > if a queue is configured with a strict-high priority setting, the
> > > transmit-rate has no effect because the strict-high is
> > given the full
> > > interface bandwidth. However, from what I've seen, the if the
> > > 'transmit-rate' is configured for strict-high, it does have
> > at least
> > > some effect. For instance, when configuring any rate
> greater than
> > > about 35%, the strict-high queue starts to drop packets.
> > >
> > > In addition, it states that queues configured with strict-high
> > > *shouldn't* be configured with a transmit-rate. However,
> > on page 655
> > > of the Sybex JNCIE book, the expedited-forwarding queue is
> > strict-high
> > > with a transmit-rate.
> > >
> > > Two questions:
> > >
> > > 1. Why does strict-high drop packets when configured with
> > too high of
> > > a transmit-rate?
> > > 2. Which method is correct? The JNCIE example or the JUNOS docs?
> > >
> > >
> > >
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > http://puck.nether.net/mailman/listinfo/juniper-nsp
> > >
> >
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
More information about the juniper-nsp
mailing list