Messages in this thread |  | | Date | Sun, 24 Sep 2000 17:56:09 +0300 | From | Constantine Gavrilov <> | Subject | Bonding Driver Questions |
| |
Hi, I'd like to use channel bonding driver for high availability.
Currenly the bonding driver does not detect a dead slave link. When a slave link dies, it causes lots of network retransmits and the effective speed of the bonding device drops to almost zero. This has been verified in the lab.
How difficult would it be to "teach" the bonding driver to check for the link status of its slave interfaces? Does ethernet layer provides a uniform way to check for the link status or it is adapter dependent?
If such extension cannot be added to the kernel for whatever reason in the near future, can it be done from user space? It seems a user space approach would require two things:
1) a user space program to check for link status 2) a way to unbind a slave device without bringing the master device down. Currently the slave interface cannot be brought down without bringing down the master interface. I.e today, if I have bond0=eth0+eth1, and the link on eth1 goes down, I have to do
(a) ifconfig bond0 down (b) ifconfig eth0 down (c) ifconfig eth1 down (d) ifconfig bond0 $IP up (e) ifenslave bond0 eth0
At stage (a) the routing is broken, which is a problem. (I guess a dummy device with the same network as bond0 could be added before (a) and deleted after (d), but this approach is already ugly enough.) So, here are two questions:
1) How can I check for the link status from the user space? 2) Could enslaved interface be released without bringing the master interface down? If yes, how? Could we have ifunslave?
-- ---------------------------------------- Constantine Gavrilov Unix System Administrator and Programmer Xpert Integrated Systems 1 Shenkar St, Herzliya 46725, Israel Phone: (972-8)-952-2361 Fax: (972-9)-952-2366 ---------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |