[j-nsp] Juniper firewall chain behavior

[Steven Brenchley]

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 <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
>



-- 
Steven Brenchley
-------------------------------------
There are 10 types of people in the world those who understand binary and
those who don't.