[j-nsp] EX4200 filter buggy?
morrowc at ops-netman.net
Wed Dec 15 11:00:10 EST 2010
(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 <ras at e-gerbil.net> wrote:
>> On Mon, Dec 13, 2010 at 10:51:26AM +0800, Gavin Tweedie wrote:
>>> I also have a case open with JTAC.
>> example, if you configured a single term to match on 0.0.0.0/8,
>> 188.8.131.52/8, or 184.108.40.206/8, the firewall compiler would try to optimize
>> that match into "0.0.0.0/6 && !220.127.116.11/8". The problem is the NOT match
>> wasn't supported on the EX, so it would ignore that operation and match
>> the 18.104.22.168/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
More information about the juniper-nsp