Community discussions

 
ShardulNayak
just joined
Topic Author
Posts: 3
Joined: Fri Sep 28, 2018 9:34 pm

Large Pings Drop

Sat Oct 06, 2018 1:37 pm

I am having issues with an application and the vendor has been doing network tests and of course blames it on us. When you do a ping xxx.xxx.xxx.xxx -l 64000 the results are almost always the same. The first packet usually drops and the rest mostly go OK albeit long ping times with random drops. (Sometimes it won't even ping just times out.)

I have a CCR1036-12g-4S running 6.42.3 at my main facility and CCR1009-7G-1S+ running 6.42.3 at my remote sites with a 1gb metro mesh. The CCRs are all setup using LACP to cisco switches. The pings even drop when you are on site going thru the CCR1036-12g-4S to get to the servers on the different vlan. e.g. pc -- switch -- CCR -- switch -- server Servers on that same switch work just fine.

Any thoughts?
Thanks
 
ShardulNayak
just joined
Topic Author
Posts: 3
Joined: Fri Sep 28, 2018 9:34 pm

Re: Large Pings Drop

Sat Oct 13, 2018 5:21 pm

I am having issues with an application and the vendor has been doing network tests and of course blames it on us. When you do a ping xxx.xxx.xxx.xxx -l 64000 the results are almost always the same. The first packet usually drops and the rest mostly go OK albeit long ping times with random drops. (Sometimes it won't even ping just times out.)
kerala matrimony Justin tao seeger BMB
I have a CCR1036-12g-4S running 6.42.3 at my main facility and CCR1009-7G-1S+ running 6.42.3 at my remote sites with a 1gb metro mesh. The CCRs are all setup using LACP to cisco switches. The pings even drop when you are on site going thru the CCR1036-12g-4S to get to the servers on the different vlan. e.g. pc -- switch -- CCR -- switch -- server Servers on that same switch work just fine.

Any thoughts?
Thanks
Can Someone reply??
 
sindy
Forum Guru
Forum Guru
Posts: 2406
Joined: Mon Dec 04, 2017 9:19 pm

Re: Large Pings Drop

Sat Oct 13, 2018 9:20 pm

This is not a contact point of the official Mikrotik support, this is a forum of fellow users, so there is no guarantee that anyone will ever reply, especially for an issue like this which requires on-site runtime analysis, not just an answer to a "how do I set up xxx" question or analysis of a static configuration to find a mistake.

What you write sounds like some kind of issue with MTU and jumbo frames - a 64000 byte ping must be sliced into multiple Ethernet frames, so fragmented on IP level, even if jumbo frames are supported on all devices on the path. But there can be also other causes to it. So starting from the simplest things,
  • check whether /interface ethernet print stats on the CCR shows no errors,
  • use /tool profile on the CCR to see whether it's not glowing red under the load (so dropping packets and thus getting even more of them as the TCP sessions retransmit lost packets),
  • use /tool sniffer on the client-facing and server-facing physical interfaces of the CCR to sniff into a file while doing the ping test, and then download the file and use Wireshark to see where the issue comes from - lost fragments, late arp response somewhere (so the first ping doesn't get through within the wait-for-response timeout) etc.
Don't believe what packet capturing done on the client or server machines tells you - the network card drivers do a lot of work between the wire and the capturing API, so they may show you 64-kbyte ethernet frames which do not actually exist.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: No registered users and 63 guests