OpenBSD's bleeding edge pf

Even though I am no networks specialist, I have been involved in the business of having to understant how OpenBSD's packetfilter, aka pf, does round-robin load balancing.

The why of this expertise was quite straightforward : as pf does round-robin exactly well and balances the load exactly as expected, the first ever target, I mean the first target when the rules are set, has been found not to be the first in the list. This remark possibly matters 0.001% of all potential pf users, but I have then been required to check pf's predictability - an unpredictable pf's first was the most seriously fact feared...

This holds for OpenBSD 4.2, ie a fairly old one, but pf code has hardly changed since, and I have not seen any change in the lines involved here.

What happens is that, using BSD's TAILQ structures and macros, pf does choose the first in the list, then iterates before selecting the target. In a word, the first target that the load balancing hits is the second in the list. It is fully predictable and safe : a behaviour well in OpenBSD's tradition.

In the end, I had to patch the program that generated our pf rules, so the first does come first in the production system...