Hi, On Wed, Dec 02, 2015 at 12:58:58AM +0100, Hannes Frederic Sowa wrote: > Hello, > > On Tue, Dec 1, 2015, at 23:43, Maximilian Wilhelm wrote: > > How should net-snmp handle cases where new interfaces come up on old > > and now unused numbers? What should it report? That would escalate the > > problem a lot IMHO. > > ifindexes are only reused when the ifindex allocator wraps around which > should hopefully take a while and that is exactly my point. > > In general the ifindexes are designed to not be reused very fast. Most > ifindex usage is in socket layer where one specifies which way a packet > should go in sendto/msg calls to override routing lookups or use link > local addresses. Imagine an application looks up an interface and > determines the ifindex to send out data to an ipv6 link local address > (which needs the ifindex obviously). If we don't bias the ifindex > selection during device creation time the app will get an error and > won't race with other tunnels being setup and can handle that > accordingly because new tunnels simply have new ifindexes until the > per-namespace counter wraps around. If we have name based policies we > have to audit user space applications how they do interface name > selection to protect them against reusing interface names. Based on your > mail you simply already do ensure that interface names are unique, so > your monitoring software should use just them. > > I simply see this feature being misused way too easily.
This is very similar to processes and their pids. On (small) embedded systems it's common that a given process will always have the same pid after boot. Then for some reason a process is restarted and you want it to have that same pid, which is not good. Same semantics would apply, I think. Monitoring software has to know how to handle with that change and cope with it. I don't know the details but I know that it's also possible to monitor processes via SNMP, meaning that monitoring apps must already do that for processes, then why not for interfaces? Marcelo -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html