![]() ![]() Mikrotik engineers should NOT place any underlying queues on bottom of CHR. ![]() There have to be some underlying, hidden queue in P1 and most likely P10 licence, which limiting interface speed to licence level speed, and is most likely improperly configured and dropping packets, even when our interface rates are much smaller than 1GBit ceiling.Ģ. Voila, everything backs to normal, no VPN drops, no LOSS!ġ000 packets transmitted, 1000 received, 0% packet loss, time 13303msġ000 packets transmitted, 1000 received, 0% packet loss, time 13238msġ000 packets transmitted, 1000 received, 0% packet loss, time 12970msġ. Then, I have created new CHR instance, installed same 6.37.1 version, obtained new P unlimited trial for 60 days, imported all settings from P1 licenced server. We 've carefully examined ESXI stats and Mikrotik interfaces/vlans stats: no drops, no errors. Our conslusion was - there is either some underlying queue on CHR instance, which dropping packets, or HW problem. Loss rate rised again after crossing 80mbit+. We have tested loss rate at night (when total router throughput was about 5-10mbit), and loss was much smaller (maybe like 0.1%). ![]() Code: Select all - 185.28.167.66 ping statistics -ġ000 packets transmitted, 987 received, 1% packet loss, time 11987msĤ89 packets transmitted, 480 received, 1% packet loss, time 5968msġ000 packets transmitted, 996 received, 0% packet loss, time 11987msġ000 packets transmitted, 994 received, 0% packet loss, time 12948msġ000 packets transmitted, 993 received, 0% packet loss, time 11996ms
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |