On Tue, 2006-08-22 at 13:54 -0700, Andy Rumer wrote:
> We're trying to migrate to a newer version of an application on Solaris 10,
> while trying to manage some similar functionality we had in older Solaris
> releases.  In previous versions we had multiple hosts file ip entries with
> the same name.  The application called gethostbyname and always returned
> the first entry from the hosts file.
> 
> Now it appears the newer verision of the application calls getipnodebyname
> which appears to return the closest match of an address to a configured
> interface on the box.  This leads to the application trying to access a host
> over a less preferred network.  We are only working with IPv4 addresses.
> 
> Does anyone know of a way to prefer networks in other ways in this scenario?  
>
> I'm looking at /etc/inet/ipaddrsel.conf, but I'm having trouble
> understanding what the ::ffff:0.0.0.0/96 actually means, and if I
> could somehow specify a more specific IPv4 subnet with a higher precedence
> to get the results we're looking for.  I'm mostly just having trouble
> understanding the syntax as it relates to IPv4.  Any pointers?

::ffff:0:0/96 is the IPv4-mapped IPv6 prefix.  It's how IPv4 addresses
are passed around the various IPv6 APIs in the OS.  Admittedly, it would
be much friendlier if this particular syntax were not required for this
interface, and if the ipaddrsel command could imply IPv4-mapped prefixes
from a dotted-quad IPv4 address in the table...  I'll file an RFE.

There are two things to try:

One is to specify specify additional IPv4 prefix entries
in /etc/inet/ipaddrsel.conf to give your preferred destination a higher
precedence.  For example, if there are two networks of interest, say
12.12.12.0/24 and 13.13.13.0/24, and you would prefer 12.12.12.0
addresses over 13.13.13.0 addresses, you could add corresponding entries
as follows:

# Prefix                Precedence      Label
::1/128                         50      Loopback
::/0                            40      Default
2002::/16                       30      6to4
::/96                           20      IPv4_Compatible
::ffff:12.12.12.0/120           12      IPv4
::ffff:13.13.13.0/120           11      IPv4
::ffff:0.0.0.0/96               10      IPv4

The second is to uncomment the SORT_ADDRS=FALSE line
in /etc/default/nss, and that will cause libnsl to not attempt to sort
addresses returned from back-end lookups.  This has nasty side-effects,
however, such as placing potentially unreachable addresses at the front
of the list returned by name lookup routines.  Steer clear of this knob
if at all possible.

-Seb


_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to