This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Branch office latency over MPLS

0

Note: fairly green at Wireshark

Scenario: We have branch offices connected to our main office via MPLS VPN. Branch offices use thin clients and VoIP phones. Users RDP to virtual desktop on ESX Server.

On random days and random times these branch offices have one minute outages where their RDP session will say "Reconnecting" and the voice call is lost. After a minute the RDP sessions and VoIP are fine.

Is it possible to capture this latency even though I don't know when it will happen again? The time range is from 815am-2pm.

I've verified the WAN circuit hasn't dropped and calls to Cisco indicate a LAN issue between the edge router > firewall > switch > ESX Server.

I'd like to capture packets remotely and locally but don't know where to start.

asked 05 Dec '12, 09:44

jtlg's gravatar image

jtlg
6113
accept rate: 0%


One Answer:

2

As you don't know when it happens, you can only capture with a ring buffer of files and stop the capture as soon as the problem was detected.

  • Configure port mirroring on the switch, where your ESX server is connected
  • Attach a capture PC to the mirrored port
  • run dumpcap

dumpcap -ni 1 -w mpls_error.cap -s 200 -b filesize:150000 -b files:50 -f "port 3389 and (net 10.1.0.0/24 or net 10.2.0.0/24)"

This will write 50 files, named mpls_error_xxxxx.cap (xxxxxx will be replaced by a time stamp). Each file will have a size of 150 MByte. If dumpcap reaches file nr. 50, it will overwrite file nr. 1, etc.

So, you will have a circular ring buffer of 50 files, each with 150 Mbyte size. As the packets are truncated at 200 bytes (-s 200), you will be able to capture a lot of sessions. This will consume max. 7.5 Gbyte on your disk, no matter how long it runs.

Comments:

  • 10.1.0.0/24 and 10.2.0.0/24 are the networks of your remote offices.
  • figure out the interface for option -i with: dumpcap -D -M
  • you might have to use different values for filesize and files, depending on the amount of data in your network

Now, as soon as the problem was detected, you or the network people need to stop dumpcap rather quickly, to prevent it from overwriting the part where the problem occurred. How quick you have to do it, depends on how much data is captured. Just observe how long it takes to write 10 of those 150 MByte files and then possibly adjust the options filesize and files to have enough time to stop dumpcap after the problem has been reported.

If you let the people record the exact time of the problem (and your capture PC is configured with the "real time"), you will easily find the capture file and within that file, the time frame where the problem occurred.

That was easy. Now you will have to walk through the captured data and try to figure out what went wrong. Maybe the capture filter (optione: -f) needs to be extended, if you can't identify the problem in the first tests.

I'd like to capture packets remotely and locally but don't know where to start.

yes, good idea. Please repeat the above steps for the remote location. Mirror the port where your MPLS router is connected to the network of the remote location.

Regards
Kurt

answered 05 Dec '12, 12:39

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 05 Dec '12, 12:56

Thanks. I'll work my way through your steps

(07 Dec '12, 06:47) jtlg

you're welcome.

If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions.

(07 Dec '12, 07:44) Kurt Knochner ♦

Kurt,

I have this up and running on the LAN side. Thanks for your help!

(12 Dec '12, 07:44) jtlg