Egregoros

Signal feed

Peter Wemm

@karinjiri@soc.crashed.org

Roaming FreeBSD/Linux/Kernel/Networking/Container/Security/CDN/Cloud/k8s/etc troublemaker.
Long time FreeBSD developer.
Ex-Yahoo! Quietly working on FreeBSD at $newjob.

Posts

Latest notes

In the blog post you mentioned 14.3 and showed ifconfig commands that looked like the old system. Since switching to the new system here I've used host addresses exclusively on the vlan* members of the bridge - it wasn't even allowed to put addresses on the bridge itself. I vaguely recall a sysctl could change that.

My ipv6 network at home is a bit of a mess. I have:
* gateway box fetches IPv6 prefix-delegations with the antique WIDE dhcp6 client from 2008 and assigns things to subnets
* gateway box runs many rtadvd announcements for dynamic addressing and ULA assignments. There are both temporary and "permanent" ULA prefixes.
* gateway box runs kea dhcp server for both v4 and v6 which includes giving out fixed public and ULA ipv6 address assignments
* FreeBSD boxes (desktop, server, and bhyve VMs) have a mixture of static IPv6 addresses configured, and kea-assigned addresses, and SLAAC style self-assignments.
* an active tayga 6-to-4 translator:
(ping6 github.com) 16 bytes from 64:ff9b::8c52:7404, icmp_seq=0 hlim=50 time=33.716 ms
* bhyve VMs with tap interfaces assigned to bridges with SLAAC or set in static configs. Some with SR-IOV vf interfaces on a second interface.
* VNET jails with single or multiple epairs, most static configs but they also fetch temporary SLAAC addresses.
* there are apple devices announcing rogue prefixes for Matter/Thread radio mesh subnets.
* there's a home assistant box doing who-knows-what that is also tunneling ipv6 <-> Thread radio meshes.
* The apple devices have a nasty habit after a reboot of deciding "OH HEY LETS RENUMBER ALL THOSE ULA PREFIXES!!!! It'll be FUN!"

This setup tortures the network in every way I can imagine but there's no difficulty getting addresses with the new bridge setup. If anything there's too many addresses. But none on a bridge interface anywhere.

I think what you're doing is closer to the old way. You've created a bridge and told it about vlans, but haven't enabled hwfilter mode. When you added the interface to it you didn't tell it what vlans it should be configured for. I think.

I'm not sure where the vlans_bridge0 parameter fits in but this is what I have:
ifconfig_ixl0="up -lro -txcsum -txcsum6 -tso4 -tso6 -mextpg"
cloned_interfaces="${cloned_interfaces} bridge0"
ifconfig_bridge0="vlanfilter addm ixl0 tagged 99-115 up"
# core network
cloned_interfaces="${cloned_interfaces} vlan100"
ifconfig_vlan100="vlan 100 vlandev bridge0 10.0.0.8/24"
# iot-snowflakes
cloned_interfaces="${cloned_interfaces} vlan112"
ifconfig_vlan112="vlan 112 vlandev bridge0 10.0.12.8/24"

The result looks something like this:
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=10<VLAN_HWTAGGING>
bridge flags=1<VLANFILTER>
member: e0a_wfe flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 96 priority 128 path cost 2000 vlan protocol 802.1q untagged 100
...
member: ixl0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q tagged 99-115
groups: bridge
vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
inet 10.0.0.8 netmask 0xffffff00 broadcast 10.0.0.255
vlan: 100 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
vlan112: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
inet 10.0.12.8 netmask 0xffffff00 broadcast 10.0.12.255
vlan: 112 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0

Short version: bridge in hwtagging mode. Each member added identifies what vlans it wants and what's tagged/untagged. e0a_* is half of a jail epair.
@dvl I saw your blog posts on it. I have options. It’s just a risk vs time vs effort vs learning something trade off. I’ve done far worse things remotely. You haven’t truly lived until deploying in-place headless consoleless FreeBSD->linux and Linux->FreeBSD converters. In this case I mostly need to be careful about what data belongs in the BE and what doesn’t.
So, I did something silly. I started backing up my primary #FreeBSD desktop after .. omg nearly 30 years. It was first installed in ~1996 and has been continuously, incrementally upgraded since then. Hardware, OS upgrades, CPU, etc.

Anyway, I was going to try and convert it to use #zfs boot environments. That's something that can't be done in-place on a legacy installation from ~1996. It's using ZFS for years but the FS layout doesn't allow a trivial rename etc in single user mode.

Then I realized.. wait, I've got important stuff on there. It's not being backed up regularly. This might not be a great idea.

So, #zrepl to the rescue! So now there is a second copy. No, a restore has not been attempted but I am reusing a process that I have tested before. Close Enough(tm), right? Nothing Could Go Wrong With This Plan(tm), right?

(Why zfs boot environments? I'm working on fixing some really annoying FreeBSD pkgbase, pkg etc limitations/problems and boot envs would be damn convenient! And of course, backups.)