How Fixing A LAN Sped Up My WAN For FREE
I once had the unfortunate experience of getting aboard a flight bound for a city some distance away. After taking off, and getting halfway there, a problem occurred, and we had to return to where we started. All of the flight time and resources wasted, and we had to start all over again with a new flight. At least they hadn’t run out of coffee and I hadn’t ordered the fish for dinner.
I wouldn’t have minded a cancelled trip if I was only driving a mile, but when using expensive flights, cancellations become a far greater inconvenience. While cancelled flights are not a very enjoyable way to travel, it does remind me of one of our stories from the field…
No Visibility & No Instruments: Troubleshooting by Assumption
Sam got the call in the middle of the afternoon: The VP who handled the European Branch Offices was unhappy with the speed of the WAN connections to headquarters in the U.S.
Peter, Pointy-Haired-Boss: “Surely it must be the speed of the WAN links – we just need to buy faster WAN connections. Perhaps this should come from YOUR Network budget as I can only chip in a little bit.”
Sam Savvy, Network Manager: “I don’t think that’s the problem, and don’t call me Shirley.”
Sam knew that troubleshooting by making unfounded assumptions was like guessing where the runway was in the fog, and hoping that you’ve guessed well – NOT a good strategy.
Total Visibility & Instrumentation
Sam decided to try out PathSolutions and gather some performance information from his network. He suspected that the WAN service provider was not performing at full speed and was surprised when, within the first hour of installing PathSolutions software, he found a LAN switch port dropping packets. The LAN switch with the issue was attached to the WAN router, so many of the dropped packets came from the WAN.
Most applications react to lost packets by simply sending a new copy of the same packet. When TCP applications detect a dropped packet, they not only retransmit a new copy of the lost packet, but will also (under the assumption that they’re sending too fast and causing congestion) slow down their data streams by reducing their “Window Size.” This “Window Size” controls how many TCP packets are sent (and allowed to be in transit at any one time) before an acknowledgement needs to come back from the other side of a link. Some of you may have experienced this by watching file transfers start quickly, but after packets begin to drop, the file transfer slows significantly.
When a data packet flies halfway around the world, it is better if it doesn’t get discarded, wait to be detected as missing, and then start the journey all over again.
FREE WAN Upgrade
What Sam determined was that packets were sent from his US router, all of the way across the ocean using an expensive link, and shortly after arriving in Europe, were dropped by a bad connection. This was a bit like the cancelled flight I mentioned at the beginning of this article. A significant amount of traffic over the WAN was re-transmitted packets. Most TCP protocols were crawling along at very low speeds, hoping to be slow enough so as to not drop any packets. Over a local Gigabit LAN connection, these retransmissions may have never been noticed, but Sam’s relatively small WAN connection magnified the problem significantly.
A short while after Sam corrected the problem, nearly all of the retransmitted packets were gone from the WAN, and TCP streams were flying through in record time.
Peter the Pointy-Haired-Boss congratulated Sam on getting the WAN service provider line “upgraded” so quickly. He wondered how Sam had negotiated such an immediate and large speed increase from their WAN provider.
“You’ve just got to know how to handle them,” said Sam. “Oh, and about that little bit of extra budget your department was going to give us…”
(cue “Airport/Airplane” Film Music music)
“Thanks for flying with us! Watch your step on the Slide! Buh-Bye!”
Stay tuned for our next cliffhanger post—same place, same channel!