Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
I would use a rewrite rule to modify DSCP on egress, so that its consistent across platforms. I still prefer the IOS way, where TOS byte values are re- written on ingress (I believe we began a small petition for this capability a year or more back, but it didn't gain any traction). However, it works just as well in JUNOS, just on egress. I actually prefer the Junos method for at least some scenarios. In my case, we connect to several other QoS-aware networks that all use different values for different things (ie: AF41 = EF = AF42 = AF21 = me going crazy). Using Junos's method its very simple to do a different rewrite map on the egress interface toward the other networks. So there's basically a single piece of configuration to make everything function.. and a single place that things could get broken. However, I would agree that for smaller sites (ie: J-series, SRX, etc) the ingress method is much easier. Having a FULL CoS stanza just to mark some traffic EF is kind of annoying. And I can see the arguments for ingress methods in other networks as well. Of course this is just my opinion and I certainly don't run a huge network like some of you guys! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling, etc...
after the classification portion of the filter but before the default-accept.
I would use a rewrite rule to modify DSCP on egress, so that its consistent
across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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] Setting forwarding-class in firewall filter, non-match behaviour
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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
--
Sent from my mobile device
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
On Sunday 20 June 2010 05:15:45 pm Derick Winkworth wrote: I would use a rewrite rule to modify DSCP on egress, so that its consistent across platforms. I still prefer the IOS way, where TOS byte values are re- written on ingress (I believe we began a small petition for this capability a year or more back, but it didn't gain any traction). However, it works just as well in JUNOS, just on egress. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
Agreed I asked juniper for the same thing but got blown off. Egress remarking rewrites everything not just what I want. On Jun 20, 2010 10:52 AM, Mark Tinka mti...@globaltransit.net wrote: On Sunday 20 June 2010 05:15:45 pm Derick Winkworth wrote: I would use a rewrite rule to modif... I still prefer the IOS way, where TOS byte values are re- written on ingress (I believe we began a small petition for this capability a year or more back, but it didn't gain any traction). However, it works just as well in JUNOS, just on egress. Cheers, Mark. ___ 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] Setting forwarding-class in firewall filter, non-match behaviour
On Sunday 20 June 2010 10:55:10 pm Chris Evans wrote: Agreed I asked juniper for the same thing but got blown off. You can remark/rewrite on ingress but: - only to 'dscp 0'/'dscp be' - only on some platforms (M320, T-series, MPC MX cards) So it's not quite there. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
I agree. One thing that we do fairly often is create a multifield classifier
like this to just accept a couple of values to place into the appropriate
forwarding-class, then for a default action reset to BE forwarding-class for
all non-matching traffic. This works well in situations where you may not want
to use a BA classifier as you don't trust the markings or you want them
rewritten on egress.
Regards,
-Jeff
On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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
--
Sent from my mobile device
___
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] Setting forwarding-class in firewall filter, non-match behaviour
i wonder what the real world performance implications are on an ASIC forwarding
platform... We really haven't seen any issues with the way we are doing it.
I think I prefer the flexibility for later
From: Richmond, Jeff jeff.richm...@frontiercorp.com
To: Addy Mathur addy.mat...@gmail.com
Cc: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 11:18:40 AM
Subject: Re: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
I agree. One thing that we do fairly often is create a multifield classifier
like this to just accept a couple of values to place into the appropriate
forwarding-class, then for a default action reset to BE forwarding-class for
all non-matching traffic. This works well in situations where you may not want
to use a BA classifier as you don't trust the markings or you want them
rewritten on egress.
Regards,
-Jeff
On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
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
--
Sent from my mobile device
___
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
