netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Friesen <cfriesen@nortelnetworks.com>
To: netdev@oss.sgi.com
Subject: suggestion for routing code improvement
Date: Wed, 10 Apr 2002 13:51:12 -0400	[thread overview]
Message-ID: <3CB47B90.B4CF1FAD@nortelnetworks.com> (raw)


Well, we're into a new experimental branch, so I figured the time had come to
bring back an idea that didn't make it in a year ago.

Currently, if you add custom routes and then down the device that the routes are
associated with, the routes are then removed.  This is entirely understandable.

However, when you then up the interface, the routes do not come back up
automatically.  This is the part that I don't agree with.

Addresses, automatic routes, and custom rules either stay in effect or are
brought back up by the system when an interface is downed and then upped.  The
only exception to this is custom routes.

I propose that these custom routes be stored in some fashion, and then be
brought back up when the device is brought back up.  This would make certain
types of link management much simpler.  Custom routes, once added, would stay in
effect until explicitly removed.  As it stands now, any time you down/up a link
you have to then go back and add all the custom routes again.  This can be a
pain in the butt.

So, what do you guys think?  Is this a reasonable thing to do?  I think that it
makes the system nicely symmetrical, as opposed to the asymmetrical handling of
current kernels.

I don't have a really good grasp of what data structures are avialable to us in
the routing code, so could someone with a better understanding of the code
comment as to how hard this would be to implement?

Thanks,


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: cfriesen@nortelnetworks.com

             reply	other threads:[~2002-04-10 17:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-10 17:51 Chris Friesen [this message]
2002-04-10 18:53 ` suggestion for routing code improvement Andi Kleen
2002-04-10 20:15 ` Robert Olsson
2002-04-10 20:56   ` Chris Friesen
2002-04-10 23:02     ` Robert Olsson
2002-04-11  2:24       ` Julian Anastasov
2002-04-11 11:29         ` Robert Olsson
2002-04-11 12:08           ` Julian Anastasov
2002-04-11 12:18             ` jamal
2002-04-11 12:58               ` Julian Anastasov
2002-04-11 13:05                 ` jamal
2002-04-11 13:01             ` Robert Olsson
2002-04-11 13:06               ` Julian Anastasov
2002-04-11 14:53                 ` Robert Olsson
2002-04-11 15:24                   ` Julian Anastasov
2002-04-11 16:05                     ` Robert Olsson
2002-04-10 21:37 ` Julian Anastasov
  -- strict thread matches above, loose matches on Subject: below --
2002-04-10 20:41 Nivedita Singhvi

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=3CB47B90.B4CF1FAD@nortelnetworks.com \
    --to=cfriesen@nortelnetworks.com \
    --cc=netdev@oss.sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).