[j-nsp] EX4200 filter buggy?

[Chris Morrow]

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