Hi Harry, I'm using packet mode. I will try the per-unit-scheduler as you suggest. Thanks!
Eric Van Tol -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Atlantech Online, Inc. | http://www.atlantech.net phone: 301-589-3060 fax: 301-589-3936 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- view our Network status | http://noc.atlantech.net ----- Original Message ----- From: Harry Reynolds <[email protected]> To: Eric Van Tol; [email protected] <[email protected]> Sent: Wed Jan 06 15:37:34 2010 Subject: RE: Class of Service Question 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>] * ... * } * ... * } * } */ regr...@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: [email protected] [mailto:[email protected]] On Behalf Of Eric Van Tol Sent: Wednesday, January 06, 2010 12:12 PM To: [email protected] 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:[email protected]] > Sent: Wednesday, January 06, 2010 2:51 PM > To: Eric Van Tol; [email protected] > 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: [email protected] [mailto:juniper-nsp- > [email protected]] On Behalf Of Eric Van Tol > Sent: Wednesday, January 06, 2010 11:38 AM > To: [email protected] > 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
