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

[nebu thomas]

Hi Chris ,
could you pls test with 14.1x53-D40 in QFX5100 and let know the outcome  .
Thanks ,Nebu V Thomas . 


      From: Chris Wopat <me at falz.net>
 To: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net> 
 Sent: Thursday, January 12, 2017 8:14 PM
 Subject: [j-nsp] QFX5100 routing engine filter eats customer l2circuit packets
   
We deployed QFX5100 w/ 14.1X53-D35 fairly recently with basic features
(v4/v6/bgp/ospf). These replaced some EX4200s in a similar role with little
issue.

We recently enabled LDP on the QFX to enable l2circuits for customers.
Config-wise, this was fine, known caveats of using native routing on unit 0
(although 14.1X53-D40 seems to have come up with a workaround for LDP to
function on IRB).

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.

If we drop lo0 input filter OR craft it differently to be overly accepting,
things work.

Logs on the firewall filter term indicate that the packets in question show
up as mac addresses with protocol 8847 (mpls unicast ethertype?). The macs
below are Src: LDP neighbor, Dst: the QFX in question.

Time      Filter    Action Interface    Protocol    Src Addr
Dest Addr
07:45:48  pfe      A      ae4.0        8847        b0:c6:9a:b7:ef:c4
 80:ac:ac:69:e1:f4
07:45:48  pfe      A      ae4.0        8847        b0:c6:9a:b7:ef:c4
 80:ac:ac:69:e1:f4
07:45:46  pfe      A      ae4.0        8847        b0:c6:9a:b7:ef:c4
 80:ac:ac:69:e1:f4

So it appears that a family inet filter is matching a unicast mpls packet
by mac address improperly? I have no idea why any of these would be punted
to the RE at all.

A few PRs that seem related are PR1028537 which states "L2 Control
protocols fail to come up between CEs across an ethernet pseudowire".

and hilariously, PR1032007 suggests "As a workaround, consider using an
alternative IGP protocol such as OSPF"

We have a case open with Juniper on this, but looking to see if others have
experienced this.

Ultimately we're trying to get a better understanding of WHAT type of
packets are punted to RE CPU so we can properly craft an ACL and pray it
fits in TCAM.

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