Messages in this thread | | | Subject | Re: RFC: ethernet links should remember routes the same as addresses | From | Andi Kleen <> | Date | 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/
| |