[j-nsp] Juniper firewall chain behavior

[Jonathan Looney]

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 <ras at e-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 <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>