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 |
One Answer:
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.
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:
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.
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 answered 05 Dec '12, 12:39 Kurt Knochner ♦ edited 05 Dec '12, 12:56 |
Thanks. I'll work my way through your steps
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.
Kurt,
I have this up and running on the LAN side. Thanks for your help!