Peter Taps wrote:
> Folks,
> 
> I just got a new box with 6 identical NICs in it. I plan to install 
> OpenIndiana on it.
> 
> I plan to bond 4 NICs into one aggregated interface. The other two will stay 
> as individuals. Essentially, I will end up with 3 IP addresses.
> 
> I am familiar with ifconfig. However, this is the first time I am dealing 
> with multiple NIC cards. 
> 
> 1. Is there any concept of primary and non-primary IP addresses?

The DHCP client has such a concept, and uses it to select among
competing sources of system configuration information, but the system as
a whole generally does not.  Addresses are just addresses.

(Perhaps more important is "why do you ask?"  If you're trying to put
some address in a more privileged position than the other addresses,
then you may want to have a look at the ifconfig "usesrc" option.)

> 2. Do all the 3 ip addresses go in /etc/hosts file or just one ip address?

That's just part of name resolution.  It doesn't matter in terms of
configuring the interfaces.  You could put none of the addresses there,
or all of them, or any subset you want.  You could even make a single
name map to one or more of the addresses.

My advice would be to segregate the two concepts in your mind: name
resolution is an application layer feature, and addresses are a network
layer feature.  They're really quite independent.

(If you're asking about "best practices" for entries in /etc/hosts that
are also used in /etc/hostname.* files, then I'd suggest using
"name-interface" as a common style, as in "myhost-e1000g0".  But this is
really a preference thing.)

> 3. Do I specify gateway for all the 3 IP addresses or just one? I am thinking 
> it may confuse the routing algorithm.

That's a more complicated question.  See below.

> 4. Is there any need for me to manually manipulate the routing table?

"Maybe"

The real answer to these last two depends on how your network is
configured and what you expect your system to do.

If the addresses are on the same subnet, then you won't have much
opportunity for routing options.  The only really supported
configuration with multiple addresses on the same subnet is IPMP.

If they're on different subnets, then your system can act as a router
and forward packets between those subnets (if you want).  Or it can act
as a NAT (again, if you want).  Or it can act as just as a host on each
network.

Each of those options can be complex, depending (again) on how your
network is set up.  You may need to set up routes, or it might "just work."

Beware: when the system goes to send a packet from an application, the
system does not care AT ALL where the original packet came in.  The IP
layer doesn't know about the concept of a "reply."  It sees only
destination addresses, and will ALWAYS look for the best match for a
destination address and send the packet there.  Depending on your
network configuration, you may need to take that into account.  Replies
do not necessarily go back out the same interface over which requests
were received!

(In extreme cases, you may need to use the "to" feature in IP Filter to
force packets to go the way you want, because traditional IP routing is
based only on destination address, not source.  Similar to being caught
with the common inter-module C++ static initializer problem, though,
finding yourself in this position is a good indication that you've made
some bad life choices.  ;-})

As for the last question, personally, I'm a big fan of running
general-purpose routing protocols even for single-homed systems as a way
of automating kernel forwarding table ("routing table") maintenance.
Computing the contents of the forwarding table is a job for a computer,
and setting these things up by hand on more than a handful of systems in
any kind of non-trivial network is for the birds.

But there are certainly others with different opinions.

-- 
James Carlson         42.703N 71.076W         <carls...@workingcode.com>
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org

Reply via email to