lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 21 Nov 2007 13:52:35 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	Patrick McHardy <kaber@...sh.net>
CC:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	NetDev <netdev@...r.kernel.org>
Subject: Re: Routing tables associated with VLANs dissappear when parent ethX
 down/up

Patrick McHardy wrote:
> Ben Greear wrote:
>> Patrick McHardy wrote:
>>> Stephen Hemminger wrote:
>>>>
>>>> But then if you are doing bonding or bridging of vlan's and you 
>>>> bring down the root network device, the upper layer is not
>>>> notified (for failover).
>>>>   
>>>
>>> operstate should be enough for this I guess. Ben, what does iproute show
>>> for the vlan device when the lower device is down?
>>
>> It looks like it knows, assuming M-DOWN is useful information.
>> Eth2 is un-plugged, by the way.
>>
>> [root@...forge-33-46 ~]# ifconfig eth2 up
>> [root@...forge-33-46 ~]# ip link show eth2.2
>> 125: eth2.2@...2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc 
>> noqueue
>>     link/ether 00:03:2d:08:33:47 brd ff:ff:ff:ff:ff:ff
>> [root@...forge-33-46 ~]# ifconfig eth2 down
>> [root@...forge-33-46 ~]# ip link show eth2.2
>> 125: eth2.2@...2: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 
>> qdisc noqueue
>>     link/ether 00:03:2d:08:33:47 brd ff:ff:ff:ff:ff:ff
>> [root@...forge-33-46 ~]# 
> 
> That comes from iproute itself, but the missing LOWER-UP flag
> indicates it and that should be enough for bridging and bonding.
> I'm unsure about this though since its still a big difference in
> userspace visible behaviour, people might just as well manually
> configure failover once routing disappears or the device goes down,
> or just have routing fall through to different routes. All this
> wouldn't work anymore.
> 
> Maybe we can make this optional somehow without too much uglyness?

I'm fine with that..we can just add a new vlan-device flag similar to the
reorder-header flag.

With the current code, on 'UP' of the underlying
code, all of the VLANs will also go UP, even if the user had previously
put them DOWN.  That seems like it could be quite dangerous/unexpected
to me..but I guess it's required if we are going to automatically DOWN them...

One other thought:  Maybe we could tell a small lie and say that we have
NO-CARRIER on the VLAN when the underlying device is down OR has no carrier?

That way we keep normal link up/down semantics w/out having to change the
admin state of the VLANs...

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ