Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Packet loss on layer4/tcp while no packet loss on layer3/icmp
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Packet loss on layer4/tcp while no packet loss on layer3/icmp

OhJohnOhJohn Member

I'm trying to understand a network problem I'm facing.

I don't have any packet loss on a normal mtr check (which is using icmp, so osi layer3), but having huge packet losses (>50%) on layer4/tcp.

(I'm trying to reach a backend from several servers, only one of them having this problem, so it's not the backend server but either the route or the calling server).

So I would say this is not a faulty physical connection problem (otherwise icmp/layer3 would have packet loss as well), it's also not a wrong routing or the like as layer3 would have problems as well.

So does this just show e.g. network congestion? Would this not show in icmp/layer3 but only in tcp/layer4?

Or what else should I look for?

Comments

  • ClouviderClouvider Member, Patron Provider

    I’m assuming you have checked the obvious - that is firewall, etc?
    Try running mtr with tcp - see if there’s anything obvious there

    https://unix.stackexchange.com/questions/462866/how-does-mtr-run-with-tcp-protocol-calculate-the-loss-rate

  • OhJohnOhJohn Member

    Yes I do run mtr with tcp and right port to test, that's where I see the problems that do not show up with mtr in icmp standard mode.

    I also use different socket timeouts, even with a socket timeout of 10 seconds I get a dst packet loss of ~ 50%.

    And it's not a firewall, the src server is allowed.

    It also just started getting problems this weekend.

  • Did you try playing with MTU sizes?

  • OhJohnOhJohn Member

    @kevertje
    no I haven't tried that so far, mtu size is at 1500, but the provider is now changing routes and by that mitigating the problems (crazy enough in this case routing away from Sparkle, which is normally one of the best transit providers I know - but this case is not about Europe but South America. But it might the providers lines with Sparkle being overloaded, who knows).

Sign In or Register to comment.