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: > > >> Until recently >> (https://github.com/openbsd/src/commit/dc68b945bbc883db108ac48a07bb89 >> 778b75582a) >> bridge did split horizon detection by not allowing you to send >> between >> two mpw interfaces. In the case of a single VPLS this is the correct >> thing, but more generally it isn't quite right. Particularly when you >> want to bridge two seperate VPLS's. It's been removed now, and to >> achieve proper VPLS functionality with the change applied I found I >> had >> to add all mpw interfaces in the same VPLS to the same protected >> domain. >> >> If you update to current your config will probably work, but be >> mindful >> that for a full mesh VPLS if you don't put them in a protected domain >> you'll probably get a full mesh of broadcasts. > > Thanks. Your advice on upgrading the OS along with a hack of my own > got me to a working state, but it isn't a sustainable or stable state. > I installed the March 31 snapshot and the split-horizon problem was > resolved. However, there is still a problem with arp (and probably all > broadcast traffic, but I never get past arp). If I create a static arp > for rtr01 on rtr02 and rtr02 on rtr01, then everything else works. I > can send traffic back and forth between routers over the pseudowires. > This is a hack that works for now, but it's not really a solution. > > 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. > > Without the protected domain, this is what I see on both mpw > interfaces: > 11 4.015737 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has > 192.168.99.2? Tell 192.168.99.3 > 12 4.015751 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has > 192.168.99.2? Tell 192.168.99.3 > 13 5.015772 02:3b:c0:60:4c:95 ? ff:ff:ff:ff:ff:ff ARP 42 Who has > > With the protected domain, I only see these packets on the incoming > mpw. > > The destination router sees this: > 189 15.137231 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff > MPLS 60 MPLS Label Switched Packet > 202 16.161025 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff > MPLS 60 MPLS Label Switched Packet > 213 17.157232 6c:b3:11:4b:07:d4 ff:ff:ff:ff:ff:ff > MPLS 60 MPLS Label Switched Packet > > 02:3b:c0:60:4c:95 is the originating router. > 6c:b3:11:4b:07:d4 is the physical interface facing the destination > router > > By examining the MPLS packets I could see they were being sent to the > right label. I haven't figured out how to decode the payload, but it's > 42 bytes which is the exact same length as the inbound arp packets. > > Maybe I'm making wrong assumptions here. I would expect that either > the bridge does proxy arp or that the bridge would re-encapsulate > broadcast packets back into unicast MPLS/VPLS packets on the pseudwire > which then gets unencapsulated by the destination router and treated as > broadcast there. Meanwhile, of course, it would also broadcast that > same arp request out any other interface in the same bridge. >
