On 26/07/10 08:18 AM, James Carlson wrote:
darren.r...@oracle.com wrote:
Author: Darren Reed<darren.r...@oracle.com>
Repository: /hg/onnv/onnv-gate
Latest revision: 2794a0c9cce102961d08f075ee1f569073b99786
Total changesets: 1
Log message:
6965774 bound the interface index in IP to [1,65535]
Files:
update: usr/src/uts/common/inet/ip/ip_if.c
update: usr/src/uts/common/net/if.h
I suspect this change will have two serious effects:
- SNMP is now potentially broken. The interface IDs cannot be reused
without an engine reboot indication, and restricting to a 16 bit range
makes reuse very much more likely than before.
Which interface IDs cannot be used?
Do you mean to say that SNMP cannot handle two different
network interfaces having the same interface ID during the
lifetime of the SNMP agent?
But to me this sounds like a fundamental problem with SNMP and
that choosing 32bits for a network interface identifier does not
represent a better design or solution, only a pushing out the
problem to some point in the future and hoping that it never
appears on your watch.
- Systems with large numbers of virtual interfaces (tunnels and PPP
links, for example) may now run out of identifiers when this wasn't
previously possible.
This was considered.
65,535 is a LOT of network interfaces.
Further, the limit is only per instance of IP.
A given installation of Solaris can only support 1024 zones and
it would require every zone to be using a shared network instance
and 64 network interfaces for it to be a problem in that direction.
Can you imagine how long "ifconfig -a" would take to run on a
system with that many network interfaces?
I suspect that anyone who is pushing beyond using 1000 network
interfaces at any particular point in time is going to be facing
all sorts of performance issues.
Was any consideration given to fixing the applications that rely on
these old BSD interfaces? That's what we had been doing since at least
2.6 -- making the applications aware that ifIndex numbers could be
ambiguous, and using other means to verify the data. There are numerous
examples of this work in the source base. Let me know if you need
pointers; I can google it for you. ;-}
In general, having aliases in the ifIndex space seen by the old BSD
interfaces is "not a problem" for most applications, because getting
routing socket messages just means that it's time to use the ioctls to
get the real current information. The routing socket messages
themselves contain too little data to make a fully functioning program
on Solaris anyway.
Or perhaps "fixing" these old interfaces with some new mechanism?
In fixing the situation to support more than 16bits for a network
interface identifier, changes to the routing message would be
required. That change would then break our compatibility with
every open source application that exists and uses those messages.
It would also break compatibility with older applications built for
Solaris. If a new interface was introduced and the old one left in
place for compatibility reasons, that doesn't stop the ones using
the old interface from causing strange behaviour when the index
exceeds 65535. The sockaddr_dl message is used by applications to
both send and receive routing messages.
In the quick survey that I did of source code that used this interface,
only the IKE daemon appeared to be able to changed easily to use
SIOCGLIFINDEX.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
