[j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
Dale Shaw
dale.shaw+j-nsp at gmail.com
Sun Jun 20 04:59:12 EDT 2010
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
More information about the juniper-nsp
mailing list