Re: RFC: ethernet links should remember routes the same as addresses

Andi Kleen (ak@suse.de)
29 Nov 2001 20:55:17 +0100


"Christopher Friesen" <cfriesen@nortelnetworks.com> writes:

> Suppose I have a fancy routing setup, dynamically configured by different
> binaries, scripts, etc, complete with multiple addresses per link, additional
> routing rules and tables specified using iproute2, etc.
>
> An ethernet driver hangs. Could be a software bug, an intermittent hardware
> issue, whatever. It can be fixed up by setting the link down and up.
>
> Currently, if I run "ip link set dev ethX down", all routes associated with that
> IP address in the additional routing tables are lost. This is somewhat
> understandable, as the addresses are not actually available anymore. However,
> the addresses are still visible associated with the link. Then I run "ip link
> set dev ethX up". The route in the main routing table comes back, but none of
> the other routes do. Somehow, all of those additional routes must be re-added.

ip route list dev device > BACKUP

...

while read i ; do ip route add $i ; done < BACKUP

>
> Wouldn't it be nice if we could keep track of these additional routes? Then you
> could simply 'down' and 'up' the link and everything would be back the way it
> was before.
>
> Does this sound like a good idea? How hard would this be to implement (not
> knowing what the current code looks like, I don't know how this would be done)?

In kernel very easy. The IP addresses and the driver init/cleanup are
completely separated and can be easily done independent. You may need
some way to prevent packets getting submitted to the driver (e.g. a
netif_carrier_off but make sure to not confuse it with a real
netif_carrier_off done by the driver, so you'll likely need a new flag)

I'm not sure it it worth it though given how easily it is to simulate
in user space. If you really wanted it I guess best would be to add new
ioctls for it. Coding should be easy.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/