Issue Network drops every 12 hours [IONOS]

[Archerford]

I’ve started having an issue recently with my IONOS dedicated server where the network drops, just stops work every 12 hours. I have to log into Cloud Server and force restart the server, when it comes back up, it works for another 12 hours and stops. The server doesn’t crash, the network just stops working. Websites are unavailable, SSH doesn’t work. The server is running Ubuntu 20.04 and the last version of Plesk / Update #2. Contacted IONOS, they told me it was my problem. It’s been working fine for months and only recently started doing this. I’ve made no changes that I’m aware of. I read another article about someone having a similar problem where they talked about eth0:1 and eth0:2, so I requested another IP from IONOS and edited my interface file with the new IP … and it worked fine for two days, until today when it started dropping network connections again. I can’t find any errors in the error log, only a log entry that says NAMED stop responding about the same time the network goes down. Any idea on how to troubleshoot this would be much appreciated.

 

[NezoSam]

I have the same exact issue as well I'm with IONOS
the issue started about 3 days ago

 

[NezoSam]

did you update your pleask to

Plesk Obsidian
Version 18.0.39

 

[Maarten.]

Did you check the fail2ban logs? Are the server IP-addresses on the fail2ban trusted IP list?

 

[NezoSam]

Did you check the fail2ban logs? Are the server IP-addresses on the fail2ban trusted IP list?

fail2ban is disabled on the server since we are running imunify360

 

[learning_curve]

@Archerford FWIW How did you solve it? @NezoSam We use IONOS (Cloud Servers) but haven't had any examples of this at all. You are both are using Dedicated NOT Cloud Servers provided by IONOS is that right? Only asking because, there's been previous posts on here, where despite almost identical Server OS / Plesk Setups & Releases, it's always been the IONOS Dedicated Server users, that have had these type of issues c/w NO Technical Support, because it's excluded normally, on all IONOS Dedicated Servers. NO TS is the same on IONOS Cloud Servers, unless you opt for an extra, chargeable IONOS Service Management Package (which we don't). Additional question: Are you both using IPv6?

 

[carlosarmando85]

@Archerford FWIW How did you solve it? @NezoSam We use IONOS (Cloud Servers) but haven't had any examples of this at all. You are both are using Dedicated NOT Cloud Servers provided by IONOS is that right? Only asking because, there's been previous posts on here, where despite almost identical Server OS / Plesk Setups & Releases, it's always been the IONOS Dedicated Server users, that have had these type of issues c/w NO Technical Support, because it's excluded normally, on all IONOS Dedicated Servers. NO TS is the same on IONOS Cloud Servers, unless you opt for an extra, chargeable IONOS Service Management Package (which we don't). Additional question: Are you both using IPv6?

Hello I'm having exact same issue for the second time with Dedicated IONOS, first time after weeks decided to create a new server and move all the data, please let me know If you solved this somehow, thanks

 

[jaym902]

I’ve started having an issue recently with my IONOS dedicated server where the network drops, just stops work every 12 hours. I have to log into Cloud Server and force restart the server, when it comes back up, it works for another 12 hours and stops. The server doesn’t crash, the network just stops working. Websites are unavailable, SSH doesn’t work. The server is running Ubuntu 20.04 and the last version of Plesk / Update #2. Contacted IONOS, they told me it was my problem. It’s been working fine for months and only recently started doing this. I’ve made no changes that I’m aware of. I read another article about someone having a similar problem where they talked about eth0:1 and eth0:2, so I requested another IP from IONOS and edited my interface file with the new IP … and it worked fine for two days, until today when it started dropping network connections again. I can’t find any errors in the error log, only a log entry that says NAMED stop responding about the same time the network goes down. Any idea on how to troubleshoot this would be much appreciated.

Hello, I am wondering if you ever found a solution to your issue? This same thing just started happening to me, network drops every 12 hours on a IONOS dedicated server.

 

[bradz]

I am also on IONOS - Dedicated - Linux Server ..
Ubuntu 20.04.4 LTS
Plesk Obsidian Version 18.0.41 Update #1, last updated on Feb 8, 2022 06:29 AM

The first post describes the situation!
It is happening to me but not predicable, not everyday, my be a week or a few days.
In addition, I have 4 identical servers, only 2 have done this so far.
When I call IONOS support, the support person had taken some time to look for issues on the serve, but did not see any.
They did say that they had seen another similar server doing it.
They said that they found some info regarding a Ubuntu 20 having a "network Sleep" mode/issue with low activity.
Your thoughts?
Solutions?
Thanks for any help!
Brad

 

[learning_curve]

Back to post #6 and the two most important questions:

a) Is eveybody that is having this issue, using IONOS Dedicted Servers NOT IONOS Cloud Servers?

b) Is everybody that is having this issue, actively using IONOS provided IPv6 addresses and IPv6 service on their servers?

@bradz This item:

They said that they found some info regarding a Ubuntu 20 having a "network Sleep" mode/issue with low activity.

It appears as though whoever said that has just made that up! Unless, they were referring to another Ubuntu 20.04 version & not Ubuntu 20.04 LTS...
Never seen that anywhere else & never experienced it, all the time we've been using Ubuntu 20.04 LTS (that's been provided on any IONOS Cloud Servers).

 

[carlosarmando85]

IONOS Dedicated Server using IPv4 addresses.

 

[bradz]

I am using IONOS Dedicated Server using IPv4 addresses
With the IPv4 IP being shared for multiple sites

 

[learning_curve]

So (perhaps) somewhat predictably, so far, it is ONLY IONOS Dedicted Servers.
That makes things a lot more difficult to trace, because all of the Dedicted Server setups will differ... and... IONOS will just pass the issue straight back to you as they are (No Tech Support) Dedicated Servers and NOT (Full Tech Support) Dedicated Server Hosting, where IONOS would manage and own the issue.

The IPv6 question, was because previously (but in some rare cases - even now) there was an IPv6 setup issue with IONOS, which then resulted in Network failures (both IPv4 and IPv6). We had that ourselves briefly, but it can be rectified via making changes to /etc/network/interfaces if/when it occurs. There was also an example of Network failures that was related to resolve and systemd but which can be rectified via changes to /etc/systemd/resolved.conf this again, was triggered from an IPv6 source unfortunately, so neither of these will be of any relevence to this issue, as it looks like everyone - so far - is using IPv4 only.

 

[bradz]

Thanks for looking at this and giving it deep thought! I have 4 server that I setup within a week, all with the same specs. Two have done this, one more then the other. The other two have been totally fine. If I learn more or any differences between the servers, I will post. Again, thanks! Brad

 

[bradz]

Thinking about it more, during the set, I did run into an IP issue. I think it was caused by bad settings on my part.
I am now thinking it was the 2 servers dropping the network. I will compare the /etc/systemd/resolved.conf files.

 

[bradz]

/etc/systemd/resolved.conf --- all 4 servers identical file
/etc/network/interfaces --- same except change in ip6

 

[learning_curve]

/etc/systemd/resolved.conf --- all 4 servers identical file
/etc/network/interfaces --- same except change in ip6

So... It's pretty unlikely to be the same issues that were experienced on IONOS Cloud Servers then, which are Virtual servers anyway... but FWIW / Just in case etc - The relevant parts of the fault-free version of /etc/systemd/resolved.conf now used, having left all other systemd associated files as per default, is:

~
# See resolved.conf(5) for details

[Resolve]
# Fallback to Cloudfare / Quad9 Backups if /run/systemd/resolve/resolve.conf IPs fail
FallbackDNS=1.1.1.1 9.9.9.9
DNSSEC=true
DNSOverTLS=true
Cache=no-negative
~

The relevant parts of the fault-free version of /etc/network/interfaces now used, having left all other interfaces associated files as per default, is:

~
#For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet6 loopback

# The primary network interface
allow-hotplug ens192
iface ens192 inet dhcp

# IPV6 Setup
iface ens192 inet6 static
accept_ra 0
address ******************::1
netmask 64
gateway fe80::1
~

The "hidden" part to the above, is, to enable the IPv6 service provided by IONOS & use it with an IONOS Ubuntu/Plesk server package, this mod was needed:

~
# Enable IPv6 addresses support on Plesk Server
net.ipv6.conf.all.disable_ipv6=0
net.ipv6.conf.default.disable_ipv6=0
~

That ^ had be added to the default etc/sysctl.conf file otherwise there was no IPv6 service, despite the Cloud Servers having IPv6 addresses (!) That is of no concern, if you're on IPv4 only and no doubt the /etc/network/interfaces will not be either, but, the #Fallback part of /etc/systemd/resolved.conf might be worth a look at, IF, the IONOS Dedicated Servers, are like the IONOS Cloud Servers and still using the IONOS in-house mod* of using ifupdown NOT netplan in both Ubuntu 18.04 LTS & 20.04 LTS despite the reasons discussed here Since adding those #Fallback IPs, we've never had any Network failures since. YMMV

*IONOS claimed that this was because this bug had not been resolved, to suit their nameserver hierarchy (back then). This might change with Ubuntu 22.04...

 

[carlosarmando85]

Hello,
Anyone having the IONOS issue please check the output and let me know If you have an error here:

sudo networkctl status

 

[learning_curve]

@carlosarmando85 It's expected that the IONOS Cloud Server setups differ from the IONOS Dedicted Server setups anyway, plus there's the effects of the default IONOS in-house mod (see above) of using ifupdown NOT netplan on their Ubuntu Cloud Servers (don't know, until somebody advises, if that's the same on Dedicated Servers?) to factor into this challenge too. Somewhat predictably then (for us anyway) the command that you've posted does produce this error:

# networkctl status
WARNING: systemd-networkd is not running, output will be incomplete.
~~

That's because of this:

# systemctl status systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-networkd.service(8)
~~

Yet, due to other setup configs made, we (i.e. IONOS Cloud Server users) don't currently or intermittently have any Network failures like the OP and others do.

 

[carlosarmando85]

@carlosarmando85 It's expected that the IONOS Cloud Server setups differ from the IONOS Dedicted Server setups anyway, plus there's the effects of the default IONOS in-house mod (see above) of using ifupdown NOT netplan on their Ubuntu Cloud Servers (don't know, until somebody advises, if that's the same on Dedicated Servers?) to factor into this challenge too. Somewhat predictably then (for us anyway) the command that you've posted does produce this error:



That's because of this:


Yet, due to other setup configs made, we (i.e. IONOS Cloud Server users) don't currently or intermittently have any Network failures like the OP and others do.

Hi,
The fix I found only applies to IONOS Dedicated Servers, unfortunately.