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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp