Hi, On Mon, Dec 27, 2021 at 10:33 PM David Gwynne <[email protected] <mailto:[email protected]>> wrote: On Sun, Dec 26, 2021 at 07:46:01AM +0000, Simon Baker wrote: > Hi, > > Struggling a bit debugging something, and hoping someone can point me in the > right direction.
ok. after staring at this for a while im pretty sure it's an actual bug rather than a misconfiguration. This makes me happy :-) > cat /etc/hostname.vport1 > group vlan-interface > link0 as an aside, link0 on a vport doesn't do anything. Indeed - I'd got to the 'exhaustive iterative testing' part of trying to get it working. I've taken it off now. > I???m a little perplexed as to what???s going on here - it???s almost as if > the veb doesn???t believe it???s responsible for this packet. It seems to be > happily routing packets from the LAN to hosts on a VLAN, it???s just the > return traffic that never arrives. you're right, the veb doesn't think it should handle the packet. veb sets and clears a flag on packets going in and out of vport interfaces as a sort of loop prevention mechanism. because vlan packets are handled before veb can clear this flag, the packet ends up being marked as inside veb when it goes through the network stack. when it comes out the stack on a vport interface again, it gets dropped because of this flag still being set. there's a diff below that moves away from the flag to try and avoid this problem. can you give it a go in your setup? Had it running for over 8 hours with behavior now being entirely as expected, PF rules on the VLAN interfaces work as expected and multicast is crossing over the network (via a repeater) , devices are able to respond cross network, essentially everything is working again :-) Added some VM hosts into the veb0 bridge, they're also able to operate correctly and they can also participate in the VLANS either as routed hosts, or hosts doing their own VLAN encap. Thanks for the fix, Simon.
