[j-nsp] Class of Service Question
Harry Reynolds
harry at juniper.net
Wed Jan 6 15:37:34 EST 2010
IIRC J boxes have inherent per-unit scheduling/shaping support. The VC group thing is a shaper, but intended for use at hub site with remote low-speak frame access links. I have notes indicating that the vc group construct can be applied to ge, but again I feel you can just do per ifl scheduling with up to 8 queues, and IIRC, you can further shape a queue using a combo of transmit-rate and shaping-rate.
Then again, maybe this all changed when they went to srx/flow based.
What version?
>From an old spec:
CLI (configuration mode) changes
--------------------------------
Following hierarchy would be used to configure shaping rate:
/*
* class-of-service {
* schedulers {
* <scheduler-name> {
* transmit-rate [<rate>|percent <percent>] [exact];
* shaping-rate [<rate>|percent <percent>]
* ...
* }
* ...
* }
* }
*/
regress at aspirin# set class-of-service schedulers <scheduler-name>
shaping-rate ?
Possible completions:
<[Enter]> Execute this command
<rate> Shaping rate as rate (3200..32000000000 bits per second)
percent Transmit rate as percentage (0..100)
| Pipe through a command
[edit]
For backward compatibility, we still allow setting exact option in transmit-rate
configuration for PEPSI. However, we disallow setting both the exact option in
tx-rate and shaping-rate knob together at the same time.
-----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, January 06, 2010 12:12 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Class of Service Question
Hi Harry,
Thanks for the suggestion. The problem is that I am using a J-Series to do this and I was told that the only way to do per-unit-scheduling was to use virtual-channel-groups. Even with the config below, my confusion comes from the fact that in a scheduler config, you specify either a percent or rate for the scheduler. That percentage is based off the physical interface bandwidth, not the logical unit - is this not correct?
Here's a sample config of what I have for our existing CoS configs, which work great on channelized interfaces:
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;
}
Unfortunately, I'm not sure how this will work in my new setup because on a channelized interface, each T1 in the DS3 reports its bandwidth as 1.5M. On a GE interface, each VLAN reports its bandwidth as 1000M, no?
-evt
> -----Original Message-----
> From: Harry Reynolds [mailto:harry at juniper.net]
> Sent: Wednesday, January 06, 2010 2:51 PM
> To: Eric Van Tol; juniper-nsp at puck.nether.net
> Subject: RE: Class of Service Question
>
> Sounds like a case for per-unit scheduling/shaping, which is possible
> on
> IQ/Iq2 interfaces. However, I'm confused by the comment of one vlan
> w/both voice and data. Here that is one unit, which you can shape to
> less than the physical rate, but to then provide bandwidth to one app
> vs another within that ifl I think you will need a MF classifier and
> related policer function as well.
>
> HTHs
>
> <<< typical per unit scheduler/shaper, needs Iq pic:
>
> > [edit interfaces]
> > ge-1/0/0 {
> > vlan-tagging;
> > per-unit-scheduler;
> > }
> >
> > Under the class-of-service interface stanza:
> >
> > [edit class-of-service]
> > interfaces {
> > ge-1/0/0 {
> > unit 50 {
> > scheduler-map vlan50;
> > shaping-rate 50m;
> > }
> > unit 60 {
> > scheduler-map vlan60;
> > shaping-rate 60m;
> > }
> > }
> > }
>
>
> -----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, January 06, 2010 11:38 AM
> To: juniper-nsp at puck.nether.net
> Subject: [j-nsp] Class of Service Question
>
> Hi all,
> I'm having a bit of a time figuring out how to do QoS for a particular
> type of setup. I currently have some excellent working configs for
> channelized IQ interfaces and full FE/GE interfaces. My problem at
> this point is trying to figure out how to do QoS for logical
> interfaces on a GE port. My problem comes from the fact that QoS
> appears to work based upon the bandwidth of the physical interface, not the logical interface.
>
> For instance, we have a need to provide voice services to customers
> through a Gigabit ethernet connection via another provider, using EoC
> for the last mile. All customers will be provisioned on a separate VLAN.
> With plain ethernet implementations, we've simply used two VLANs - one
> for voice and one for data. However, in this case, we are being given
> only a single VLAN on which both voice and data will traverse.
>
> My primary question is when configuring schedulers, how do I let the
> router know that logical interface A is only a 10M circuit and
> interface B is a 25M circuit? When specifying that I need a certain
> amount of bandwidth available for traffic type X on a 10m logical
> unit, doesn't JUNOS see that the interface bandwidth is 1G and
> therefore never really implement any queuing because the full
> interface bandwidth and queues will likely never really be full? Or
> does the 'shaping-rate' in the virtual- channel configuration clue the
> router in to the actual rate of the logical unit?
>
> I recall, perhaps mistakenly, that IOS had the 'bandwidth' command in
> the interface config that not only worked for IGP calculations, but
> also clued the QoS config into knowing that an interface really only
> had X amount of bandwidth and not what was reported by the interface
> itself. Doesn't look like Juniper's "equivalent" does this, at least
> from what I can gather from the docs.
>
> Any advice from anyone who's done a similar setup would really be
> appreciated.
>
> Thanks,
> evt
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list