Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 am implementing failed over for a network node, so my idea is to make the master node listens on a broadcast ip address and port. If the master node fails, another failover node will start listening on this broadcast address (and port) and take over.


My concern is that I will be using a broadcast IP address just for a single node: the master. The failover node only binds if the master fails, in other words, almost never.

In terms of network/traffic overhead, is it bad to talk to a single node through a broadcast address or the network somehow is smart enough to know that nobody else is listening to this broadcast address and kind of treat it as a unicast in terms of overhead?

My concern is that I will be flooding my network with packets from this broadcast address even thought I am just really talking to a single node (the master). But I can't use unicast because the failover node has to be able to pick up the master stream quickly and transparently in case it fails.

share|improve this question
In terms of network/traffic overhead, you need smart enough switch (Cisco or comparable one) to do any broadcast optimizations. Most switches will just forward your broadcast to everyone. – Serhiy Sep 11 '12 at 22:07
if you really have to reinvent the wheel, multicasts might be what your looking for. Most switches treat multicasts well, and should only copy them to stations that have interesting in that traffic. However most switch are dum and will treat multicasts as broadcasts. – The Unix Janitor Sep 14 '12 at 16:56

It sounds like you're trying to reinvent NIC teaming/clustering in your own way. Most active/passive clusters will share a virtual IP and MAC address and when one unit fails, the secondary takes over the shared mac address. Using a broadcast IP to communicate to a cluster is unorthodox and will almost certainly create unnecessary traffic throughout the LAN.

share|improve this answer

It is in general impossible for the network to predict in advance, or be instantly aware of, the failure of a node.

Hence, you must either:

  • accept that it will always take a small time to detect the failure and move to the failover node
  • preemptively send traffic to the backup node, losing network efficiency

Reliable messaging at the network level is difficult and costly to implement. This is why we use dumb packet-switched networks and implement reliability at the transport level. This is the scenario where you use a floating IP (and possibly MAC) address, and wait for the (gateway ARP cache / switches forwarding tables) to update.

But if it is that critical that you never miss a single packet, You will have to pay some efficiency. If you use multicast (not broadcast) addresses, and your redundant paths go trough switches that are capable of IGMP snooping, then they should be smart enough to at least not flood your whole LAN. You still need a way for your backup node to reliably detect a failure of the master.

If you use streams, instead of using your own ad-hoc reliable protocol on top of multicasted udp, you may want to look into SCTP as it handles multihoming and may advantageously replace udp or tcp.

share|improve this answer

Yes, broadcasting has overhead. The more nodes you have connected to your switch, the more overhead you have. So you should only send broadcast when you really want to reach all nodes and/or when you are trying to discover a node that has moved someplace else. Broadcast once, wait for a reply from the node from wherever it is, discover its new address and from now on unicast. Beautiful, isn't it? :)

share|improve this answer

Whether you are flooding your network depends entirely on the frequency and size of the broadcasts, the size of the subnet you are broadcasting to, your network topology, and the capabilities of your equipment.

Without knowing that no one can answer your question for sure.

However, DHCP is broadcast traffic, and in a large network can be quite chatty. Many networks won't take any special action to manage this DHCP traffic - the impact is not a concern. Estimate whether your broadcast will amount to significantly more than existing DHCP broadcast traffic on your network - if so, then maybe you need to worry and implement a different solution to whatever problem you are having. If not, then most likely you can move on to the next challenge.

I'm intrigued as to what specifically you are trying to setup failover for. As other respondents have suggested, there are a bunch of options out there for redundancy you might use where you won't have to worry about this, and can tap into other people's experience.

share|improve this answer

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.