Re: [j-nsp] RED Drops with Qos
Enable extended buffer size..
q-pic-large-buffer
also under chassis/pic configuration.
From: Scott Berkman
To: Derick Winkworth ; juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:58:45 PM
Subject: RE: [j-nsp] RED Drops with Qos
Derick,
FYI after making your suggested changes I am still seeing drops:
show configuration chassis fpc 2 pic 2
red-buffer-occupancy {
weighted-averaged {
instant-usage-weight-exponent 9;
}
}
show interfaces queue ds-2/2/0:1:5:1
Physical interface: ds-2/2/0:1:5:1, Enabled, Physical link is Up
Interface index: 165, SNMP ifIndex: 79
Description: Test-1
Forwarding classes: 4 supported, 4 in use
Egress queues: 4 supported, 4 in use
Queue: 0, Forwarding classes: be
Queued:
Packets : 290 0 pps
Bytes:375596 0 bps
Transmitted:
Packets : 268 0 pps
Bytes:346908 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets :22 0 pps
Low, non-TCP: 0 0 pps
Low, TCP:22 0 pps
High, non-TCP : 0 0 pps
High, TCP : 0 0 pps
RED-dropped bytes: 28688 0 bps
Low, non-TCP: 0 0 bps
Low, TCP: 28688 0 bps
High, non-TCP : 0 0 bps
High, TCP : 0 0 bps
Thanks,
-Scott
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth
Sent: Monday, December 21, 2009 4:41 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there is
no allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and you
should put a weight of 9 as a start.
From: Scott Berkman
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example interface:
ds-2/2/0:1:1:1 {
scheduler-map V
Re: [j-nsp] RED Drops with Qos
Derick,
FYI after making your suggested changes I am still seeing drops:
show configuration chassis fpc 2 pic 2
red-buffer-occupancy {
weighted-averaged {
instant-usage-weight-exponent 9;
}
}
show interfaces queue ds-2/2/0:1:5:1
Physical interface: ds-2/2/0:1:5:1, Enabled, Physical link is Up
Interface index: 165, SNMP ifIndex: 79
Description: Test-1
Forwarding classes: 4 supported, 4 in use
Egress queues: 4 supported, 4 in use
Queue: 0, Forwarding classes: be
Queued:
Packets : 290 0 pps
Bytes:375596 0 bps
Transmitted:
Packets : 268 0 pps
Bytes:346908 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets :22 0 pps
Low, non-TCP: 0 0 pps
Low, TCP:22 0 pps
High, non-TCP : 0 0 pps
High, TCP : 0 0 pps
RED-dropped bytes: 28688 0 bps
Low, non-TCP: 0 0 bps
Low, TCP: 28688 0 bps
High, non-TCP : 0 0 bps
High, TCP : 0 0 bps
Thanks,
-Scott
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth
Sent: Monday, December 21, 2009 4:41 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there is
no allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and you
should put a weight of 9 as a start.
From: Scott Berkman
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example interface:
ds-2/2/0:1:1:1 {
scheduler-map VOIP-MAP;
unit 0 {
classifiers {
dscp DSCP-CLASS;
}
}
}
I also tested with the following scheduler and still saw the drops:
be-sched {
transmit-rate percent 80;
buffer-size percent 80;
pri
Re: [j-nsp] RED Drops with Qos
Thanks Derick,
I read about changing the RED method, but missed that it is done on
the chassis/pic level, not in the drop-policies.
I'll try this out and see where it gets us.
On a related note, I saw some back and forth about setting the
percentages (transmit-rate and buffer-size) on strict-high queues to other
than 0. What are everyone's best recommendations/past successes on this?
Thanks again!
-Scott
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth
Sent: Monday, December 21, 2009 4:41 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there is
no allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and you
should put a weight of 9 as a start.
From: Scott Berkman
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example interface:
ds-2/2/0:1:1:1 {
scheduler-map VOIP-MAP;
unit 0 {
classifiers {
dscp DSCP-CLASS;
}
}
}
I also tested with the following scheduler and still saw the drops:
be-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority high;
}
ef-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there is no
allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and you
should put a weight of 9 as a start.
From: Scott Berkman
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example interface:
ds-2/2/0:1:1:1 {
scheduler-map VOIP-MAP;
unit 0 {
classifiers {
dscp DSCP-CLASS;
}
}
}
I also tested with the following scheduler and still saw the drops:
be-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority high;
}
ef-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example interface:
ds-2/2/0:1:1:1 {
scheduler-map VOIP-MAP;
unit 0 {
classifiers {
dscp DSCP-CLASS;
}
}
}
I also tested with the following scheduler and still saw the drops:
be-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority high;
}
ef-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Kernal routes
Hi All, I happened to see certain route as 'Kernal' routes. Is there a link which explians about these in JUNOS? Cheers ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Sampling Traffic --- Urgent
On Mon, Dec 21, 2009 at 09:06:23AM +0100, sth...@nethelp.no wrote: > > I think it is common practice, and it is required also by major netflow > > tools, to have sampling enabled as input on all interfaces. This allows > > to directly getting stats for ingress traffic and indirectly getting > > stats for egress traffic by aggregating on the egress if-index of the > > netflow record. This avoid double counting the same flow first on > > ingress on one interface and then again on egress on another interface. > > Or just enable it on the transit/peering interfaces. You obviously > lose the information about which (internal) interface the traffic > is coming from. Enabling ingress/egress at the transit/peering interfaces, not only you loose the ingress interface (ie., which might be good to detect routing asymmetries) but also the entrance point (router) within your domain (which is essential building block to build traffic matrices). At the end it depends what is the end goal: if just couting bytes up one can go either one way or the other. For some specific scenarios, (TE, peering, etc.) it might be recommended to go ingress-only at all the edge interfaces. Cheers, Paolo ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Sampling Traffic --- Urgent
Dear All, I am really thankfull towards you all for your kind help and quick response. Actually now in Juniper M10i we don't have service PIC, we will be upgrading our Juniper M10i with MS-PIC which is an integrated service PIC. And also we can't activate lo0 interface for now on our network. We will be looking on this topic with details considering your given ideas and will further come on contact with experts like you whenever came on some confusion on any related issue. Thank You. Thank You very much for your kind help again. Regards, Uttam On Mon, Dec 21, 2009 at 1:51 PM, wrote: > > I think it is common practice, and it is required also by major netflow > > tools, to have sampling enabled as input on all interfaces. This allows > > to directly getting stats for ingress traffic and indirectly getting > > stats for egress traffic by aggregating on the egress if-index of the > > netflow record. This avoid double counting the same flow first on > > ingress on one interface and then again on egress on another interface. > > Or just enable it on the transit/peering interfaces. You obviously > lose the information about which (internal) interface the traffic > is coming from. > > > One thing that you may want to check: I think that the M10i is equipped > > with the integrated service-pic that would allow to perform sampling in > > hardware rather than on the RE. In that case you find a sp-././. > > interface. By enabling family inet on it you enable the service pic; > > then you can source netflow from it. > > No, the M10i doesn't have any integrated service-pic. The M7i has an > integrated *tunnel PIC*, which is not the same. > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] no router alert
Dear experts,
I am struggling to formulate a term to drop all packets with any
ip-option set apart from router-alert.
The following term does NOT work because drops not only packets with
ip-options other than router-alert, but also packet with NO
ip-option Which of course is devastating !
Any idea how to implement it?
Thanks,
bit.
inactive: term NO-RT-ALERT {
from {
ip-options-except router-alert;
}
then {
count NO-RT-ALERT;
log;
discard;
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Sampling Traffic --- Urgent
> I think it is common practice, and it is required also by major netflow > tools, to have sampling enabled as input on all interfaces. This allows > to directly getting stats for ingress traffic and indirectly getting > stats for egress traffic by aggregating on the egress if-index of the > netflow record. This avoid double counting the same flow first on > ingress on one interface and then again on egress on another interface. Or just enable it on the transit/peering interfaces. You obviously lose the information about which (internal) interface the traffic is coming from. > One thing that you may want to check: I think that the M10i is equipped > with the integrated service-pic that would allow to perform sampling in > hardware rather than on the RE. In that case you find a sp-././. > interface. By enabling family inet on it you enable the service pic; > then you can source netflow from it. No, the M10i doesn't have any integrated service-pic. The M7i has an integrated *tunnel PIC*, which is not the same. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
