On Thu, Sep 12, 2013 at 06:51:46AM +0200, Claudio Jeker wrote:
> On Tue, Aug 27, 2013 at 01:39:14PM +0200, Martin Pieuchot wrote:
> > I think that's the right approach but the current code generating
> > interfaces indexes is too clever from my point of view, it tries
> > to reuse the last index if possible. This could lead to some
> > funny races if we detach and reattach an interface before the
> > task get scheduled.
> >
> > So I'm ok with your diff if we avoid to reuse the last index too
> > soon. Diff below does that.
>
> We should not do that since this was done for tun(4) switching between
> modes without getting new ifindexes. It also reduces the holes in the
> ifindex array on system that dynamically allocate interfaces for e.g.
> VPNs.
>
Claudio is right.
The if_indexes are excessively used by the SNMP MIBs for various
interface-related values. I'm not just talking about the
implementation in snmpd(8), I'm talking about the actual standard MIBs
that use "ifIndex" values everywhere. Having dynamic / random /
inconsistent if_indexes confuse SNMP a lot.
For example, you have to query the IfIndex via SNMP to get further
information, like the ifName or statistics, and most monitoring
systems would save interface information based on the index - they
would not recognize that tun0 with if_index 10 is the same interface
(from an OpenBSD point of view) as tun0 with an if_index 11. It is
not guaranteed in OpenBSD, but we shouldn't make it worse.
btw., just have a look on a system with net-snmpd's MIBs. On a Mac,
which ships with Apple's version of net-snmp by default, go to
/usr/share/snmp/mibs and run:
$ grep -i ifindex * | wc -l
162
Reyk
