On Fri, Sep 13, 2013 at 10:45:57AM +0200, Martin Pieuchot wrote:
> > No, that's utterly stupid. The interface index is a value that is
> > supposed to be consistent across the system. How should it be synced
> > with other userland tools? How would you handle it in if_nametoindex
> > and friends?
>
> So what do *you* suggest which is not utterly stupid?
>
I stopped suggesting things that get ignored.
> I can't see where it is written that the interface index should be
> consistent, from the RFC 1156, I read:
>
> ifIndex { ifEntry 1 }
>
> A unique value for each interface. Its value ranges
> between 1 and the value of ifNumber. The value for each
> interface must remain constant at least from one re-
> initialization of the entity's network management system
> to the next re-initialization.
>
I read your statement and read the RFC text and I totally don't get
how they fit together. Isn't the RFC saying the opposite of what
you're saying? I will get some coffee now and try to read it again
afterwards.
>
> > As I said before: it is not a big issue for snmpd and I can live with
> > the fact that your changes might confuse SNMP clients a bit. Just go
> > ahead, but
>
> Well it looks like a big issue because you keep complaining.
>
> Would you exclaiming what "confusing SNMP clients" means? What breaks?
> Can it be solved? What is the technical problem here?
>
Well
> > > In the end we need two different tables, one with an unique index per
> > > interface (to avoid passing pointers in kernel) and another one with
> > > the biggest index equals to the number of interfaces (to not confuse
> > > snmp). IMHO we don't need these two tables in the kernel.
> > >
> >
> > please read the history: if_index _was_ created for SNMP. Then it was
> > used for routing and other stuff. Now you want to use it as a "PID"
> > for something else. Fine. But please stop claiming that SNMP is
> > doing anything wrong with if_indexes when they were created FOR SNMP.
>
> I'm not clamming anything that SNMP is doing wrong, I'm not rewriting
> history, I'm just saying that the actual index generation code is broken
> for SNMP because it doesn't returns a value between 1 and the number of
> interfaces.
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.
So let's get back to the technical part:
- Do you even have to use if_index? Is it performance critical or
could you lookup the interface by name?
- I think introducing a new kernel-only if_id for your needs would be
the better approach. Then we could fix if_index to conform to the
definition "between 1 and number of interfaces".
- But I can also live with a modified if_index that is unreliable.
What am I suggesting? In this situation: just continue.
Reyk
