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
I'll be more than happy to talk about it if you or someone else have any proof and/or support ticket showing this issue with actual and reproducible test.
Just saying "that's not working / It don't get my speed" is not a good way to find support.
You're not doing the best job as an rep here ;-). Seriously, there is a search function here, if not Google. There you go, your guaranteed 250Mbps in London in reality, independent test by another forum member:
So you're testing your speed on your server using speedtest.net ?
When I was talking about reproducible test, I mean "true" tests. You know, like the ones that can prove something and also be meaningful.
And then we can talk.
Heh.
Mate, I'm not testing anything. This are complaints from your own Customers that you don't care about.
Apparently if you test from another network than OVH the results are vastly different, so I'm inclined to believe there's something there, especially that I see a pattern and it wasn't the only Customer of yours complaining.
Your post really shows the attitude OVH has towards their Customers. It's in your best interest to fix your problems, your Customers shouldn't be the ones forcing you to do it, yet you chose to dismiss it outright. Great job OVH !
Anyway, just reminded the issue, someone else posted recently here, in case someone would want to take you up on the unmetered, 'guaranteed' option expecting any real bw/performance/support. You get what you pay for.
Good luck ;-).
I'm not asking you to test anything, you point me some "tests" showing an "issue", i'm telling you what actual tests should be. That's it. I can't even understand how you can take seriously result from speedtest.net while being "a provider".
I'm not looking at all subject speaking about OVH, if there is complaint here, maybe I missed them.
Peoples that actually contacted me on here know that I do care a lot about our customers and there's a lot of people that actually contacted the OVH Support for an issue and get it resolved quickly. But yes, sometimes it can take few hours or days, yes. Yes, sometimes there's a bug somewhere on a router or a switch impacting the speed of one specific customer or one specific switch, etc. (maybe that's why we ask for tests showing the issue when our own tests on tests servers do not show any issue. Did you think about that ?) We are not managing 200 servers hosted on a reseller, we have to manage 270 000 servers. Depending on the complexity of the issue, yes it can take some time.
The only things I'm saying is that coming to the support saying "my speed is bad" but not actually showing it is not the way to doing it. And sending Speedtest.net is really not.
Complaining is a thing, proving the issue and contacting the support is another one.
I'm not sure you will be happy if someone say your network is bad without proving it or contacting you.
Getting back to the subject of this thread please.
If someone want to test the bw or latency from our network, I may be able to help (test servers for few days, etc.).
Thanks.
@MaikoB
Upload test:
Multiple download tests:
Traceroute from my own connection in the Netherlands:
I am getting better speeds than advertised. It might have improved since you last checked @clouvider
@clouvider
Not even coming close to filling up my 500 Mbit/s home connection when doing an upload on your public Speedtest.net server in Enfield.
And yes, I really do have a 500 Mbit/s home connection that I can fully utilize:
More than happy to look into it, shoot me an MTR if you can and I'll happily look into it.
My point, or rather OPs point, re: OVH was about issue with local connectivity, in the same country, to all speedtest.net servers from the actual server -> outside. None of which could achieve the guaranteed speed. What you show here is completely different, it's a single ISP heaving an issue with sending data to us, so completely different direction (where the provider, us, has less control over), and completely different scenario. Again, I was talking about a pattern.
Nevertheless, happy to look into options for you, but the inbound route to us cannot really be forced by us, and is likely something that your ISP will have to fix, this is dictated by limitations of BGP protocol.
D
Install Ubuntu, CentOS, CloudLinux, RHEL using the distribution ISO - you'll see that rp filtering are actually enabled by default.
wooopie.
+1.
i can do something for you in Romania, if you are interesed please pm but such traffic is not cheap.
Yes, but should be in loose mode.
What should be done in your scenario and what is done by default are two different things.
Default value is 1, 1 is 'strict'. It's most definitely not disabled by default as you said, nor in loose mode ('2') as you say it should.
my scenario? My network not need special requirements and the issue that customer explained has nothing to do with my network, but with his configuratio and i'm trying help him finding a solution.
Have nice monday
What @clouvider said - default is 1 - aka strict
So basically you say that seflow cannot support default kernel settings :-)
That sounds promising.
oh ok you're searching the drama. Sorry we not require that, i'm just trying to help customer to fix an issue. Any O.S. default installation work well in our network.
Please read what i wrote, i see user to check that option IF he had in his custom virtualized enviroment 2 NICs. If not to check the nic offloading. But again has nothing to do with our network, we not require anything
Case Closed.
This has nothing to do with routing. A router is NEVER allowed to modify packets in ANY way.
How mani active nic do you have in both server?
This is entirely unrelated, but if you think that this helps in solving your network fuckup: It's only one NIC on both ends.
Ok so the rp filter is not the issue.
Please check my second suggestion about nic offload
I think most agrees that it was never expected to be the issue, it wouldn't modify the packet.
tcp proxy / syn proxy running by any chance your end @matteob ? That would at least partially explain why timestamps differ ?
TCP segment, RX and TX checksum offloading are all disabled on my SeFlow server but as for the Vultr server, I have no control over the hardware and as such can't disable RX checksum offloading there. Please PM me if you have more tips to do further debuggung, let's not completely derail this thread.
No customer does not have aby security service with us. Just server - tor - distribution switch - edge routers - border routers
There is no way for us to manipulate packets even if is inside ddos protected area, but is not that case. (And honestly is first time that i read about that issue)
Sounds like the typical SYNProxy Setup with bridging. I'm wondering how many packets one of your filters can deliver if it only process packets inside of it's kernel, not explicitly in the userspace by using kernel bypass methods?
Please read the post before writing....
https://10gbps.io/
provides you with unshared 10gbps port
Plenty can for the right budget. The one they propose for 10G of the upstreams they have is reasonable.
Question is if he OP is prepared to pay ~1.5k GBP for 10G dedicated on an E3.
Sir, everything can be done for 27 dollars.
you can get a E5 with 32 gb ram with 300tb bandwidth for 1000$
Great, you can also get an E3 with 16 GB of memory and 30 TB BW for £40 with LET discount.
We can discuss many different things we can get for different amount of money but that's beside my point.