> 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.
