On 01/13/2017 12:03 AM, nebuvtho...@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

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to