All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
[DOWNVOTING] Is LiteServer.nl a real company with real people?
tdelenikas
Member
I have a KVM VPS with those guys (liteserver.nl).
On 19/05/2017, I've opened a ticket stating that I see excessive inbound traffic (attached graphs and stuff).
A couple of months later, ticket was closed with no answer.
On 17/11/2017, I've reopened it asking for some advise. Problem continues.
No answer.
Today (23/12/2017) I've once again replied with my stats. The VPS was idling, however it managed to receive 190GB of traffic! Munin graphs show peaks for 6Mbit.
Is this a joke company or something? Are they alive? Don't I deserve a fucking answer? What's wrong with them?
Very disappointing...
FYI: Ticket "#242493 - Unusual inbound traffic recorded."
==================
nvstat output:
Database updated: Sat Dec 23 09:44:18 2017
Nov '17 53.76 GiB | 549.34 MiB | 54.30 GiB | 175.73 kbit/s
Dec '17 190.80 GiB | 36.69 MiB | 190.83 GiB | 826.93 kbit/s
Comments
I opened a couple of tickets with them and they are not only real but also very swift and helpful, at least in my case. Currently I have one KVM and one OVZ with them.
You should at least tag them, don't you think? @liteserver
Odd, what are you using your server for?
Otherwise: @LiteServer
check output of "lsof -i " as root. (post here if you're comfortable )
Liteserver is right up there with drserver in terms of friendly host, in my experience.
Setup a basic allow only firewall and see if incoming bandwidth usage changes.
i have seen such inbound with two providers, they explained its a harmless udp on a shared network or something like that.
We actually have send you a reply on your ticket regarding this issue a couple minutes before this thread has been opened.
What you're referring to is 'network noise' related to the VLAN you've been using. Detailed info about this have been mailed to you :-).
Yes, of course we're a company with real people behind it :-)
is there a magic command to stop seeing those inbounds?
Update:
I have finally received an answer with all the technical details.
in my experience, last week i open ticket about request optimization route to my isp with detailed info.
2 days later they reply my ticket and i see better route with my isp.
problem solved.
in my opinion they are ALIVE...
in your opinion what provider can do to fix your problem?
if you want provider help you, you need to cooperate with them and provide any detailed info
my2cent
null route ?
Since I've identified many "weird" UPD packets in my streams, I've setup iptables but it didn't make any difference. This was done a couple of months ago, but I didn't see any real result so I gave up.
i mean from the end user terminal, not the provider.
Are you sure you've read my initial post? Did you notice that my ticket was left unanswered for six months???
Assuming this is ARP traffic and broadcast traffic in general, you can't do much more than getting a dedicated vlan.
That's indeed the case here :-).
Ticket of @tdelenikas has already been answered and cleared up.
I had a customer a while back who wanted to open an internal abuse report every time someone on the same VLAN hit their CSF with broadcast traffic, even if it was once.
While I don't mind asking people with dropbox or minecraft lan broadcasts to turn them off there is a point where you have to realise that is just how things work.
Good to know.
Is there a pending feature request with SolusVM to ignore LAN broadcast traffic?
I'm guessing fairy dust powered gnomes. You can't prove otherwise!
You can’t ignore the broadcast traffic and have fully working connectivity.
Solution would be to put less hosts per vlan to limit it, or police it somehow to minimise it, as, for example, LINX does
I think he means to ignore it from the traffic stats.
I think it would be quite heavy on the CPU to DPI the traffic in such manner, so I’d say the onus is on he providers to make sure they use the smallest viable number of hosts per VLAN to keep the numbers of this normal traffic low, if this causes a problem
In any case it would be more taxing than the current stats which probably come from the interfaces. Don't think you'd have to DPI the traffic though. Lan/ARP traffic should match some basic filter rules based on src, dst and type. CPU overhead would probably be like running tcpdump with said filters but yeah, i wouldn't say it's worth it either.
Multiplied by the number of VMs (in some cases I've seen in excess of 500 per server) and then to substract them from existing stats. What could possibly go wrong if someone tried to DDoS it :P
I am having 2 services with them and all working fine. Only 1 ticket for more than a year. Rock solid!