[j-nsp] Juniper firewall chain behavior

[Richard A Steenbergen]

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)