So we've noticed, and taken issue with this behavior.
If you have several IP aliases on an interface (eth0:0, eth0:1, eth0:2) you
get inconsistent behavior when downing them.
* if I 'ifconfig down' eth0:1, I am left with eth0:0 and eth0:2
* if I 'ifconfig down' eth0:0, eth0:1 and eth0:2 go away, too
I assert that this should not happen. I have a simple patch to fix this
behavior, but I want to know a few things.
* Is this supposed to happen? Why?
* Is it correct that both the real interface and the first alias are marked
as primary (! IFA_F_SECONDARY), while all other aliases are secondary? It
seems to me that ALL ALIASES should be secondary. Is this wrong? Why?
Can anyone fill me in?
Thanks
Tim
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[email protected]
Hello,
Tim Hockin wrote:
> If you have several IP aliases on an interface (eth0:0, eth0:1, eth0:2) you
> get inconsistent behavior when downing them.
>
> * if I 'ifconfig down' eth0:1, I am left with eth0:0 and eth0:2
> * if I 'ifconfig down' eth0:0, eth0:1 and eth0:2 go away, too
>
> I assert that this should not happen. I have a simple patch to fix this
> behavior, but I want to know a few things.
>
> * Is this supposed to happen? Why?
> * Is it correct that both the real interface and the first alias are marked
> as primary (! IFA_F_SECONDARY), while all other aliases are secondary? It
If you look again into the sources you can see that
secondary addresses are those that are attached when there is
already IP address from the same subnet. The aliases don't play
here nor their number. The analyze points that the semantic
covers the selection of source addresses (probably when you don't
use preferred source address in your routes) and in some way they
look as an IP address lookup and kernel routes handling
optimizations. The other thing that I don't know is that may be
there is some compatibility reasons for such secondary flag.
> seems to me that ALL ALIASES should be secondary. Is this wrong? Why?
IMO, to keep the semantic of "attaching or detaching an IP
address" clear and independent, all addresses should be primary
because it is hard to keep correct setup when it is dynamicaly
changed. There is already mechanism (the scope) to make one address
"secondary" in the source address selection mechanism or even there
is a preferred source to make it primary. This is my opinion but
may be I'm missing some other usage. At least, the current handling
looks very dangerous.
Regards
--
Julian Anastasov <[email protected]>
Actually it is quite sane. The tool is not.
Switch to 'ip' instead of 'ifconfig', several large distros now include
it. Addresses can be added and removed completely indiscriminately on
interfaces.
The "ethN:X" is a legacy design that is now deprecated.
David
Julian Anastasov wrote:
> Hello,
>
>Tim Hockin wrote:
>
>>If you have several IP aliases on an interface (eth0:0, eth0:1, eth0:2) you
>>get inconsistent behavior when downing them.
>>
>>* if I 'ifconfig down' eth0:1, I am left with eth0:0 and eth0:2
>>* if I 'ifconfig down' eth0:0, eth0:1 and eth0:2 go away, too
>>
>>I assert that this should not happen. I have a simple patch to fix this
>>behavior, but I want to know a few things.
>>
>>* Is this supposed to happen? Why?
>>* Is it correct that both the real interface and the first alias are marked
>>as primary (! IFA_F_SECONDARY), while all other aliases are secondary? It
>>
>
> If you look again into the sources you can see that
>secondary addresses are those that are attached when there is
>already IP address from the same subnet. The aliases don't play
>here nor their number. The analyze points that the semantic
>covers the selection of source addresses (probably when you don't
>use preferred source address in your routes) and in some way they
>look as an IP address lookup and kernel routes handling
>optimizations. The other thing that I don't know is that may be
>there is some compatibility reasons for such secondary flag.
>
>>seems to me that ALL ALIASES should be secondary. Is this wrong? Why?
>>
>
> IMO, to keep the semantic of "attaching or detaching an IP
>address" clear and independent, all addresses should be primary
>because it is hard to keep correct setup when it is dynamicaly
>changed. There is already mechanism (the scope) to make one address
>"secondary" in the source address selection mechanism or even there
>is a preferred source to make it primary. This is my opinion but
>may be I'm missing some other usage. At least, the current handling
>looks very dangerous.
>
>Regards
>
>--
>Julian Anastasov <[email protected]>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
> Actually it is quite sane. The tool is not.
>
> Switch to 'ip' instead of 'ifconfig', several large distros now include
> it. Addresses can be added and removed completely indiscriminately on
> interfaces.
>
I'd like to, but there's nothing like documentation with it.
Petr
P.S.: Yes I know about examples in Linux 2.4 routing, but manpage would be
nicer.
I agree that the documentation for 'ip' is sparse or hard to grok.
Learn by example. I have some scripts on http://blue-labs.org/, the
rc.* scripts. These two scripts are my live scripts and cover a lot of
things from simple to advanced.
(comments appreciated for corrections or improvements)
David
Petr Titera wrote:
>>Actually it is quite sane. The tool is not.
>>
>>Switch to 'ip' instead of 'ifconfig', several large distros now include
>>it. Addresses can be added and removed completely indiscriminately on
>>interfaces.
>>
>I'd like to, but there's nothing like documentation with it.
>
>Petr
>
>P.S.: Yes I know about examples in Linux 2.4 routing, but manpage would be
>nicer.
>
Hello,
On Wed, 24 Oct 2001, David Ford wrote:
> Actually it is quite sane. The tool is not.
Wrong. It does not depends on the used tools.
> Switch to 'ip' instead of 'ifconfig', several large distros now include
> it. Addresses can be added and removed completely indiscriminately on
> interfaces.
You have to check it again. I'm using ip from quite long time.
> The "ethN:X" is a legacy design that is now deprecated.
It is a naming scheme, nothing more.
> David
Regards
--
Julian Anastasov <[email protected]>
On Tue, Oct 23, 2001 at 10:54:30AM -0700, Tim Hockin wrote:
> So we've noticed, and taken issue with this behavior.
>
> If you have several IP aliases on an interface (eth0:0, eth0:1, eth0:2) you
> get inconsistent behavior when downing them.
>
> * if I 'ifconfig down' eth0:1, I am left with eth0:0 and eth0:2
> * if I 'ifconfig down' eth0:0, eth0:1 and eth0:2 go away, too
This was reported ages ago too.
>From what I remember, because eth0:x is an AF_INET hack only, you
should only do a down of it with an AF_INET socket. Some
versions of ifconfig did it with a socket of the wrong type,
which resulted in the whole interface going down.
Which version of ifconfig (nettools) are you using?
Kurt
On Wed, Oct 24, 2001 at 01:36:40PM +0200, Kurt Roeckx wrote:
> On Tue, Oct 23, 2001 at 10:54:30AM -0700, Tim Hockin wrote:
> > So we've noticed, and taken issue with this behavior.
> >
> > If you have several IP aliases on an interface (eth0:0, eth0:1, eth0:2) you
> > get inconsistent behavior when downing them.
> >
> > * if I 'ifconfig down' eth0:1, I am left with eth0:0 and eth0:2
> > * if I 'ifconfig down' eth0:0, eth0:1 and eth0:2 go away, too
Oops, I seem to have responded a little too fast.
It used to be, if you ifconfig down eth0:1, that eth0, eth0:2
were gone too.
If you down eth0:0, does eth0 go down too?
Kurt
----- Original Message -----
From: "Petr Titera" <[email protected]>
To: <[email protected]>
Sent: Wednesday, October 24, 2001 2:18 AM
Subject: Re: issue: deleting one IP alias deletes all
> > Switch to 'ip' instead of 'ifconfig', several large distros now include
> > it. Addresses can be added and removed completely indiscriminately on
> > interfaces.
> >
>
> I'd like to, but there's nothing like documentation with it.
>
iproute should come with the ip command reference.
On RedHat 7.1, it lives here:
/usr/share/doc/iproute-2.2.4/ip-cref.ps
I've converted it to PDF, if you don't like PS:
http://www.hellninjacommando.com/misc/ip-cref.pdf
They accused us of suppressing freedom of expression.
This was a lie and we could not let them publish it.
-- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship
David Ford wrote:
>
> Actually it is quite sane. The tool is not.
>
> Switch to 'ip' instead of 'ifconfig', several large distros now include
> it. Addresses can be added and removed completely indiscriminately on
> interfaces.
>
> The "ethN:X" is a legacy design that is now deprecated.
Minor issue...if I create (using 'ip') two addresses on the same subnet on the
same device, one of them is primary and the other is secondary. If I then
delete the primary address, the second one goes with it.
I submit that this is bad behaviour.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
> > Switch to 'ip' instead of 'ifconfig', several large distros now include
> > it. Addresses can be added and removed completely indiscriminately on
> > interfaces.
> >
> > The "ethN:X" is a legacy design that is now deprecated.
>
> Minor issue...if I create (using 'ip') two addresses on the same subnet on the
> same device, one of them is primary and the other is secondary. If I then
> delete the primary address, the second one goes with it.
>
> I submit that this is bad behaviour.
This is the same behavior for which I am proposing fixing. The origin of
the thread, if you will.
Tim
Tim Hockin wrote:
>
> > > Switch to 'ip' instead of 'ifconfig', several large distros now include
> > > it. Addresses can be added and removed completely indiscriminately on
> > > interfaces.
> > >
> > > The "ethN:X" is a legacy design that is now deprecated.
> >
> > Minor issue...if I create (using 'ip') two addresses on the same subnet on the
> > same device, one of them is primary and the other is secondary. If I then
> > delete the primary address, the second one goes with it.
> >
> > I submit that this is bad behaviour.
>
> This is the same behavior for which I am proposing fixing. The origin of
> the thread, if you will.
Yes, precisely. I was rebutting David Ford's statement above about addresses
being added and removed indiscriminately using 'ip' but not using aliases.
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
That is IMO bad behavior, it didn't use to do this because I have
scripts that rely on this behavior.
I'll take it up with the author, Alexey.
David
Christopher Friesen wrote:
David Ford wrote:
>Actually it is quite sane. The tool is not.
>
>Switch to 'ip' instead of 'ifconfig', several large distros now include
>it. Addresses can be added and removed completely indiscriminately on
>interfaces.
>
>The "ethN:X" is a legacy design that is now deprecated.
>
Minor issue...if I create (using 'ip') two addresses on the same subnet on the
same device, one of them is primary and the other is secondary. If I then
delete the primary address, the second one goes with it.
I submit that this is bad behaviour.
Chris
David Ford wrote:
>
> That is IMO bad behavior, it didn't use to do this because I have
> scripts that rely on this behavior.
>
> I'll take it up with the author, Alexey.
It has done this since 2.2.x, when we first filed and fixed this bug. I've
pinged Alexey, and haven't heard back yet. Maybe you'll have better
response time.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[email protected]
On Tue, 23 Oct 2001, Tim Hockin wrote:
> So we've noticed, and taken issue with this behavior.
>
> If you have several IP aliases on an interface (eth0:0, eth0:1, eth0:2) you
> get inconsistent behavior when downing them.
>
> * if I 'ifconfig down' eth0:1, I am left with eth0:0 and eth0:2
> * if I 'ifconfig down' eth0:0, eth0:1 and eth0:2 go away, too
Use ip.
> I assert that this should not happen. I have a simple patch to fix this
> behavior, but I want to know a few things.
>
> * Is this supposed to happen? Why?
> * Is it correct that both the real interface and the first alias are marked
> as primary (! IFA_F_SECONDARY), while all other aliases are secondary? It
> seems to me that ALL ALIASES should be secondary. Is this wrong? Why?
iif - using ip then
ip addr add 10.1.1.1/24 dev eth0
creates 10.1.1.1 as a primary address for the 10.1.1.0/24 address space as
defined. Now:
ip addr add 10.1.1.2/32 dev eth0
10.1.1.2 in this case IS NOT a secondary alias because it is _not_ within
the scope of 10.1.1.0/24 by definition (it is in the scope of 10.1.1.2/32
by definition).
Now try:
ip addr add 10.1.1.3/24 dev eth0
and 10.1.1.3 is a secondary alias by definition as it is within the scope
of 10.1.1.0/24
Better yet:
ip addr add 10.1.1.4/25 dev eth0
This defines a third scope on dev eth0 and now:
ip addr add 10.1.1.5/25 dev eth0
defines 10.1.1.5 as a seconday within 10.1.1.0/25
So to summarize we now have:
Three (3) Primary addresses:
10.1.1.1 for scope 10.1.1.0/24
10.1.1.2 for scope 10.1.1.2/32
10.1.1.4 for scope 10.1.1.0/25
Two (2) Secondary addresses:
10.1.1.3 for scope 10.1.1.0/24
10.1.1.5 for scope 10.1.1.0/25
Now let us see what the interactions are:
ip addr del 10.1.1.1/24 dev eth0
Will wipe out both 10.1.1.1 and 10.1.1.3
Make sense now? BTW - don't use ifconfig and coloned addresses (which are
deprecated) as you will merely confuse yourself. Remeber that ifconfig =
InterFace CONFIGure which has everything to do with Interfaces and very
little to do with IP addresses... ;-}
> Can anyone fill me in?
RPDB documentation is your freind.
> Thanks
> Tim
> --
> Tim Hockin
> Systems Software Engineer
> Sun Microsystems, Cobalt Server Appliances
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: [email protected]
WWW: http://www.paktronix.com
--------------------------------------------------
On Wed, 24 Oct 2001, Petr Titera wrote:
>
> > Actually it is quite sane. The tool is not.
> >
> > Switch to 'ip' instead of 'ifconfig', several large distros now include
> > it. Addresses can be added and removed completely indiscriminately on
> > interfaces.
> >
>
> I'd like to, but there's nothing like documentation with it.
http://www.linuxgrill.com/iproute2-toc.html
And many other places...
> Petr
>
> P.S.: Yes I know about examples in Linux 2.4 routing, but manpage would be
> nicer.
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: [email protected]
WWW: http://www.paktronix.com
--------------------------------------------------
On Wed, 24 Oct 2001, David Ford wrote:
> That is IMO bad behavior, it didn't use to do this because I have
> scripts that rely on this behavior.
The behaviour that Chris describes below has _always_ occurred. And if you
read Alexey's documentation he states that primary and secondary addresses
are the _intended_ behaviour. If you do not like the behaviour of
primary and secondary addressing then simply use /32 as then _every_
address is it's own primary.
The original thought refers to the old concept of address "class" where is
a "class" (think subnet) went away then there was no need (and indeed
incorrect) behaviour to still be able to have addresses on it. Thus when
the primary address is deleted you should clear all addresses within that
network and so the secondaries are removed. The entire concept of an
"aliased" address is an address that is within a scope. This behaviour of
addresses has nothing to do with coloned interfaces and everything to do
with the definition of scope as applied to the address space of an IP
network.
Again - if you do not like this behaviour do not use the primary/secondary
addressing scopes. Use /32.
> I'll take it up with the author, Alexey.
>
> David
>
> Christopher Friesen wrote:
>
> David Ford wrote:
>
> >Actually it is quite sane. The tool is not.
> >
> >Switch to 'ip' instead of 'ifconfig', several large distros now include
> >it. Addresses can be added and removed completely indiscriminately on
> >interfaces.
> >
> >The "ethN:X" is a legacy design that is now deprecated.
> >
>
> Minor issue...if I create (using 'ip') two addresses on the same subnet on the
> same device, one of them is primary and the other is secondary. If I then
> delete the primary address, the second one goes with it.
>
> I submit that this is bad behaviour.
>
> Chris
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: [email protected]
WWW: http://www.paktronix.com
--------------------------------------------------
"Matthew G. Marsh" wrote:
> The original thought refers to the old concept of address "class" where is
> a "class" (think subnet) went away then there was no need (and indeed
> incorrect) behaviour to still be able to have addresses on it. Thus when
> the primary address is deleted you should clear all addresses within that
I don't really think the original thought matters. What matters is that
the behavior is
a) non-obvious - you don't expect it
b) undetectable - you can't find out which alias is "primary"
c) inconsistent - some aliases act differently that other aliases
All of these violate the principle of least surprise. Whether it was
intentional or not, it behaves like a nasty hack, or worse, a bug. It is
easily fixed, and should be.
> Again - if you do not like this behaviour do not use the primary/secondary
> addressing scopes. Use /32.
Why should user-land be forced to work around what is obviously (to the
vast majority of people in this discussion) a mis-feature?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[email protected]
From: Tim Hockin <[email protected]>
Date: Thu, 25 Oct 2001 13:01:45 -0700
> Again - if you do not like this behaviour do not use the primary/secondary
> addressing scopes. Use /32.
Why should user-land be forced to work around what is obviously (to the
vast majority of people in this discussion) a mis-feature?
You have to understand how routing works to setup IP, we're deeply
sorry about that.
Franks a lot,
David S. Miller
[email protected]
In article <[email protected]>,
Tim Hockin <[email protected]> writes:
> "Matthew G. Marsh" wrote:
>> The original thought refers to the old concept of address "class" where is
>> a "class" (think subnet) went away then there was no need (and indeed
>> incorrect) behaviour to still be able to have addresses on it. Thus when
>> the primary address is deleted you should clear all addresses within that
> I don't really think the original thought matters. What matters is that
> the behavior is
> a) non-obvious - you don't expect it
It's bug to bug compatibility with 2.0. If you never rename ip aliases
manually and always create the "main" device first it is actually
not too unobvious.
> b) undetectable - you can't find out which alias is "primary"
The information is actually exported to user space via the ifaddrmsg
flags in rtnetlink, but not displayed currently by iproute2.
> c) inconsistent - some aliases act differently that other aliases
> All of these violate the principle of least surprise. Whether it was
> intentional or not, it behaves like a nasty hack, or worse, a bug. It is
> easily fixed, and should be.
It is an nasty hack, but needed to not void all the documentation and scripts
that rely on the old 2.0 alias behaviour.
If you want to avoid it only use ifconfig add/del or ip addr add/del..
to create aliases; never named ip aliases. They're deprecated, but
unfortunately still quite popular.
-Andi
On Thu, Oct 25, 2001 at 11:30:13AM -0500, Matthew G. Marsh wrote:
> On Tue, 23 Oct 2001, Tim Hockin wrote:
>
> > Can anyone fill me in?
>
> RPDB documentation is your freind.
The main problem with this documentation is that, wherever I have
seen it, it comes _only_ as few sizeable Postscript files. Like
this (after 'ls -s' so sizes are in kilobytes):
120 /usr/share/doc/iproute-2.2.4/api-ip6-flowlabels.ps
336 /usr/share/doc/iproute-2.2.4/ip-cref.ps
124 /usr/share/doc/iproute-2.2.4/ip-tunnels.ps
Mighty helpful if you happen to have only a text interface as is often
the case when you work on more complicated routing setups. It is also
excellent for grepping (NOT!) through a 60 pages long document if you
want to find something on a particular topic. Unfortunately it was not
apparently written in 'texinfo', or similar, as then one would have also
_at least_ .info files and an easy way to search through the whole thing
does not matter what kind of a display you have.
HTML format would be of some help but searches through that, especially
if multiple files are involved, are also not that nice. Right now your
best bet is probably to print that out and carry a stack of papers with
you wherever you may need it. Other than that you are currently reduced
to '/sbin/ip help' although you may follow up with something like
'/sbin/ip addr help' and you will get something to parse. :-)
Michal
Hello!
> It has done this since 2.2.x, when we first filed and fixed this bug. I've
> pinged Alexey, and haven't heard back yet. Maybe you'll have better
> response time.
People frequently do not understand that when creating two aliases
with completely coinciding prefixes, they must do an administrative decision:
what address they suppose to use as source address when communicating
to this network. In other words, what address is primary and what addresses
are just some unused dummies.
Well, and as soon as admin created configuration with some unused dummies,
kernel cannot promote slave to state of a citizen with full rights.
So, if you do not want an address was slave, just make it master of itself,
setting prefix length to 32.
What's about responce time... Well, I bring apologies, seeing you did not
append the patch to the note, this happened to fit to class of RTFMs
with answer which can be easily found in dejanews.
Alexey