Do you have a specific OpenBSD patch you obtained this from?

Part of the issue here is that we've got layer 3 and ethernet anchors and it's possible for an anchor to exist in one but not the other. So a pfctl -sA -a foo can be valid for one but not the other. I don't immediately see a better way of handling that than to just not raise errors either.

Thanks. I’ll try to review this (and your other patch) in the next days.

In D53070#1213136, @mjg wrote:

In D53070#1212847, @kp wrote:

I do still want to murder this code, but we'll wait until armv7 finally dies, or dies enough.

one can consider reverting this to a state prior to introduction of per-cpu counters. that is, just have a var updated directly. this loses updates, but maybe it's good enough for armv7?

Thanks for catching that. I'm not sure how I missed it, but I'm glad I remembered you wrote it and would be a good person to copy on a review.

LGTM

LGTM, ship it.

In D52852#1208672, @zlei wrote:

I've ever considered this approach, but this adds too many headaches. Well I'd propose to use vlxan(4) + bridge(4) + epair(4) if the underlay network is in different VNET.

For example, how can the admin change the tunnel parameters ( vni / vxlanlocal / vxlanremote / ports ) when the vxlan(4) interface is vmoved to another VNET ?

In D52852#1207545, @glebius wrote:

if_vmove bites again? I'm fine with adding more kludges around this problem as long as we all agree that eventually this thing needs to be removed and interfaces shall be fully destroyed and fully instantiated in a different jail.

I'm not qualified to review this in depth, but with the prerequisite patch included this works and is very, very useful.

I may be holding it wrong, but it still breaks for me:
It's a panic in vnet shutdown, so perhaps it's related to that: