(~) # ip address show eth0
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:08:74:07:2d:44 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.64/24 brd 10.0.0.255 scope global eth0
inet 10.1.0.5/24 brd 10.1.0.255 scope global eth0
inet 10.2.0.5/24 brd 10.2.0.255 scope global eth0
inet 10.3.0.5/24 brd 10.3.0.255 scope global eth0
inet 10.4.0.5/24 brd 10.4.0.255 scope global eth0
Without binding to a specific IP, my outgoing traffic will always be from 10.0.0.64. However I may want to charge my traffic to a specific IP. I may also traffic shape to test things and compare them side by side. Etc, etc.
There's nothing broken by having multiple IPs assigned to an interface :)
-d
Renaud Deraison wrote:
On Sat, Jun 07, 2003 at 10:40:09PM +0200, Axel Thimm wrote:
Then the next step would be to cycle thru all the IP addresses I guessAre there benefits in using multiple source addresses? Would it be
(ie: if you have a eth0:0, eth0:1, eth0:2, eth0:3, ... eth0:N, have the
plugins use all the interfaces).
possible to make the set of available interfaces/aliases limited by
user input?
Apart from working around obviously broken network configurations (see the begining of this thread), it may allow the test of hosts which are configured to block all the traffic coming from rogue hosts (think of things like portsentry and all), as the checks would establish a connection from different source IP addresses (and this is mostly why I find it interesting to implement it).
-- Renaud
