Hello George,
Thank you very much for assisting me with this problem.
I am sorry if I am not using proper channel to reach you,
but I dont know how to open a case at JTAC and be assigned
to you. Also I believe that what we are discussing can be
beneficial for all community, so I am continuing to cross-post
this email to juniper-nsp@puck.nether.net
Please tell me if what I am doing is improper.
Going back to technical issues:
I did following:
1. Verified that I have no firewall filters, policers, samplers
or anything annotated as "deprecated" in my config.
2. Deleted completely class-of-service configuration from the router.
3. Commited changes
4. Created following class-of-service configuration:
[edit class-of-service]
karwas@USMIANAPJM20X1A# show
classifiers {
inet-precedence inet_clsf {
forwarding-class be {
loss-priority low code-points 000;
}
forwarding-class ef {
loss-priority low code-points 101;
}
forwarding-class nc {
loss-priority low code-points 111;
}
}
}
forwarding-classes {
queue 0 be priority low;
queue 1 ef priority low;
queue 2 af priority high;
queue 3 nc priority high;
}
interfaces {
ge-3/0/0 {
scheduler-map test-scheduler-map;
unit 100 {
classifiers {
inet-precedence inet_clsf;
}
}
}
}
scheduler-maps {
test-scheduler-map {
forwarding-class be scheduler be-scheduler;
forwarding-class ef scheduler ef-scheduler;
forwarding-class nc scheduler nc-scheduler;
}
}
schedulers {
be-scheduler {
transmit-rate percent 70;
buffer-size percent 70;
priority low;
}
ef-scheduler {
transmit-rate percent 20;
buffer-size percent 20;
priority high;
}
nc-scheduler {
transmit-rate percent 10;
buffer-size percent 10;
priority high;
}
}
[edit class-of-service]
5. Commited it.
-----
I see following problems which I think needs to be resolved before
I will apply this to other (production) interfaces:
1. I have confirmed that I have cosd running:
karwas@USMIANAPJM20X1A# run show system processes | grep cosd
608 ?? I 0:01.32 /usr/sbin/cosd
2. I still can run old "show chassis cos":
(...snip...)
FPC 3:
precedence-map 'Default':
bits 000 output-queue 0;
bits 001 output-queue 0;
bits 010 output-queue 0;
bits 011 output-queue 0;
bits 100 output-queue 0;
bits 101 output-queue 0;
bits 110 output-queue 0;
bits 111 output-queue 0;
drop-profile 'Default':
msp-profile:
plp-set-queue-profile:
plp-clear-queue-profile:
which is not showing that any new forwarding classes (queues) are
active.....
3. I will need to apply this to ATM OC12 interface with multiple
units (point-to-point only), but with different ATM QoS configured
(different CBR bandwith on different units....)
How different schedulers are interacting with multiple
unit on ATM interaface?
Can I somehow use different scheduler-maps assigned to different
ATM PVCs?
What is the actual relation between queues maintained for every
ATM PVC (does they exist at all?) and FPC queues used by CoS framework?
Thank you very, very much.
I would appreciate any help with understanding those issues,
if you have no time, just point me to specific place in documentation.
Thanks again,
Przemek
On Mon, 2002-06-03 at 15:17, George Zhou wrote:
> Hello Przemek,
>
> You need to make sure there is no old CoS cli/configuation in
> your router, and only the new cos configuraton, therefore only cosd
> is sending the configuration to PFE(in new cos), not the chassisd like
> old cos.
>
> The reason you got some queue information from "show chassis cos"
> is you may have old cos cli configured at your router. You need
> to remove old cos configuration and leave only the new cos cli.
> Then deactivate/activate class-of-service or reboot the router.
>
> regress@boxster# deactivate class-of-service
> regress@boxster# activate class-of-service
>
> Yes, you need EFPC to run priority queueing and vopi application.
>
> Here is a sample configuration for your application:
>
> Thanks,
>
> - George Zhou
>
> regress@boxster# show class-of-service
> classifiers {
> inet-precedence inet_clsf {
> forwarding-class be {
> loss-priority low code-points 000; <== data
> }
> forwarding-class af {
> loss-priority low code-points 010;
> }
> forwarding-class ef {
> loss-priority low code-points 101; <== voip, precedenece = 5
> }
> forwarding-class nc {
> loss-priority low code-points 111;
> }
> }
> }
> forwarding-classes {
> queue 0 be priority low;
> queue 1 ef priority low;
> queue 2 af priority low;
> queue 3 nc priority low;
> }
> interfaces {
> so-* {
> scheduler-map test-scheduler-map;
> }
> ge-* {
> unit 0 {
> classifiers {
> inet-precedence inet_clsf;
> }
> }
> }
> }
> scheduler-maps {
> test-scheduler-map {
> forwarding-class be scheduler be-scheduler;
> forwarding-class ef scheduler ef-scheduler;
> forwarding-class af scheduler af-scheduler;
> forwarding-class nc scheduler nc-scheduler;
> }
> }
> schedulers {
> be-scheduler {
> transmit-rate percent 80;
> buffer-size percent 80;
> priority low;
> }
> ef-scheduler {
> transmit-rate percent 20;
> buffer-size percent 20;
> priority high; <== or priority strict-high in 5.4
> }
> }
>
>
>
> >
> > Thanks for explanation.
> >
> > But I am still confused, as I have some statements configured
> > (and successfully commited) under class-of-service using new
> > syntax.
> >
> > What do you mean by "bootup your router with new CoS cli"?
> > Do I need to enable new CoS somehow special?
> >
> > Maybe that is the reason, why my attempts to deploy
> > two separate forwarding classes for be and voip are failing....
> >
> > I understand that I have some limitations because my router
> > has old FPCs (not extended), but what I need to do is just
> > assure that traffic with ip_precedence 5 will be emitted first.
> > I know that this is "priority queuing", which is nt supported
> > on old, non Enhanced FPCs, but I was hoping that maybe i will
> > be able to differentiate traffic into 2 classes, police be class
> > to 80% of interface capacity, and then I will have remaining 20%
> > reserved for voip class.
> >
> > Any ideas how to approach this issue on Juniper M20 with old FPCs?
> >
> > Thanks in advance,
> >
> > Przemek
> >
> > On Mon, 2002-06-03 at 14:31, George Zhou wrote:
> > > Hello Przemek,
> > >
> > > In JunOS 5.3, the old CoS cli/mode still exists. But if
> > > you bootup your router with new CoS cli, the cosd will kick in,
> > > and you will get error messages from "show chassis cos".
> > >
> > > This command is removed from JunOS 5.4 and above..
> > >
> > > Thanks,
> > >
> > > - George
> > >
> > > >
> > > > All,
> > > >
> > > > How come this command is still available in JunOS 5.3?
> > > > It is removed from documentation for 5.3, and I believe
> > > > it is showing improper information about queue assignments:
> > > > ...
> > > > bits 000 output-queue 0;
> > > > bits 001 output-queue 0;
> > > > bits 010 output-queue 0;
> > > > bits 011 output-queue 0;
> > > > bits 100 output-queue 0;
> > > > bits 101 output-queue 0;
> > > > bits 110 output-queue 0;
> > > > bits 111 output-queue 0;
> > > > ...
> > > >
> > > > Thanks,
> > > >
> > > > Przemek
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:36 EDT