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
This was a review, I used them purely for testing purposes. I don’t need X4B that much really, as my backends are always well protected with 10Gbit uplinks and >1.5Tbit/s. I wanted X4B to increase the security and protect the website as well. That did not work well at the end
I kind of knew that from the beginning as it is impossible to expect everything to work for $20-50/month.
Yes, why not?
I can rewrite the whole network layer, and you can rewrite an app.
Believe in yourself.
@OpenSource Please make up your mind, Saying one thing in a ticket and the opposite in public is deceptive. Expecially when actually helping you involves more hours of work that will never be recouped.
I wish I could pipe the botnet attack you received earlier through to you. I would love to see you handle the 9k SSL handshakes per second on a single machine. Feel free to set your service to Layer 4 mode and disable the L4 rule created for attack trimming for a taste if the attack returns.
For most customers we are used for great result. Most customers however come with the understanding of how unmanaged services work and a reasonable technical understanding to make full use of whats provided (interface and support). There are plenty of companies doing managed versions of what we provide for $1-3k/month of course those arent comparable, those might be more suitable for you however as we are very clearly unmanaged.
Now problematic routes do exist on the internet, some of which can be solved. Some of which can't.
In this specific case I'd love to be able to shunt your route over to public peering, unfortunately that's just not an option in Amsterdam. As covered in the ticket we are currently not peered with AMS-IX due to our upstream pulling out of that peering relationship (due to underutilization).
I also checked and while your upstream is on LINX they do not import routes (or do so selectively) so LINX offers no benifit to you either (it is unclear even if available if AMS-IX would).
It's not impossible that we could get AMS-IX from another source or direct if it's particularly important to you.
Supplimentry information for the curious about the BGP process and why his ISP chooses London over Amsterdam. From his ISPs looking glass there are four equaly weighted routes available between them and us.
In (slightly) layman terms the three main routes available:
His ISP connects to Level3 in Romania but preferences that interface over other more local ones. As all the routes available are equal in length (hops) they (are supposed to) choose based on local preference (which they can detirmine by dollar cost, or something more intelligent). Based on this his ISP hands over to Level3 in all the traceroutes I have seen.
Level3/Lumen interconnects with NTT in Paris via a peering relationship. As this is a peering relationship the routes are not controllable by (me) the customer. NTT offers more than the normal level of BGP control, however it is for the most part limited to controlling customer routes. Peer routes are largely left to NTTs discression.
NTT prefers transit via UK over Amsterdam for France. Therefore his traffic lands in London. Normally this is not an issue as few people care about the 5ms difference in route. It certainly wouldnt explain any of the other issues he has been raising (which point towards other issues instead, but that's a different matter entirely).
Now what options are available to an ISP to improve a route in a case like this?
1. Public peering (e.g AMS-IX): Will work if the source AS and destination AS filter / egress route communities to enable communication. My preferred option, however not currently available for us in Amsterdam.
2. Private peering: More costly and not immediate but guarunteed to provide a specific route.
3. Better matching Transit: e.g if we had Lumen or Telia (co-incidentally we should be getting some new transit soon) or they had NTT
4. Removal of the GTT prepend: We prepend x1 to keep the majority of traffic flowing via NTT making NTT the preferred peer where available (GTT has limited interconnects). In our case the prepend is currently required for three bad route cases AFAIK.
5. Contact the ISP for a route adjustment: I'm yet to see this ever work, but it's not impossible. The ISP would need to either insert a static route, or adjust a filter on the route forcing a different egress (forcing GTT would likely give the correct result)
I hope you enjoyed the "fun" that is BGP.
P.S I wouldnt mind switching from a plain prepend (x1) to GTT's
3257:2291(x1 for peers, not customers) in the future. For the standard range it may result in slightly better results by making more use of GTT (the premium line not so much). I might test that a little today on a testing range. It would likely help in cases like this. Of course a change of that magnitude (not eyeball AS specific) requires quite a bit of testing to prevent the creation of new edge cases.I know enough about BGP and can confirm this explanation makes sense.
If OP cannot understand fully, they should take a graduate-level computer networking class.
Picture Brad Pitt, but instead of him saying, "what's in the box?" 50 times, he's saying "what is the issue in one sentence?"
Huge red flag, you probably don't realize this. You kind of implied you abuse Support. But it's like you know nowhere near what a person would gain in knowledge in 30 odd trials. And it reflects poorly on you.
Fucking called it. Regular person finds a working provider after 2-3 tops and then plays his fucking game in happiness. Not this guy. 30. 30! Once more for effect, 30!
Seems like to everything I said you can find something to contradict to. I will make sure to respond to every stupid comment that this community throws at me. There are many… Mathew is still relatively normal over you other guys - one is attacking me for not redesigning whole Minecraft, another one is doing so because I wanted to experiment with the different providers, and some people are just here as they don’t really have anything better to do with their lifes but to contradict to all of my comments with no real reason at all… Some of you are even saying that it’s in some ways totally normal to have packet loss and bad routine, and internet is built that way… I don’t know if many of you hear yourself. I’m just wanting all of my game servers to have somewhat stable latency (doesn’t mean it must be 30ms, it can be up to 60, but at least it should be stable and not dropping and rising with no reason with huge packet loss).
For your specific information, in 95% of the providers I tried, and was with them always for a month or two, I never had to open more than one or two tickets. In some cases never had to open any. While in some, I had to open more than ten of them due to their services not working as expected (Khm… x4b). I learned a lot on how a real provider and real support should look like. Jesus Christ, at X4B they start without even saying Dear Customer, or even Hello there! They just start typing whatever comes to their mind… I’ll talk more over it below.
Maybe, but it would not solve anything. Minecraft is Minecraft, Spigot is Spigot. At the top of all that, MC is not OpenSource. Even if by whatever magic I end up further optimizing it for huge latency, all of my customers would not use my custom Minecraft or my custom Spigot but just use the normal one from paper or spigotmc.org, or even vanilla mc from the official Minecraft website. Maybe I should make a new game in order to make it all work with X4B…
Not just my ISP, but every single one in Serbia and Croatia. Some players get kicked instantly after they connect. Even from your test server.
L7 http/https attacks can easily be mitigated by Path.net, the protection I use on all my websites. Even tho it is theoretically one machine, connecting to port 80 through them is done through reverse proxy, so my machine would not have a need to deal with it. As for L3/4 (Game Servers), I use Serverius (1.5Tbit/s) and RoyaleHosting for their additional in-house firewall of up to 500Gbit/s and machines with 10Gbit uplink. I hardly believe any attack can pose any problem to any of those. No offense, but excellent mitigation at X4B poses more problems than it actually helps - at least for me.
check out https://www.cloudflare.com/products/cloudflare-spectrum/minecraft/
does not look like they are much more expensive but will have an unbeatable network.
cloudflare is usually always keen on improving routings as its part of their business model. Make sure you loop in your ISP though as its a two-way game....
There is no reason for that due to simply bad route. And without clear technical information regarding your issue I really don't see what I can do. With the useful information you have provided (nothing) all i can do is speculate. I have no data since it's not something a VPN to Amsterdam (or Serbia below) produces which is the closest I can get to testing your setup.
Anyway your claim can be easily verified by me since it's supposedly every single ISP (clearly an exaggeration).
Surfshark have a PoP with "Secure Data Systems SRL" in Serbia. Using the server that I setup for testing on your IP I am able to connect. I have other things I need to get done today and do not have a spare Minecraft capable PC available at this time so I am unable to stay logged into this VPN for any long term test. However I have immediately verified your claim as flawed.
The route that traffic follows is also attached: https://paste.ee/p/8cxHa#DEVNgvJhGaKwEh4Lnr1TTneS1kTJb7OC / https://paste.ee/p/iOLNP#D0RnUl0TvPkBRF0eK9eoOFu94CeRaw3i
Regarding the bad route portion of your ticket our actioning of
3257:2291would have resolved it. As that was silently actioned on Saturday night (and in doing so your route switched to Amsterdam according to your ISPs looking glass). From this reply of yours I'm going to say it didnt change a thing for you (as I've been saying...).Anyway if you wanted this to actually get fixed you would have came to us many replies ago with the requested information. This has not gone unresolved due to any unwillingness from us to resolve any issues found (quite the opposite) it's gone unresolved because you have provided near nothing to work from. I have expended FAR more effort than your accounts worth simply for the chance this is an issue that if resolved could benifit other appreciative customers (certainly not for yours, your disrespect and lack of apreciation is a given).
To this point as we are yet to receive even a single item of supporting information I'm starting to suspect something very fishy here. Sure @OpenSource could be just a problematic client who doesnt understand that providing the requested information is a required part of resolving issues a customer-business relationship, but he could also be making the entire issue up.
Normally I wouldnt need to suspect this but it would make sense that no real information could be provided....
Honestly if he has the same issues with any host they are going to ask for the same information we are.... assuming he behaves the same the result will likely be poor.
P.S no issues with Surfshark Croatia either.
A very smart boy rewrote Minecraft already:
Distributing the Game State of Online Games: Towards an NDN Version of Minecraft
A Quadtree-based synchronization protocol for inter-server game state synchronization
source code
@yoursunny a bit off topic but wow.
Point is, you really can't argue with ignorance, but you can educate against it.
Noone told you that. It's not normal to have packet loss but it is normal to have bad routing. Yes, internet was built that way. BGP does not consider latency but path length. Your ISP may have its own path preferences sending traffic to X4B, and the same applies to X4B. My ISP has its own pop in london, and it's normal to take 50ms to hop from their london pop to london IX.
This happens when ISPs generally don't care about their customers and focus on saving costs or selling transit.
The few ms of latency you are fighting for by changing routing would not fix spikes and packet loss. Either way, you should probably give up on X4B by now. You've used 30+ different providers and never learnt to move on?
He has shown no MTRs with packet loss or spikes yet by the way. If he had provided even one it we wouldnt be here now I dare say.
@smallbibi You are getting 50ms from your London ISP to our London PoP? Could you pop me a ticket with that route please (traceroute / mtr in text form) and your source IP. If you have something particularly bad I'll look to enable LINX for your ISP (we are whitelist only due to the smaller port size vs transits).
Sorry, I think either I was unclear or you misread what I said. I was trying to tell him that it's common for ISP to have garbage routing and sometimes it can't be helped. Nothing to do with your service.
I'm in asia and my ISP is quite big and has many pops around the world. When routing to europe, it's a 50-50 whether I get routed to west coast us then london, or I get routed directly to their own london pop. Then, from their london pop to linx, it takes somewhere between 20-70ms for one hop. I stuck with them because they were good locally but I'm giving up on them soon.
How it takes 20-70ms for one hop to linx, I have no idea. Their looking glass london pop pings linx 1ms. My understanding is it's probably due to asymmetric routing, and my ISP cares more about selling transit than serving local consumers.
t;ldr it's possible these serbian ISPs have cost-saving measures which gives them bad latency, but packet loss and lag spikes shouldn't happen. @OpenSource cares for the few ms of latency and can't show packet loss, so the only thing he can do is to move on. If he wasn't lying about the 30 providers he tried, the problem is with serbian consumer ISPs. Otherwise, it's his own problems. But it does make you wonder why he didn't stick with the "good" providers. Or were they all bad?
I don't really understand most of the technical back and forth here, but I'm astonished at your patience and professional demeanour. A+++.
Jesus, just stop. Not only does it sound like you don't fully understand the technical issue, you completely failed to cooperate with a support team who seemingly went above and beyond to troubleshoot your issue, and most egregiously, you totally misrepresented the communication you had with the aforementioned support team.
How long are you going to keep dragging this out?
I'm not even planning to, it's just that every time I reply with something, there are at least 10 more new comments to reply to...
Everything you required was provided in my latest ticket reply. I don't really see what else you need. If you do, simply specify it here... I provided you with TR to every single Europe X4B POP and even one of my backends, to which you said:
I understand and I'm no longer willing to use X4B. Let's end it here. Maybe I was wrong on some parts, but I hope I won't have to go through this anytime soon in the future. Like some other, seemingly more understandable people said:
Pretty much comes up as soon as I searched for X4B, and the mentioned two at the top of my review are just the two I found in the first thread... As for why there are uncountable people here trying to defend you, I don't really know, but again, let's keep it on this, no further replies or explanations are required.
As mentioned, of course, I'll move on.
I never said there were no good providers. I just always wanted to test different hosting companies, different DDoS Protections, networks, interfaces. Of course, I have my preference on which of them are the best (for me). Quite interesting that I never had such problems with any of them...
Also, I think the video I showed is quite an example of packet loss, especially once it teleported me back.
And again, one last time, let's keep it on this, I need no further explanations, argues or anything such. From my experience, X4B is not a great solution - to some of you, it may be... It's your preference.
Because you're the person who's appearing to be unreasonable throughout this thread. Maybe you can post the entire ticket for us to see, to see which of you was actually rude or wasn't willing to do their part.
There are a few things which cannot be fixed by the DDOS mitigation provider, it is the nature of the internet and those who are somewhat aware about internet routing and/or BGP are aware of such issues. You could ask for clarification from @SplitIce as to why this issue can't be addressed, if you had trouble understanding?
I do see an explanation added a few posts above this thread, maybe you can ask for further clarification if you missed something (and maybe sign up for their packages, since support agent time for such technical services is not exactly cheap).
OP, thank you for standing by your position and not ran away despite massive trolling effort. It is nice and refreshing to see this. Keep it up.
So anyone who understands the issue is a shill now? In that case, I missed my cheque from x4b
Sorry, I think that's an issue of latency + netcode. If you mention lag spikes and packet loss specifically, you need to show evidence of it. And if possible, reproductions of it. Of course, maybe you teleported because of packet loss. But where's your evidence?
Shilling is entirely different problem, which is not present here.
Just a reminder we did end up changing the route, mainly because in investigating his issue we discovered a better BGP community for the (on record) adjusted routes. Due to the age of the adjustment I was concerned regarding predocumentation cases but found none and it did change his route (for the better) although as expected it didnt solve his issues (which is our primary priority in any ticket, not a minor latency improvement).
If I was to hazzard a guess this would come down to one of a few things:
1. His ISP doing something funky e.g round robining outbound (destroys TCP and would show in a MTR) - not observed in ISP looking glass (or ATLAS probe)
2. Packet loss - not supported by issue persisting accross a route change (would show in a MTR, possibly also a PCAP in the form of resends), would have to be exceptionally bad to cause disconnections (usual effect is latency)
2(a). His ISP or their transits with a saturated interconnect/connection/etc (would show in a MTR) - not supported by his ISPs looking glass or by change of route
3. His PC having a firewall, or some other security software messing with traffic (hard to see but may show in a MTR, or in pcap). - Not supported by claims of "every ISP" and testing from multiple users
4. Something between us and him interrupting connections (likely best diagnosed with PCAP) or manipulating packets in some incorrect way (likely best diagnosed with a PCAP compared with one from our end)
5. Some derivative of PEBKAC error (thanks @yoursunny for introducing me to that term)
Of course I don't like guessing like that without some supporting evidence. But as this marks the end of this matter as far as I am concerned I figure I'll leave them here.
Works for me.
Anyone who understands this entire thread would be a killer support rep (if we were hiring).
Can you tell me in one sentence the issue you were trying to solve? I didn't watch his video and couldn't deduce from partial ticket screenshots. The dude likes screenshots and video more than text.
Have you tried enabling TCP-BBR on your servers? I've seen it do wonders to connections from ISPs with bad routers.