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

[nebu thomas]

Hi Chris,
Per your email , I understand it is this specific payload coming thru the L2ckt which is reporting this issue .
<<<<<<<<<<<<Werecently enabled LDP on the QFX to enable l2circuits for customers.
A few customers had a variety of issues, circuits would only pass traffic successfully when we dropped our lo0 filter on the QFX . Filter in question has a default discard action.

Example: Customer running EIGRP on their equipment, hello packets (224.0.0.10) would ingress on QFX l2circuit ethernet-ccc interface and not egress on the far end. As a test, we also had them set static EIGRP
neighbors (Unicast) but they had the same issue.>>>>>>>>>>>>
So here the issue  you are seeing is when these particular pkts are the" payload " of L2ckt .
Hence my earlier suggestion to test with14.1X53-D40 , and verify whether it helps in your case .
--Thanks ,  Nebu.





      From: Chris Wopat <me at falz.net>
 To: juniper-nsp at puck.nether.net 
 Sent: Friday, January 13, 2017 10:15 PM
 Subject: Re: [j-nsp] QFX5100 routing engine filter eats customer l2circuit packets
   
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