On sön, 2009-06-07 at 13:38 -0400, Mike Edwards wrote:
> I've also found that the bug appears to manifest itself when the aliased
> interface uses an address on the host interface's network, but not when
> the alias is on a different network:
Yeah... looks like it has to do with if there's a "secondary" address. I
tested with two different subnets last time.
The second address automagically becomes secondary if there already
exists an address for the same subnet.
(By default "promote secondaries" is disabled, and thus the secondary
address will automagically dissapear when the primary is deleted.)
# ip addr add 10.20.30.42/24 dev skif ; ip addr add 10.20.30.41/24 dev skif
# ip addr show dev skif
28: skif: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen
1000
link/ether 00:11:d8:94:98:98 brd ff:ff:ff:ff:ff:ff
inet 10.20.30.42/24 scope global skif
inet 10.20.30.41/24 scope global secondary skif
# ip addr de 10.20.30.42/24 dev skif
# ip addr show dev skif
28: skif: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen
1000
link/ether 00:11:d8:94:98:98 brd ff:ff:ff:ff:ff:ff
#
You could probably work around your problem by enabling "promote
secondaries". This means the secondary address will be promoted
to primary if the primary is removed, rather then dissapearing along
with it.
# sysctl -w net.ipv4.conf.all.promote_secondaries=1
Another workaround would be to first flush all secondary addresses, then
flush the rest.
# ip addr flush dev skif secondary ; ip addr flush dev skif
I'll see if I can find out where this is handled in the code and work
out a proper fix for it.....
--
Regards,
Andreas Henriksson
