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, lnelson@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.
>
No comments:
Post a Comment