OpenBSD's currently limited to using interfaces with an index < 32 for multicast, and on one of my machines I created and destroyed enough virtual interfaces during experimentation that some of the interfaces currently in use and that I would like to route multicast traffic to have indexes >= 32.
The simple solution is to reboot since I have fewer than 32 interfaces total, they'll renumber and everything will be fine. However, I saw if_attachsetup (in net/if.c) there's some code for looping through ifindex2ifnet twice to try to find an unused interface index, so I figured I could avoid rebooting by creating and destroying ~65000 virtual devices to wrap the counter, and then recreating the necessary interfaces so I could use them in multicast. Fortunately, I tested this idea first, because it actually leads to a kernel panic. :-) A second somewhat closer look at the kernel's interface handling code gives me the impression that the ifnet structures are never freed, the ifindex2ifnet table is never zero'd out, and so that loop always results in a panic. Looking at the history on net/if.c, I see a commit comment from itojun that "ifindex2ifnet could become NULL when interface gets destroyed, when we introduce dynamically-created interfaces", but this was four years ago and if_vlan has existed for 7 (though seemingly in a different form then). What does "dynamically-created" mean if not something like vlan/gif/carp/trunk? Is there anything major preventing ifindex2ifnet being cleared? (If it's just developer interest, it *looks* like it should be a straight-forward-enough fix that I'd be interested in trying to write a patch.)
