(ex-platform causes death/dismemberment/pain/anguish) On 12/15/10 09:18, Charlie Allom wrote: > On Sun, Dec 12, 2010 at 09:49:02PM -0600, Richard A Steenbergen > <[email protected]> wrote: >> On Mon, Dec 13, 2010 at 10:51:26AM +0800, Gavin Tweedie wrote: >>> >>> >>> I also have a case open with JTAC. >> >> For >> example, if you configured a single term to match on 0.0.0.0/8, >> 1.0.0.0/8, or 3.0.0.0/8, the firewall compiler would try to optimize >> that match into "0.0.0.0/6 && !2.0.0.0/8". The problem is the NOT match >> wasn't supported on the EX, so it would ignore that operation and match >> the 2.0.0.0/8 packets anyways, even though you didn't configure that >> range in your filter. > > Richard how did you come to this realisation? Was this a JTAC case or do > you have a way to look at the filter optimization?
juniper doesn't normally release this sort of data, you can run some command to dump the optimized code out though... it's kinda ugly :( > I think I have seen similar outcomes, but don't know how to match it up > with proof. try this fun experiment: 1) apply loopback filter, permit ssh/bgp/ospf (things you include normally in your loopback filter) 2) if you permit 'icmp' or 'traceroute' to the device (use the device interface ips in the from clause, potentially with a prefix-list built from an apply-path expression 3) traceroute to something behind/beyond the device note that the device doesn't show up in the traceroute? ;( packet processing/firewalling fail. -chris _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
