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
What you mean? Can you please elaborate?
We report every outages here http://status.seflow.net
p.s. @wa44io4 have one test server from us, so he can really know the stability and performance of our network, without someone that lie because it just hate my attitude :-)
Matteo offered a server just to test the network and stability. So far it seems to be perfectly fine for me, though due to holidays in Italy I couldn't order the Unmetered Servers with Matteo
But after testing for this whole month I should have more experience about SeFlow. I will be looking forward to solid performance and buying more servers from SeFlow.
Yes correct we sold all E5 2620v4 CPUs and need wait tomorrow that supplier reopen warehouse to restock them. i'm sorry for that but suppliers closed for 20 days and we was not able to restock in time.
Got both the server ready with WorldStream ... Benchmark here -
Sure. Global ones.
Not if your NETIX (that was last one) link fails less than your monitoring limit, or when your appliance seems to manipulate TCP-ACK packets (why else would they arrive on DST with OTHER checksum? This happens right now between you and seemingly anyone behind Level3, especially Vultr...), or when unreachable entirely...
At this time aside of the 99EUR Gbit i would not recommend your services, because at 100Mbit the HW and this issues are not worth anything over a Hetzner or Leaseweb server and Hetzner even provides better protection on top.
This was reported in our status page and fixed while ago:
http://status.seflow.net/incidents/6fpyqxk13rd5
>
>
this happen when the ip receive DDoS and is forwarded under mitigation mode. If you have DDoS Protected plan open a ticket to SOC to find a solution (best is, if your server receive frequent DDoS, move it under AlwaysON mode). Here differencies about standard Sensor mode and AlwaysON mode:
https://manage.seflow.it/index.php?/knowledgebase/article/30/ddos-mitigation--sensor-mode-vs-alwayson/
If you're in sensor mode, the protection take 22sec to start mitigation and this is why you get 1 minutes outages. Under AlwaysON mode you're filtered immediately and your server is not hitten.
If you not have any security product we not manipulate anything, please elaborate this.
Every company have different products this mean that there is no absolute better company. This only mean that for your needs we not offer any value added service then them.
For example Hetzner DDoS Mitigation does not provider Alwayson protection mode or packet validation solution. We have lot of customers switched to us with word "your protection is better than..." and i think some other will leaved us for opposite reasons. It's the way the business work.
For packet validation feature https://manage.seflow.it/index.php?/knowledgebase/article/72/ddos-seguard-custom-port-list-protection/
I will be happy to clarify any issue you get to see you happy with us.
Regards
@wa44io4
worldstream doesn't allow streaming.
source: https://www.worldstream.nl/WorldStream_TOS.pdf
you can ask at https://10gbps.io or https://10g.amsterdam for a custom quote
3W INFRA has also a good promotion running http://www.webhostingtalk.com/showthread.php?t=1667160
there is also nforce.com but i think they don't allow streaming on every network class, you may have to ask
and last but not least https://www.m247.ro/en/services/dedicated-servers/
This test only benches the inbound speed, which is completely meaningless for streaming.
The software I believe you use says it's in own datasheet it needs ~5s to detect an attack in this mode.
Wansight is only for customer reporting. We not use it for mitigation and detection.
I had 1 server previously with WorldStream and today got 2 more. So, far they never said they won't allow video streaming on Unmetered Bandwidth servers.
Their TOS says they allow it on-permission and I think I have the permission.
Thanks for other recommendations ....
NFOrce - I am their regular customer but their network / bandwidth is costly.
M247 - Can match WorldStream prices but the network is 2Gbps hard limit and the CPU isn't same.
3W INFRA - Didn't really contacted them this time but I should have tried getting a quote
10Gbps.io - Far more costly and network is 2Gbps hard limit.
Please link me to a better benchamarking script ... thanks
Sure they do, if they approved it on a case-by-case basis.
>
source: https://www.worldstream.nl/WorldStream_TOS.pdf
It's hard to simulate streaming in a real world scenario. To simply test outbound bandwidth (inbound is completely irrelevant for streaming) you could use something like iperf 0. The problem is that this is always from server to server, the hard part about streaming is that the actual people who watch your streams don't have access to a backbone with multiple carriers, they are solely with their ISP. And if the ISP is for example DTAG it is more or less guaranteed to be laggy even though you might have enough capacity from server to server, since DTAG transit is very expensive and most providers don't have direct access to it. (So they can't control if your stream will be laggy or not).
Worldstream for example doesn't have direct access to DTAG or UPC, both combined have a market share of > 50% in Germany 1. So alone for Germany they don't have it in their hand if you streams will be laggy or not even though they might offer you the theoretical "capacity" for it. So even iPERF doesn't matter, what matters is a quality network with enough capacity.
Got it ... however, I am satisfied with the network and I am getting good speed from even Germany. Also, I am not trying to build something like Youtube so I am not going to invest thousands of EUROs for getting streaming servers. Hope you understand that.
So far everything is fine for me and I am happy with all the providers I used for video streaming. The migrations or, changing providers is becuase of better price mainly. However, the DDoS protection and better support matters too which I am getting with WorldStream.
That's funny. I remember when one of the biggest illegal streaming sites used Worldstream.
hmm
i would contact worldstreams support
You can contact these Skype Sales Staffs ...
[WorldStream] Nick de Jong #115 - nick.de.jong0
[WorldStream] Rick Vollebregt - rickvol1
Updated network usage -
Sure:
Usually, connections built from Vultr (NL-AMS) to SeFlow work perfectly fine:
tcpdump at seflow:
tcpdump at vultr:
Let's compare the second packet (SYN-ACK):
Everything works fine, but randomly TCP connections fail to establish:
tcpdump at seflow:
tcpdump at vultr:
Let's compare the second packet (SYN-ACK) here as well:
Not seeing it yet? Let's trim it down:
Still not? What about that:
That's right, the TCP packet timestamp has been changed to something else. Now, here's the thing: I have another VPS at another provider (Melbicom) that seems to take the same route between SeFlow and Melbicom both inbound and outbound, however it does not happen there, nor was I able to reproduce it with some other servers that I have tried this. At the same time, the server at Vultr seems to work perfectly fine and is able to repeatedly build connections without any hiccups to other providers. I also don't have Vultr DDoS protection or the firewall enabled for this server.
Here's an MTR in both directions:
Let's have a closer look at the packets with tcpdumps checksum functionality:
tcpdump at seflow:
00:00:50.945198 IP (tos 0x0, ttl 58, id 36048, offset 0, flags [DF], proto TCP (6), length 60) vultr.42652 > seflow.22: Flags [S], cksum 0x02c1 (correct), seq 2764091288, win 29200, options [mss 1460,sackOK,TS val 3732742984 ecr 0,nop,wscale 7], length 0 00:00:50.945207 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) seflow.22 > vultr.42652: Flags [S.], cksum 0x9f29 (correct), seq 2832303451, ack 2764091289, win 28960, options [mss 1460,sackOK,TS val 801703552 ecr 3732742984,nop,wscale 7], length 0Everything looks good with the packets and checksums at SeFlow, correct checksum is sent out to the client (Vultr) where it should arrive with the same checksum:
tcpdump at vultr:
00:00:50.937817 IP (tos 0x0, ttl 64, id 36048, offset 0, flags [DF], proto TCP (6), length 60) vultr.42652 > seflow.22: Flags [S], cksum 0x02c1 (correct), seq 2764091288, win 29200, options [mss 1460,sackOK,TS val 3732742984 ecr 0,nop,wscale 7], length 0 00:00:50.953491 IP (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto TCP (6), length 60) seflow.22 > vultr.42652: Flags [S.], cksum 0x9f29 (incorrect -> 0xa029), seq 2832303451, ack 2764091289, win 28960, options [mss 1460,sackOK,TS val 784926336 ecr 3732742984,nop,wscale 7], length 0See the part where it says "incorrect"? That's the incorrect checksum of the TCP packet calculated on the virtual NIC at Vultr.
Let's bring the lines closer together:
seflow.22 > vultr.42652: Flags [S.], cksum 0x9f29 (correct), seq 2832303451, ack 2764091289, win 28960, options [mss 1460,sackOK,TS val 801703552 ecr 3732742984,nop,wscale 7], length 0 seflow.22 > vultr.42652: Flags [S.], cksum 0x9f29 (incorrect -> 0xa029), seq 2832303451, ack 2764091289, win 28960, options [mss 1460,sackOK,TS val 784926336 ecr 3732742984,nop,wscale 7], length 0Are you still following? Because the timestamp value of the packet is incorrect, the checksum is as well and the Linux kernel therefore drops the packet.
This is what in a real world is called asynmetrical route.
echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
To be persistent
nano -w /etc/sysctl.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
This should fix your issue if you have dual interface in your vm/dedicated. If not please check next reply with another possible cause.
But this is not a provider network related issue and need to be investigated on host level.
Regards
Why don't you go fix it on your end (because clearly, there is one) instead of making petty excuses.
I know from what provider I won't be buying servers when we expand our network.
Because,
RP Filtering is a linux feature that is not enabled by default, probably the customer enabled it for security reason not considering that.
Please also remember that i suggest this **only ** if on your machine you have two active interfaces. If this is not the case there is something else that cause this and need to be investigated, but is something on the servers because we have nothing that can manipulate packets in our networks.
If above is not the case, also remember that checksum error on tcpdump is a common issue if you have checksum offloading on your NIC.
Please check it with:
ethtool -k eth0 | grep on
Replace eth0 with your network interface.
If is enabled type:
ethtool -K eth0 tx off rx off
and retry.
Regards
i'm sorry to read that, we will do our best to improve our service to see your decision changed
Have nice monday
How is the TCP timestamp related to the asymmetric i routing ?
I don't think asymmetric routing is what @Fusl has a problem with. I know it's a long post, but you could make an effort to actually read it.
Not directly related, but is related to how tcpdump handle it. If you read both of my reply i posted two possible cause, one if you use 2 nics in same host and other one for offloading.
I not know which service he have with us and vultr so i need to take all possible cause.
Please refer to tcpdump documentation for further details.
Hi,
OVH have a big and very good network if you target EU and NA.
In Europe, all our servers come with 500Mbps guarantee bandwidth with a paid option to get 1Gbps guarantee (upto 3Gbps on some models).
https://www.ovh.com/us/dedicated-servers/enterprise/
https://www.ovh.com/us/dedicated-servers/hosting/
https://www.ovh.com/us/dedicated-servers/storage/
https://www.ovh.com/us/dedicated-servers/hg/
If you have any questions, I'll be happy to help.
Tcpdump documentstion for RF Filtering in Linux (kernel feature) ? I don't think so.
@MaikoB that includes your London PoP where no one could get their guaranteed BW, or any reasonable BW really, to any Major UK eyeball ? Dunno if that improved recently, but frankly it proved this guarantees mean nothing.
@Clouvider
No, RP_filtering for kernel dropping that he wrote.
Offloading for warnings on tcpdump