What to look for when troubleshooting WAN circuits

[jdlucado1]

Hello,

I handle mainly basic internal network work but I was asked to help troubleshoot a problematic WAN circuit.

I'm starting from scratch so I need to know what performance metrics to look for and a recommendation on tools.

Sorry, I can't get into details, but any general feedback is greatly appreciated.

Thanks!

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

First identify the meaning of "problematic".  That would help direct troubleshooting efforts.

WAN links, as they generally offer less, often much less, bandwidth than LAN links, congestion is often an issue.  Another common "issue" with WAN links, vs. LAN link, is their additional (distance) latency.  Often applications were developed to work on LANs and are not designed for optimal usage of WAN links.  I.e. a WAN circuit might only be "problematic" as it reveals applications not designed to work well across WANs.

[jdlucado1]

Thanks to both John and Joseph. So things to look for are congestion, latency and take into consideration if the application is meant to operate over a WAN. How would those symptoms manifest themselves? What specifically should I try and measure? 

[John Blakley]

High latency would be the first indiction for congestion along with jitter, lost packets, etc. It's really difficult to tell you what to look for since you're not able to fill us in on what you're experiencing.

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

What to measure depends much on what kind of WAN you're dealing with, and whether you're just doing passive or active measurements.

For example, for passive, you might "watch" interface stats on drops, queue depth and errors.

If doing active, as John described, you might monitor latency, jitter, loss.  For latency, you should have some base, when path is lowly used.  Jitter and loss have acceptable ranges depending on the traffic type.

[John Blakley]

Just to add to Joseph's response, WAN types of circuits also differ in the way that they're troubleshot. T1/E1 links are different than ethernet circuits. Ethernet circuits generally connect to a carrier's switch at the demarc. If the circuit goes down, your interface will still show up/up since your connection to the switch will probably be good.

The flipside of that is the T1 (serial) interface in that if the circuit is having a problem, you will see the interface on your side in a down/down state. Those are a lot easier to troubleshoot most of the time because you'll also have things like CRCs, slips, etc. on the controller.

HTH,

John