[j-nsp] QFX5100 routing engine filter eats customer l2circuit packets

[Chris Wopat]

On 01/13/2017 12:03 AM, nebuvthomas at yahoo.com  wrote:
 > Hi Chris ,
 > could you pls test with 14.1x53-D40 in QFX5100 and let know the
 > outcome  .
 > Thanks ,Nebu V Thomas .

We do intend to test D40, are you aware of anything specific in this 
release that may address this?

We were also pointed to JSA10748 which clearly states:

	"Chipset on EX4300, EX4600, QFX3500, QFX5100 platforms
	sets destination port as CPU port even for transit
	multicast packets"


The rest of this JSA however is written quite confusingly and I'm not 
sure what to make of it.

It initially implies that there's an inherent 'accept all multicast' 
hidden term:

	"OSPF packets are making it to CPU due to implicit rule
	to allow IP reserved Multicast packets which is placed
	before last discard term"


but then later seems to contradict itself with:

	"QFX5100 platforms chipset's action resolution engine,
	Discard wins over any action and hence in the absence of
	implicit term to allow reserved multicast packets"


It is quite clear that transit multicast packets of some types (only 
IANA Reserved?) are punted to RE filter.

However, doing something logical like placing this term before the final 
'discard' term doesn't seem to fix it up:

	term multicast-accept {
	    from {
	        destination-address {
		224.0.0.0/4;
	        }
	    }
	    then {
	        count multicast-accept;
	        accept;
	    }
	}

If anyone has a concise explanation of what it's doing, I'm sure we can 
craft a proper filter, hopefully with a default action of 'discard' and 
not 'accept'.

--Chris