From: Davy Durham <pubaddr2@davyandbeth.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: virtual NICs
Date: Wed, 16 Nov 2005 15:56:27 -0600 [thread overview]
Message-ID: <437BAB0B.1090504@davyandbeth.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0511161540080.5251@chaos.analogic.com>
First, thanks for the prompt response.
linux-os (Dick Johnson) wrote:
>Of course there is extra work! Any time something has to be checked
>(filtered), there is the overhead of the filtering. In the case of
>two or more IP addresses, the software has to perform an ARP on two
>or more IPs. This means that it needs to "listen" for more queries.
>Note that machines on Ethernet, communicate using their hardware-
>addresses i.e., the "IEEE station address". But, the initial route
>to the target machine needs to be set up by broadcasting an IP address,
>thereby asking everybody on the LAN if the IP address belongs to them.
>Hopefully only one machine answers. This sequence is called ARP
>(address resolution protocol).
>
>
>
My question was whether the one being defined to eth0 has an advantage
over the one assigned to eth0:0 since one is real and one is virtual.
My uninformed instinct told me to wonder if the NIC hardware itself
somehow gets told to handle the IP assigned to eth0 and something in the
linux software has to handle the IP assigned to eth0:0
I realize that the machine will have to do more work total. But I
wonder if it's any more work than if the server has two NICs with two
different IPs.
>Adding more IP addresses is like adding more machines as far as
>the source (perhaps a router) is concerned. Adding more IP addresses
>to a single host is sometimes necessary, but it is not without
>cost. Basically, don't do it unless it's necessary.
>
>
>
It's necessary because of the in-born inability for name based virtual
hosting to be done over SSL (though I think this inability was
unnecessary in that it could have been relaxed if just a little bit of
unsecured data could be transmitted in the SSL header allowing the
server to make some decision based on that clear data.. but that's
another matter).
Thanks again,
Davy
next prev parent reply other threads:[~2005-11-16 21:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-16 20:14 virtual NICs Davy Durham
2005-11-16 20:49 ` linux-os (Dick Johnson)
2005-11-16 21:56 ` Davy Durham [this message]
2005-11-16 22:42 ` Lee Causier
2005-11-17 1:05 ` Bernd Eckenfels
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=437BAB0B.1090504@davyandbeth.com \
--to=pubaddr2@davyandbeth.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.