Juniper firewall chain behavior

Ok, if this is actually documented somewhere I'll be damned
if I can find 
it. When you do:

interface ge-#/#/# {
    unit 0 {
        family inet {
            filter {
                input-list [ filter1 filter2 filter3 ];
            }
        }
    }
}

What is the behavior for evaluating a packet across chains?
If you have an 
explicit "then accept" or "then discard"
in filter1 does it end 
processing, or does it then move to the next filter? I would
normally 
expect that it would behave similarly to policy chains, but
since there is 
no "next filter" command I'm suspicious that it
actually does something 
like fully evaluate filter1, then fully evaluate filter2,
rather than 
compile it into one ruleset.

The documentation says absolutely nothing about the
behavior, as best as I 
can tell.

-- 
Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
5ECA F8B1 2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

IIRC, it is processed like a policy chain.  So, an accept,
reject or discard
in the first filter will immediately end processing of the
chain.  (Also,
recall that there is an implied 'then accept;' when you
modify attributes in
the then clause.  For example, 'then forwarding-class
expedited-forwarding;'
would imply an action of 'accept;' and also cause processing
to stop.)

-Jon

On 4/3/07, Richard A Steenbergen <rase-gerbil.net> wrote:
>
> Ok, if this is actually documented somewhere I'll be
damned if I can find
> it. When you do:
>
> interface ge-#/#/# {
>     unit 0 {
>         family inet {
>             filter {
>                 input-list [ filter1 filter2 filter3
];
>             }
>         }
>     }
> }
>
> What is the behavior for evaluating a packet across
chains? If you have an
> explicit "then accept" or "then
discard" in filter1 does it end
> processing, or does it then move to the next filter? I
would normally
> expect that it would behave similarly to policy chains,
but since there is
> no "next filter" command I'm suspicious that
it actually does something
> like fully evaluate filter1, then fully evaluate
filter2, rather than
> compile it into one ruleset.
>
> The documentation says absolutely nothing about the
behavior, as best as I
> can tell.
>
> --
> Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF
4C41 5ECA F8B1 2CBC)
> _______________________________________________
> juniper-nsp mailing list juniper-nsppuck.nether.net
> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

> Date: Tue, 3 Apr 2007 20:21:54 -0400
> From: Richard A Steenbergen <rase-gerbil.net>
> Sender: juniper-nsp-bouncespuck.nether.net
> 
> Ok, if this is actually documented somewhere I'll be
damned if I can find 
> it. When you do:
> 
> interface ge-#/#/# {
>     unit 0 {
>         family inet {
>             filter {
>                 input-list [ filter1 filter2 filter3
];
>             }
>         }
>     }
> }
> 
> What is the behavior for evaluating a packet across
chains? If you have an 
> explicit "then accept" or "then
discard" in filter1 does it end 
> processing, or does it then move to the next filter? I
would normally 
> expect that it would behave similarly to policy chains,
but since there is 
> no "next filter" command I'm suspicious that
it actually does something 
> like fully evaluate filter1, then fully evaluate
filter2, rather than 
> compile it into one ruleset.
> 
> The documentation says absolutely nothing about the
behavior, as best as I 
> can tell.

If any filter in the chain reaches an explicit 'accept' or
'deny', that
is the end of the processing for the entire chain. Of
course, there is
an implicit accept at the end of the chain.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley
Lab)
E-mail: obermanes.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3
987B 3751

_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Tue, Apr 03, 2007 at 08:20:40PM -0700, Kevin Oberman
wrote:
> If any filter in the chain reaches an explicit 'accept'
or 'deny', that
> is the end of the processing for the entire chain. Of
course, there is
> an implicit accept at the end of the chain.

Funny, in normal firewall use there is an implicit discard
at the end of 
the chain. I wouldn't have expected such a major change in
behavior, 
especially if you might ever be expected to mix a filter in
a chained and 
non-chained role.

So, to test this out I tried to do the following:

firewall {
    filter BORDER {
        some generic border-wide filters and rate-limits
here;
    }
    filter SAMPLE {
        term SAMPLE {
            then sample;
        }
    }
}

interfaces {
    xe-0/1/0 {
        unit 0 {
            family inet {
                filter {
                    input-list [ BORDER ... ];
                    output-list [ BORDER SAMPLE ... ];
                }
            }
        }
    }
}

At first I noticed that it didn't seem to be sampling
anything, so I tried 
to reorder it to [ SAMPLE BORDER ]. In this configuration,
it sampled, but 
never processed BORDER. So for the same of testing I did
this:

filter SAMPLE {
    term SAMPLE {
        then {
            count sampled;
        }
    }
}

filter DISCARD {
    term DISCARD {
        then {
            count discarded;
            discard;
        }
    }
}

And tried applying it as [ SAMPLE DISCARD ]. The results:

Filter: xe-0/1/0.50-o                                       
  
sample-xe-0/1/0.50-o                              1432935   
            16958

I get per-interface matches on the counter from my first
filter, but the 
counter for the second filter isn't even created, and no
packets are 
discarded. The only explanation for this would be that
"then sample" and 
"then count" act as terminating actions, which
would seem exceedingly 
lame. Combine with the lack of "next filter" and
what is the point? The 
whole thing becomes about as useful as route-map without
continue. 

-- 
Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
5ECA F8B1 2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

For Firewall filters there it is an implicit discard at the
end of the chain
for policys it depends on the protocol such as BGP has an
implicit accept.
I don't recall what it is for the other protocols but it's
mentioned in the
jncia and/or jncis study guides.

On 4/3/07, Richard A Steenbergen <rase-gerbil.net> wrote:
>
> On Tue, Apr 03, 2007 at 08:20:40PM -0700, Kevin Oberman
wrote:
> > If any filter in the chain reaches an explicit
'accept' or 'deny', that
> > is the end of the processing for the entire chain.
Of course, there is
> > an implicit accept at the end of the chain.
>
> Funny, in normal firewall use there is an implicit
discard at the end of
> the chain. I wouldn't have expected such a major change
in behavior,
> especially if you might ever be expected to mix a
filter in a chained and
> non-chained role.
>
> So, to test this out I tried to do the following:
>
> firewall {
>    filter BORDER {
>        some generic border-wide filters and rate-limits
here;
>    }
>    filter SAMPLE {
>        term SAMPLE {
>            then sample;
>        }
>    }
> }
>
> interfaces {
>    xe-0/1/0 {
>        unit 0 {
>            family inet {
>                filter {
>                    input-list [ BORDER ... ];
>                    output-list [ BORDER SAMPLE ... ];
>                }
>            }
>        }
>    }
> }
>
> At first I noticed that it didn't seem to be sampling
anything, so I tried
> to reorder it to [ SAMPLE BORDER ]. In this
configuration, it sampled, but
> never processed BORDER. So for the same of testing I
did this:
>
> filter SAMPLE {
>    term SAMPLE {
>        then {
>            count sampled;
>        }
>    }
> }
>
> filter DISCARD {
>    term DISCARD {
>        then {
>            count discarded;
>            discard;
>        }
>    }
> }
>
> And tried applying it as [ SAMPLE DISCARD ]. The
results:
>
> Filter: xe-0/1/0.50-o
>
> sample-xe-0/1/0.50-o                             
1432935                16958
>
> I get per-interface matches on the counter from my
first filter, but the
> counter for the second filter isn't even created, and
no packets are
> discarded. The only explanation for this would be that
"then sample" and
> "then count" act as terminating actions,
which would seem exceedingly
> lame. Combine with the lack of "next filter"
and what is the point? The
> whole thing becomes about as useful as route-map
without continue. 
>
> --
> Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF
4C41 5ECA F8B1 2CBC)
> _______________________________________________
> juniper-nsp mailing list juniper-nsppuck.nether.net
> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Steven Brenchley
-------------------------------------
There are 10 types of people in the world those who
understand binary and
those who don't.
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

As I mentioned before (and as Juniper's documentation
indicates), there is
an implicit "accept;" when you modify other things
(which includes applying
counters, sampling, etc.).  If you want to override that,
you can use the
"next term;" action.  So, using that action in the
terms in your filter
chain may allow you to achieve your desired result.

-Jon

On 4/4/07, Richard A Steenbergen <rase-gerbil.net> wrote:
>
> On Tue, Apr 03, 2007 at 08:20:40PM -0700, Kevin Oberman
wrote:
> > If any filter in the chain reaches an explicit
'accept' or 'deny', that
> > is the end of the processing for the entire chain.
Of course, there is
> > an implicit accept at the end of the chain.
>
> Funny, in normal firewall use there is an implicit
discard at the end of
> the chain. I wouldn't have expected such a major change
in behavior,
> especially if you might ever be expected to mix a
filter in a chained and
> non-chained role.
>
> So, to test this out I tried to do the following:
>
> firewall {
>     filter BORDER {
>         some generic border-wide filters and
rate-limits here;
>     }
>     filter SAMPLE {
>         term SAMPLE {
>             then sample;
>         }
>     }
> }
>
> interfaces {
>     xe-0/1/0 {
>         unit 0 {
>             family inet {
>                 filter {
>                     input-list [ BORDER ... ];
>                     output-list [ BORDER SAMPLE ... ];
>                 }
>             }
>         }
>     }
> }
>
> At first I noticed that it didn't seem to be sampling
anything, so I tried
> to reorder it to [ SAMPLE BORDER ]. In this
configuration, it sampled, but
> never processed BORDER. So for the same of testing I
did this:
>
> filter SAMPLE {
>     term SAMPLE {
>         then {
>             count sampled;
>         }
>     }
> }
>
> filter DISCARD {
>     term DISCARD {
>         then {
>             count discarded;
>             discard;
>         }
>     }
> }
>
> And tried applying it as [ SAMPLE DISCARD ]. The
results:
>
> Filter: xe-0/1/0.50-o
>
> sample-xe-0/1/0.50-o                             
1432935                16958
>
> I get per-interface matches on the counter from my
first filter, but the
> counter for the second filter isn't even created, and
no packets are
> discarded. The only explanation for this would be that
"then sample" and
> "then count" act as terminating actions,
which would seem exceedingly
> lame. Combine with the lack of "next filter"
and what is the point? The
> whole thing becomes about as useful as route-map
without continue. 
>
> --
> Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF
4C41 5ECA F8B1 2CBC)
> _______________________________________________
> juniper-nsp mailing list juniper-nsppuck.nether.net
> 
https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, Apr 04, 2007 at 10:42:07AM -0400, Jonathan Looney
wrote:
> As I mentioned before (and as Juniper's documentation
indicates), there is
> an implicit "accept;" when you modify other
things (which includes applying
> counters, sampling, etc.).  If you want to override
that, you can use the
> "next term;" action.  So, using that action
in the terms in your filter
> chain may allow you to achieve your desired result.

Except that when I finish off my BORDER filter with a
"next term", I get:

[edit groups BASE-FIREWALL firewall]
  'filter BORDER'
    Next term specified but no following term exists
error: configuration check-out failed

Now whats strange is when I do it on a very simple filter,
like:

            filter TEST {
                term TEST {
                    then {
                        count test;
                        next term;
                    }
                }
            }

And apply it as [ TEST SOMETHINGELSE ], it does apply
successfully, 
and correctly kick the packet over to the next filter. It
doesn't stop 
working until I have a more complex filter, such as this
final term that 
generates the error above:

term ICMP-OTHER {
    from {
        protocol icmp;
        icmp-type-except [ echo-reply time-exceeded
unreachable ];
    }
    then {
        policer 50M;
        count ICMP-OTHER;
        loss-priority high;
        next term;
    }
}

This is 8.2R2. It also objects (same as above) if I add this
as the final 
term:

term DEFAULT {
    then {
        count test;
        next term;
    }
}

-- 
Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
5ECA F8B1 2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, Apr 04, 2007 at 02:23:33PM -0400, Richard A
Steenbergen wrote:
> On Wed, Apr 04, 2007 at 10:42:07AM -0400, Jonathan
Looney wrote:
> > As I mentioned before (and as Juniper's
documentation indicates), there is
> > an implicit "accept;" when you modify
other things (which includes applying
> > counters, sampling, etc.).  If you want to
override that, you can use the
> > "next term;" action.  So, using that
action in the terms in your filter
> > chain may allow you to achieve your desired
result.
> 
> Except that when I finish off my BORDER filter with a
"next term", I get:

Ok, the plot thickens. I think I found the root of my issue.
It turns out 
that you can only configure a filter with a final term that
does "next 
term" if you are actively USING that filter in a
firewall chain.

In other words, you can commit the following:

firewall {
    filter EXAMPLE {
        whatever here;
        term FINAL {
            then {
                next term;
            }
        }
    }
}

ONLY if you have a reference to input/output-list [ EXAMPLE
SOMETHINGELSE 
] in your configuration. Objecting to its use at the end of
a chain or in 
a non-chain is somewhat logical (though annoying, since you
can't reuse 
the same filter code in both chains and non-chains), but not
letting you 
configure the filter at all even if it is not referenced
anywhere seems 
like a bug to me.

-- 
Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
5ECA F8B1 2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsppuck.nether.net

https://puck.nether.net/mailman/listinfo/juniper-nsp