Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a server communicating with a cluster of machines and the bottleneck is the network bandwidth. The good news is there are 2 interfaces, while the server can only make use of one. Without changing the code of the server, the utilization of the two interfaces are 100% vs. 0%.

What I want is a transparent round-robin scheduling on the two interfaces with minimal change, and the program should not be altered. This is because I have no physical access to the server, any configuration errors would be painful to recover from. The best solution I thought is like setting up a virtual interface that handles all traffic in a round-robin manner using the two underlying interfaces.

How can I do this without employing the "bonding" technique?


Why bonding is not an option? Because I have only remote ssh access of the server, any configuration errors on the existing interface will put the server down for a few days until the local administrator thousand-miles away takes over. Therefore a lightweight, i.e. "transparent", solution would be best.

share|improve this question

migrated from Jul 31 '12 at 20:57

This question came from our site for professional and enthusiast programmers.

I'm sorry, but bonding is required to utilize multiple ethernet uplinks from your server – Mike Pennington Jul 31 '12 at 21:00
any configuration errors on the existing interface will put the server down for a few days until the local administrator thousand-miles away takes over. --> So, wait a few days, and make the configuration change when the local admin is on site? Or make him do it? Not grasping why waiting a few days to get it done right isn't an option. – HopelessN00b Jul 31 '12 at 21:13

Bonding is the solution -- your lack of comfort with it does not change the fact that it's what you should do in this case. Any other solution will be a half-baked hack, while bonding is well understood, documented thoroughly, and extremely reliable.

If you only have SSH access to the server and you're concerned about breaking the network while configuring bonding you have two choices:

  • Have someone with local access set up bonding for you.
    (Ideally you would have done this yourself before you deployed the system, or be able to visit the machine. Having remote hands do this kind of stuff gets expensive...)


  • Use a watchdog.

The watchdog can be as simple as adding a cron job that puts your old configuration back in place and reboots the machine 5 minutes from now, so if you mess up the network configuration you just have to wait 5 minutes and it will be fixed for you.
This is a common technique, and I use it myself when modifying remote firewalls to save me a site visit or an embarrassing remote hands phone call when I invariably mess up the rules...

As to the actual configuration of bonding, it's been a while since I've used a Linux box in production so I'm sure my knowledge is out of date -- I'm sure there are a bunch of excellent tutorials available for the Googling though.

share|improve this answer

There's no option for you other than increasing bandwidth (assuming these are gigabit interfaces) or some level of bonding. You'll need one of the Linux bonding modes; probably "balance-rr". You could potentially set this up without downtime, if done carefully... but it's not fool-proof.

I would question the server access or configuration issues. Is there any out-of-band management access available to the system? ILO? DRAC? IPMI? I suppose you would be in the same situation if there were a kernel panic or system crash.

If it can wait until you have a resource available locally, I'd do that. In general, it's probably a good idea to keep the administrator in the loop for changes like this.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.