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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You are jumping to incorrect conclusions here by misinterpreting the test. I think I found your ticket that you only created with this allegations today on Sunday morning. If the packet loss you are complaining about was actually real you wouldn’t be able to run that MTR as the console would lag so much.
Your service is connected to a multihomed site connected to two core routing sites and load balanced with ECMP. Algorithm used in Juniper devices that are at the edge of EVPN/VXLAN pod serving your Hypervisor means that the specific flow tuple will stay on the same path, therefore, not affecting your service in negative way but enhancing it by providing multi router and multi site routing redundancy.
https://www.juniper.net/documentation/us/en/software/junos/sampling-forwarding-monitoring/topics/concept/policy-configuring-per-flow-load-balancing.html
Manchester is not connected in the same way, therefore it simply is not the same “problem” as you alleged.
The “problem” is in “” as it has thus far not been replicated or proven to exists.
The example MTR I put in the ticket was to my dedicated server at datapacket so you could be assured that the connection was solid.
The place I sshed from is a residential connection which is why I didn't include it. It had maybe 5-10% packet loss and spikes of up to 1000 ms which would match the situation in my video reasonably.
Right now there is no lag, and the MTR shows 0 packet loss now and no ping spikes. This issue only happens during the day during US hours. I hope you will check in on this tomorrow during US times.
We monitor packet loss and latency and found no spikes across any switch in NY Metro at any time. Our average utilisation sits at around 30% in this market.
Certainly, although please note we don’t provide support through the forum. The response here has only been provided in a response to a public and baseless claim that has been posted here.
Please work with the support team through the ticket, we won’t discuss the matter further via this channel.
This is a different issue, your issue is with connectivity at peak hours.
I also have similar issue with various providers in NJ, I suspect this because NY region is cluttered. I've moved some of my VPS to different region to solve this issue.
At US peak hours, all servers run in full capacity, rendering some of services lag. This also happens with the big names, for example: anthropic ai will respond with gibberish if you access them at ultimate peak hours.
The issue OP mentioning is problem with running script.
From what I see, OP is trying to POST multiple request without pause, from a single server. If the package going through Cloudflare, of course Cloudflare would suspect that OP is trying to DoS the target server and rate limiting the source server.
Let me explain my situation:
Currently, I was in the middle of migrating my production server to @Clouvider, so I've been monitoring LET closely to see if there's any problem. My heart stopped a little when OP mentioned DDoS, and I panickly ran a benchmark, analysis, checked the logs... and found nothing.
Then I remembered that no sane hacker will DDoS a newly created server.
DDoS is a f*king expensive operation, many soldiers will die in the process of attacking the fort. No monetary gained by DDoSing a random VPS servers.
You will get a DDoS if your product is famous enough, and there is a competitor willing to pay massive money to run the operation.
So no, Clouvider is not DDoSed
@nullnothere I really want to try testing from the recovery environment or a different image but I can't get an internet connection.
I tried:
ifconfig ens3 216.245.140.8.xxx netmask 255.255.255.0 up
route add default gw 216.245.140.255 ens3
But it didn't work. Do you know how to get an internet connection up or do you have a different image I could try?
A summary to everything above:
My server sends out a constant stream of less than 10 HTTP requests per minute. There is no rate limiting involved.
I ran the following mtr commands (with screenshots): https://imgur.com/a/yJiKNup
mtr --report-cycles=500 --order LDRSBAWGJ --tcp --port 80 54.84.170.143
mtr --report-cycles=500 --displaymode 2 --tcp --port 80 54.84.170.143
mtr --report-cycles=500 --order LDRSBAWGJ --tcp --port 18080 143.42.254.xxx
mtr --report-cycles=500 --displaymode 2 --tcp --port 18080 143.42.254.xxx
DNS benchmark/test screenshot: https://i.imgur.com/xzPAhVD.jpeg (DoH vs Do53)
root@Alba:~# dig @8.8.8.8 google.com
;; communications error to 8.8.8.8#53: timed out
If you have any commands or software you want me to run let me know.
@Jokull I never said I am getting DDoS'd. You misunderstood from the start
I said I suspect my traffic is being delayed by the DDoS mitigation infrastructure Clouvider is using because I know Corero has one of the worst reputations in this space. It could also be from other network equipment or a neighbour on the VPS host. Also possible to be from my environment even though I'm using the Ubuntu image provided by Clouvider.
Also I said many times the server sends less than 10 requests per minute and I tried with lots of hosts so it's not rate limiting. Trust me I had this VPS for like 6 months now I tried all the basic stuff and I am tiered of it
Have you checked your firewall?
The most common cause of this type of reports that we have is a Customer overloading a system firewall with rules, often through use of CSF with country blocking.
And still no ticket in our system despite I offered to look at it in my initial messages.
Hi, the firewall is disabled.
Yes, if I made a ticket I wanted to do a proper one and I didn't have time sorry. My old ticket from last year #895562 is closed and I am opening a new one now and I will give you the number.
Thanks for your message.
Whenever you have a moment, please raise a new ticket, include some relevant troubleshooting information in it and DM me the number, I will monitor it for you. Many thanks!
Your IP and GW are wrong. But I think you just botched the IP obfuscation.
I put xxx instead of the real ip and the gateway seemed weird at first but that's what I found in ifconfig. From examples on the internet I think it should end in 0 or 1 but from ifconfig it ends in 255.
You're looking in the wrong place, since gateway would come from route, not ifconfig. You're looking at the broadcast address. Change to 1 or 254, WHATEVER your provider provided in the panel, you don't need to guess.
(Also, you didn't block anything with xxx, you added it after the IP).
@TimboJones oh I just realised. I don't know what the .8. is that's not the IP must have copy pasted it wrong but thanks. Will try again now 👍
Your mtr actually shows the same issues as I had. When traffic goes through GTT in NY (unsure if other locations matter), there is massive latency increase and sometimes even packet loss. This matches with my other experience at other hosts also currently having issues with GTT right now.
The issue was obscured in my situation because clouvider doesn't load balance ICMP and sends it all through Telia, so it never shows up in a normal ping.
Even after I showed Dom this, he refuses to acknowledge that there's an issue.
@TimboJones No luck even with the right gateway confirmed from route -n | grep 'UG[ \t]' | awk '{print $2}'
It isn't cluttered at every host. Reliablesite GTT is fine for the most part except when they switch to Path momentarily for ddos protection. Telia also seems to be uncongested.
Since you're using System Rescue CD, please see:
https://www.system-rescue.org/manual/Network_configuration_and_programs/
That will give you specific instructions on enabling networking (manually) - please put in the correct IP+GW details (that should be visible from the VPS control panel where you access VNC).
Once network is enabled and you're able to check via ping, you can run whatever tests you want (check if the iptables firewall is preventing anything - the above page also lists instructions for iptables).
This will eliminate any OS specific issues (like with Ubuntu).
Hope this helps you move forward in at least debugging/getting more data points so that you can handle via ticket in detail.
@nullnothere Thank you. All I had to do is systemctl stop NetworkManager
I got the same behaviour in system rescue:
So that rules out any Ubuntu issues.
I don't quite know what the issue is but it looks like you're connecting to an AWS endpoint.
It could very well be something on the AWS side (including some form of rate limiting or something else including the VIP to internal IP connector). You should try out some other end points (which are under your control) and already lots of suggestions have been provided to you in terms of simultaneous MTR + ICMP + CURL just to check.
FYI, in my limited quick tests, I found variations from 0.5 to 1.8s in connecting and getting replies - though not as extreme as 2m whatever (which is likely some timeout due to a botched connection).
Please try to also play with different curl timeouts and see if that helps - now that you've ruled out any OS issues.
As always, I think the detailed debugging is better taken forward via tickets if you think it's something to do with Clouviders network.
Hope this helps!