Reyk Floeter wrote:
> Yes, in theory if_index should be fixed and return a consistent number
> between 1 and the number of interfaces. But this is obviously
> difficult and I'm not sure if it's worth the effort. So the "hack"
> that you're going to remove was a best effort. But putting another
> interface index abstraction layer in userland (via snmpd or some
> shared db) is just not the right way to do it. We either have a
> reliable if_index from the kernel or we don't. But inventing another
> thing in userland doesn't make sense to me.
If above theory doesn't dictate all interfaces must exist (it shouldn't
because of hot-plug interfaces), kernel can operate on fixed predefined
ifIndex table like this:
tun ifIndex (only have 256 of them because of unit_no):
1 - 00:bd:xx:xx:xx:00 - tun0
256 - 00:bd:xx:xx:xx:ff - tun255
vether ifIndex (only have 65536 of them?):
257 - fe:e1:ba:d0:xx:xx - vether0
65,792 - fe:e1:ba:d0:xx:xx - vether65535
physical ifIndex (claim to support ~1M of physical interfaces):
65,793 - 00:25:90:xx:xx:aa - em0
65,794 - 00:25:90:xx:xx:ab - em1
1,179,906 - xx:xx:xx:xx:xx:xx - foo77
trunk ifIndex (claim to support ~17M of trunk interfaces, by unit_no):
1,179,907 - xx:xx:xx:xx:xx:xx - trunk0
19,005,699 - xx:xx:xx:xx:xx:xx - trunk16999999
vlan ifIndex (claim to support ~280M of vlan interfaces, by unit_no):
19,005,700 - xx:xx:xx:xx:xx:xx - vlan0
304,218,372 - xx:xx:xx:xx:xx:xx - vlan279999999
and so on, up to 2,147,483,647.
IMO, cloners aren't so problematic (because of algorithmically controlled
enumeration and unit number assignment) as physical interfaces are.
I think, the best is to let ifIndexes be assigned to physical interfaces
via ifconfig, but let cloners to do their assignments automatically.
And do not let snmpd to operate on interface without an ifIndex: having no
ifIndex means no interface available.
