Since Mitchell's last email, this appeared from CVS in the place where the patch was supposed to be applied:
CLR(m0->m_flags, M_BCAST|M_MCAST); I skipped the patch and compiled the kernel with the source as I found it from CVS. With this new kernel everything works as I expected. arp broadcast requests coming into the bridge on one mpw are being seen by the router on the other mpw and arp replies are getting back to the requesting router. Thank you to everyone!!! On Tue, Apr 2, 2019 at 4:52 AM Mitchell Krome <mitchellkr...@gmail.com> wrote: > > > > On 2/04/2019 7:57 pm, Mitchell Krome wrote: > > > > > > On 2/04/2019 7:24 pm, David Gwynne wrote: > >> > >> > >>> On 2 Apr 2019, at 6:41 pm, Mitchell Krome <mitchellkr...@gmail.com> wrote: > >>> > >>> On 2/04/2019 2:08 pm, David Gwynne wrote: > >>>> Can you send me the hostname.* files and the output of ifconfig (showing > >>>> all interfaces)? > >>>> > >>>> You're using -current now, right? > >>>> > >>>> dlg > >>>> > >>>>> On 2 Apr 2019, at 08:15, lnel...@nelnet.org wrote: > >>>>> > >>>>> > >>>>> First of all the protected domain seems to do the opposite of what I > >>>>> need, but it may only appear to be the case because of the strageness > >>>>> with broadcast. When trying to ping (or send any traffic) between > >>>>> rtr01 and rtr02 and the two mpw2's are in the same protected domain, > >>>>> the arp requests die in the bridge. The arp never shows up at all on > >>>>> the other mpw. If I remove the mpw's from the protected domain, then > >>>>> the arp traffic gets through to the other mpw, but it doesn't get sent > >>>>> out properly by MPLS. It's sent out as MPLS broadcast traffic > >>>>> originating on the physical ethernet interface but with the right label > >>>>> for the pseudowire. Even though the arp request itself is broadcast > >>>>> traffic, I would expect it to be encapsulated in a unicast MPLS packet > >>>>> which is sent from the MAC of the bridge or the originating router and > >>>>> and sent as unicast to the destination router with the pseudowire's > >>>>> label. As it is now, even if the destination router could figure out > >>>>> what to do with these MPLS broadcast packets, it would respond to the > >>>>> physical interface and not the bridge. > >>> > >>> You only need the protected domain if you do a full mesh vpls (I.E. > >>> every router has a mpw to every other router). That wasn't the config > >>> you showed initially so I don't think you need it in your case. > >>> > >>> I am running the following diff to get MPLS to work with GRE as I had a > >>> similar ARP issue that was caused by gre_input tagging the packets as > >>> MCAST and then mpls_input dropping them. When I looked into it I didn't > >>> think that should cause the issue I was seeing for a real interface as > >>> ether_input didn't re-add the MCAST flag, but I also don't have a real > >>> box to test on. You can give it a go and see if it helps. > >> > >> I think you've found the problem. mpls_output replaces if_output though, > >> so for interfaces with mpls enabled on this, this change causes > >> BCAST|MCAST to be cleared for all outgoing packets. ie, it might break > >> things like ipv6 nd on ethernet interfaces. > > > > Yeah I had no idea what the impact of that change was, it seemed like a > > hack when I wrote it... > > > >> > >> What are you running on top of GRE that hit this? > > > > I have a vpls over GRE. And I had some weird behaviour where arp was > > being dropped only on paths that skipped the outer MPLS label. I.E. > > we're directly connected to the next-hop and implicit null means we > > never add the LSP label, only the service label. Thanks to tcpdump not > > knowing about multicast MPLS over GRE and printing weirdness I worked > > out what was going on and tracked it down to this. > > > >> > >> For now it might be better to have mpw etc clear the flags before calling > >> mpls_output. > > > > That make sense - anything going over an LSP (even if it's one that has > > no label due to implicit null) should never be multicast. > > > >> > >> Cheers, > >> dlg > >> > > Give this diff a try. I totally didn't see the initial post showing the > remote routers as microtik, so it's entirely possible they drop the > multicast MPLS ethertype, where as openbsd just treats it as normal > unicast unless you have it over gre. An almost identical diff can be > applied to mpe. > > diff --git sys/net/if_mpw.c sys/net/if_mpw.c > index 4348dff3f..e591e2a77 100644 > --- sys/net/if_mpw.c > +++ sys/net/if_mpw.c > @@ -672,6 +672,9 @@ mpw_start(struct ifnet *ifp) > > m0->m_pkthdr.ph_rtableid = ifp->if_rdomain; > > + /* Once we add a label it's a P2P tunnel */ > + m0->m_flags &= ~(M_BCAST | M_MCAST); > + > mpls_output(ifp0, m0, (struct sockaddr *)&smpls, rt); > } > > -- https://keybase.io/nelsonov
