It's May and that means a new version of OpenBSD is out. My SNMP MIBs have been updated for 5.1 and are available for download on the OpenBSD SNMP MIBs page.

THIS WILL BE ONE OF THE LAST RELEASES OF THE MIBS FOR NET-SNMP.

During the OpenBSD 5.1 development cycle, I committed the CARP MIB to the base OpenBSD snmpd. The kernel sensor MIB has been in the base snmpd for a few releases now. That leaves the pf MIB which was committed to 5.1-current some weeks ago and will be present in the 5.2 release.

Update: For help running both snmpds at the same time, see Net-SNMP and snmpd Coexistence on OpenBSD

Now that OPENBSD-CARP-MIB and OPENBSD-PF-MIB have been added to the base snmpd in OpenBSD (CARP-MIB will be in 5.1-release, PF-MIB in 5.2, and the SENSOR MIB has been there since 4.5), I wanted to document the differences between these MIBs and the corresponding implementation of the MIBs that I wrote for Net-SNMP.

Both implementations provide the same set of OIDs and allow the same data to be retrieved. Whatever you were querying via Net-SNMP is available via snmpd.

What has changed is the base OID where the CARP and PF MIBs are rooted at as well as the name of certain OIDs.

The OpenBSD SNMP MIBs are now updated to compile under OpenBSD 5.0. Full details of how to install and use the MIBs are on the SNMP MIBs page.

There is no functional change in this release.

Download: obsd-mibs50.tar

As usual, if you find OpenBSD valuable, please make a donation to the project as they are dependent upon donations to cover many of their costs.

The OpenBSD routing table can be carved into multiple virtual routing tables allowing complete logical separation of attached networks. This article gives a brief overview of rtables and explains how to successfully leak traffic between virtual routing domains.

I recently had an issue with an OpenBSD firewall where the number of state table entries was hitting the default limit of 10,000. When this limit is reached, no new state entries can be created. If you're using "keep state", "modulate state" or "synproxy state" on your rules or if you're running OpenBSD 4.1 or newer (where "keep state" is the default on all rules) this could mean that:

• You cannot make new connections through the firewall
• You cannot make new connections to the firewall
• You cannot make new connections from the firewall

So.... if you hit the state table limit it's kinda bad, mmmkay?