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

So the scenario is we have a web server at our colocation. In front of that web server are two SonicWalls and two L2 non-stacking managed switches. We're trying to find an efficient way to set up redundancy on all levels here (router, switch, machine) with the equipment we already own (so please, no "Go buy X" answers). The SonicWalls have an active/passive HA link, the switches have nothing, and the machine has dual NICs teamed with the same IP address (different MACs).

So each router has a link to each switch. The switches have a trunk link between each other and each switch has a connection to the dual NIC on the PC. Right now, the redundancy works such that I can kill the link between the router/switch or the switch/pc and I still have network access. To accomplish this, I set the ARP flush to 2 minutes on the Sonicwalls (lowest it would go) and 60 seconds on the switches). I can set up a constant PING on the machine and then remove one of the links. I have usually 20-30 seconds down time and then the ping starts back up.

My question is, what are the negative effects of having this low arp flush time? The server runs an online testing platform that people use, and in some cases they'll be downloading audio files. I was told by a peer that if they're downloading a file and the arp cache is flushed on the router, they'll lose their download. My understanding with TCP was that if it doesn't get an ACK in response, it will keep resending that same packet until it does? Given this information, can you see any issues that I might run into?

share|improve this question

On networks I have worked on in the past servers that had redundant links had the same MAC address for both links, that MAC address was used for the main traffic to & from the server and the native MAC addresses were used for keep-alives between the links. That method removes the need for constant ARP cache clearing.

Anyway, in answer to your question, yes TCP will retry if necessary, but it probably wouldn't be required because the device that had just had its ARP cache emptied would simply send an ARP request as it would do on its first attempt to contact the device with the uncached address. On the switches, as you may be aware, the address cache will be repopulated almost instantly because it will learn addresses as soon as traffic with an unknown MAC flows through it.

share|improve this answer
Here's the unfortunate part, straight from the manual of the NIC "Under SLB, all adapters in the team have separate MAC addresses. The load-balancing algorithm operates on Layer 3 addresses of the source and destination nodes, which enables SLB to load balance both incoming and outgoing traffic" – Safado Apr 22 '11 at 19:53
Ah yes, the servers I mentioned were configured for redundancy rather than load balancing. Is your Internet link actually faster than a single Ethernet link or is SLB your only option? The second paragraph in my answer still stands but I can't help thinking, like yourself, that there is a better solution. – blankabout Apr 22 '11 at 20:05
It looks like it also supports Dynamic Trunking(IEEE 802.3ad Link Aggregation), in which case it uses the same MAC address. I'm not too familiar with Link Aggregation.. is this combining two ports into one "link"? In which case would only be effective if my switches were stackable, right? Aside from that, what about if a link between a switch 1 and router 1 dies? Wouldn't the arp have to be cleared in order for the switch to forward the packet through the the trunk port connected to switch 2, and then switch 2 sends it on up to the router 1? – Safado Apr 22 '11 at 20:16
I'm not familiar with 802.3ad beyond knowing that it is very similar to Cisco's Etherchannel port aggregation protocol, for which there is a multi-channel version, you'll have to check your switch docs to see if they support an 802.3ad version of it, as long as they are linked there is a fighting chance that they do. The ARP issue is dealt with by the port aggregation protocol as obviously switches normally learn addresses from ports and object if the same MAC address comes in from more than one of them. – blankabout Apr 22 '11 at 20:41
Cisco boxes have a method of port control (whose name I've forgotten) which allows port tracking, if your switches have something similar then that could take of the failed link scenario. – blankabout Apr 22 '11 at 20:42

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.