Howdy, Stranger!

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


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Providers in Netherlands that don't use upstreams AS1299 neither AS174

2»

Comments

  • @nexius1981 said: coincidences were in these upstreams as174 and as 1299

    If your mobile carrier is different from your internet isp try mtr from it and see if you have packet loss. (You can try even vpn connection from it and see if gets any dc.)

  • @nexius1981 said:
    I didn't start doing this out of curiosity. I started to have a lot of disconnections within the VPN itself. When I did the basics of the basics, which is starting with ping, I saw a massive amount of lost packets. And I did this from several clients to the server.

    You're talking about disconnects within your VPN, so basically from your computer to the "endpoint" of your VPN. And the MTRs you're sending look like coming from those endpoints. Even if they would show dropped packets that wouldn't be a conclusive reason for you having issues.

    Start with MTRs from your computer to those endpoints. And keep in mind what @Clouvider told you: don't be fooled by in-between-hops that have packet loss, as one of my network guru's always told me: a router is for routing, not for answering your ICMP packets.

    Local ISP?!?!? @emgh I tested more than 10 VPN clients from various parts of the globe, from France, United Kingdom, Italy and Austria.

    Maybe you were lucky? Or maybe something totally different is the cause. I once had a strange problem with a friend that could do everything he wanted, except for visiting a few sites. Cause was a wrongly set MTU at his switch and for "some reason" only a couple of sites/usage cases would have an issue.

    Basically what those kind of situations tell you: if nobody else complains the cause may not be that big company but could be in your own setup.

  • 0ka0ka Member

    give ips of your bad vps or at least their subnet

    Thanked by 1NHNHNH000
  • @CConner said:

    @nexius1981 said:

    @CConner said:

    @nexius1981 said:
    I only have problems with those 2 VPS's that data pass trough this 2 upstreams...

    the others VPS's that I have across UK and DE, non of them have this problems, and none of them show me any kind of packet loss on any upstreams

    Based on the MTRs you've shared, there simply isn't any packet loss to speak of. 8.8.8.8 (one of the test targets you used) ratelimits ICMP packets, so seeing packet loss on that destination is expected.

    Are any of your services impacted by network issues, or did you just perform an MTR out of curiosity?

    I didn't start doing this out of curiosity. I started to have a lot of disconnections within the VPN itself. When I did the basics of the basics, which is starting with ping, I saw a massive amount of lost packets. And I did this from several clients to the server.
    Local ISP?!?!? @emgh I tested more than 10 VPN clients from various parts of the globe, from France, United Kingdom, Italy and Austria.

    Keep in mind that AS212477 / Royale Hosting has inline DDoS mitigation active in that point of presence. VPN traffic carried over UDP may be impacted by certain ratelimits / inspection rulesets, especially at higher packet rates. Support will most likely be able to tell you more and perhaps tweak some of the settings on your specific address(es).

    DDoS inspection & mitigation is only performed on inbound traffic, which is why it's not showing up on outbound traceroutes, but is potentially impacting inbound traffic.

    This is the answer, ticket support, tell them what you're doing, and they'll fix up your filtering.

  • estnocestnoc Member, Patron Provider

    @nexius1981 said:

    @lukast__ said:

    @nexius1981 said:

    @Clouvider said:
    Where do you have the packet loss to ?
    Can you show an MTR for a pair you have an issue with?

    The issue might be with their Customer not upgrading, not with Arelion (which is a good network!) or Cogent.

    https://imgur.com/a/IpgXX96

    I start to feel this problem, when, inside VPN I had major packet loss between client to server or vice versa.

    In some cases, even the handshake could not be made

    In the first MTR, there is no packet loss to the destination (packet loss in between is irrelevant), and while in the second MTR is packet loss, it isn't routed over Arelion/Twelve99 or Cogent.

    irrelevant or not, the problem is that I had packet loss inside vpn and this packet loss lead to a lot of disconections due to handshakes not done. Tried Openvpn and wireguard and all this 2 protocols had problems.

    dont use mtr but use simple ping instead. let it ping for lets say 300 times and see how much gets lost. these hops in the middle, can show you packet loss for multiple different reasons but that does not mean its correct. when packets are really been lost, you can see it the best way doing simple ping test.

  • @estnoc that’s exactly what OP @nexius1981 did

    He started to ping inside vpn, that seems where everything started

    He had another topic where he ask for help

  • @Clouvider said:

    The issue might be with their Customer not upgrading, not with Arelion (which is a good network!) or Cogent.

    @Clouvider can you explain better what you mean with this "The issue might be with their Customer not upgrading"

    thanks

  • I think he means that the provider doesn't have enough capacity on his port. At least thats what I understand.

    Thanked by 2yoursunny mrsky
  • So, what exactly happens to cause such problems?

Sign In or Register to comment.