[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

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?  


> -----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