All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Ben Greear <greearb@candelatech.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>,
	NetDev <netdev@vger.kernel.org>
Subject: Re: Routing tables associated with VLANs dissappear when parent ethX down/up
Date: Wed, 21 Nov 2007 23:24:35 +0100	[thread overview]
Message-ID: <4744B023.60504@trash.net> (raw)
In-Reply-To: <4744A8A3.8060406@candelatech.com>

Ben Greear wrote:
> Patrick McHardy wrote:
>>
>> 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.

An alternative to this would be something like Julian Anastasov static 
routes
patch. Not sure if it has ever been considered for merging, but its a 
cleaner
way than doing per-device hacks.

http://www.ssi.bg/~ja/

>
> 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...

Yeah, I too never liked this behaviour.

>
> 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...

Thats pretty much what the operstate is doing, it should go to
IF_OPER_LOWERLAYERDOWN when the lower device is down. But as I
said above, people could actually rely on routes disappearing.



      reply	other threads:[~2007-11-21 22:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-21  1:20 Routing tables associated with VLANs dissappear when parent ethX down/up Ben Greear
2007-11-21 19:51 ` Ben Greear
2007-11-21 20:00   ` Stephen Hemminger
2007-11-21 20:25     ` Patrick McHardy
2007-11-21 20:54       ` Ben Greear
2007-11-21 21:12         ` Patrick McHardy
2007-11-21 21:52           ` Ben Greear
2007-11-21 22:24             ` Patrick McHardy [this message]

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=4744B023.60504@trash.net \
    --to=kaber@trash.net \
    --cc=greearb@candelatech.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.org \
    /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.