[j-nsp] delay-buffer in Juniper
Serge Vautour
sergevautour at yahoo.ca
Sun Oct 14 12:51:45 EDT 2012
Hello,
What kind of hardware are you using? The behavior is different on MPC vs DPC. The MX80 family use built-in MPC cards.
My testing has shown the following with regards to queue commands:
DPC:
-Rate-limit: works as expected, queue is policed.
-Exact: Not supported
-Shaping-Rate: Command takes but it does nothing. The queue isn't
capped and traffic can reach sub-interface or interface shaped rate.
MPC:
-Rate-limit: Command takes but it does nothing. The queue isn't
capped and traffic can reach sub-interface or interface shaped rate.
-Exact: The result looks like a shaper.
-Shaping-Rate: Results look exactly like the "exact" command. Traffic
looks shaped.
The summary is that DPC cards can only "police" queues and MPC cards can only "shape" queues. I agree that the docs aren't very clear on what's supported. I had to run my own tests to figure it out.
Serge
________________________________
From: Huan Pham <drie.huanpham at gmail.com>
To: Stefan Fouant <sfouant at shortestpathfirst.net>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Sent: Saturday, October 13, 2012 8:45:58 PM
Subject: Re: [j-nsp] delay-buffer in Juniper
>
>
> Honestly, that's 9.5 documentation. Perhaps something changed at some
> point, but in current versions of code this is not how it works.
>
>
Hi Stefan,
You are right, I should to pay attention to the version, as the behaviour
may have changed. I am new to Juniper (moving from the Cisco background),
so I am still not familiar with navigating Juniper documentation. I relied
on Google first hit :) . Will try to navigate the Juniper documentation.
However, for this feature in the newest OS, I do not think that the
behaviour is as you described. Although worded differently, it basically
means the same as the one I quoted:
Here's the link to the 12.1 OS:
http://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/transmit-rate-edit-cos.html
rate-limit—(Optional) Limit the transmission rate to the rate-controlled
amount. In contrast to the exact option, the scheduler with the rate-limit
option shares unused bandwidth above the rate-controlled amount.
I do not always trust the documentation, especially there may be limitation
with hardware platform, OS version etc that is not well documented, so I
set up a quick lab (running version 11.4R5.5) to test this feature. The
behaviour in this case is the same as documented.
When I use transmit-rate rate-limit I can send more traffic than the
transmit rate-controlled amount. The transmit-rate rate-limit is 1m, but I
can send traffic at 8Mbps.
When I use transmit-rate exact I can not send more traffic than the
transmit rate-controlled amount.
One side note though, when I set the rate to a very low number (e.g. 10k,
or even 500k), and use the "exact" option, the actual transmuted rate (on
1Gbps port) is not rate limited to the configured value. This is probably
understandable, due to factors as sampling intervals etc.
Here's my lab config and results:
ge-1/0/0 ge-1/1/0
(MX5) R1 -------------------------------- R2 (Virtual)
10.1.1.1 10.1.1.2
I generated traffic by pinging from R2 to R1
lab at MX5> ping 10.1.1.1 routing-instance R2 rapid count 100000 size 1000
(Ping from R2 to R1, and monitor traffic on outbound of R1)
lab at MX5> show configuration class-of-service schedulers admin-sched
transmit-rate {
1m;
rate-limit;
}
buffer-size percent 10;
priority medium-low;
lab at MX5> show interfaces queue ge-1/1/0 | find admin
Queue: 1, Forwarding classes: admin
Queued:
Packets : 75751 931 pps
Bytes : 80750566 7942744 bps
Transmitted:
Packets : 75751 931 pps
Bytes : 80750566 7942744 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
Change to using "exact", I can not send more than 1M as expected.
lab at MX5> show configuration class-of-service schedulers admin-sched
transmit-rate {
1m;
exact;
}
buffer-size percent 10;
priority medium-low;
lab at MX5> show interfaces queue ge-1/1/0 | find admin
Queue: 1, Forwarding classes: admin
Queued:
Packets : 14288 116 pps
Bytes : 15231008 994928 bps
Transmitted:
Packets : 14288 116 pps
Bytes : 15231008 994928 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets : 0 0 pps
Low : 0 0 pps
Medium-low : 0 0 pps
Medium-high : 0 0 pps
High : 0 0 pps
RED-dropped bytes : 0 0 bps
Low : 0 0 bps
Medium-low : 0 0 bps
Medium-high : 0 0 bps
High : 0 0 bps
FULL CONFIG
-----------
lab at MX5> show configuration class-of-service
forwarding-classes {
queue 0 best-effort;
queue 1 admin;
queue 2 voip;
queue 3 network-control;
}
interfaces {
ge-1/0/0 {
scheduler-map my-sched-map;
}
ge-1/1/0 {
scheduler-map my-sched-map;
}
}
scheduler-maps {
my-sched-map {
forwarding-class best-effort scheduler best-effort-sched;
forwarding-class admin scheduler admin-sched;
forwarding-class voip scheduler voip-sched;
forwarding-class network-control scheduler network-control-sched;
}
}
schedulers {
best-effort-sched {
transmit-rate 40k;
buffer-size percent 40;
priority low;
}
/* PING packets are subject of this scheduler */
admin-sched {
transmit-rate {
1m;
rate-limit;
}
buffer-size percent 10;
priority medium-low;
}
voip-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority high;
}
network-control-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority medium-high;
}
}
lab at MX5# show firewall
family inet {
filter RE-Generated-Classifier {
term OSPF {
from {
protocol ospf;
}
then {
forwarding-class network-control;
dscp cs7;
}
}
term ICMP {
from {
protocol icmp;
}
then {
forwarding-class admin;
dscp cs1;
}
}
/* Keep default behaviour */
term OTHERS {
then accept;
}
}
}
lab at MX5# show
/* This loopback belong to the Master Router */
unit 0 {
family inet {
filter {
output RE-Generated-Classifier;
}
}
}
/* This loopback belong to Virtual Router R2 */
unit 2 {
family inet {
filter {
output RE-Generated-Classifier;
}
}
}
lab at MX5# show routing-instances
R2 {
instance-type virtual-router;
interface ge-1/1/0.0;
interface lo0.2;
routing-options {
router-id 10.1.1.2;
}
protocols {
ospf {
area 0.0.0.0 {
interface ge-1/1/0.0;
}
}
}
}
lab at MX5# show protocols ospf
area 0.0.0.0 {
interface ge-1/0/0.0;
}
_______________________________________________
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