Vultr SSH time outs with Vultr

@eva2000, do you have any network issue with Vultr? After made fresh installation OS & centmindmod, I restarted my vpses, and all is running well. However; after a day, or sometimes some hours later, my servers have time out error "The connection has timed out", I tried proxy or TOR but had same result. (console from Vultr is accessible, but web server to my vps is not). I had to restart vps again to see my webserver running.
Could you try then keep that vps running for a day?
I tested 2 vpses in Vultr in Illinois and New Jersey, they had same result. I can't find the contact support to ask...
My test vps at Ramnode is quite good, not have same connection error...

---

 

Thanks for your info, after the benchmark, I wanted Vultr but now have to come back Ramnode anyway

 

Yes, I already tried to both new jersey & Illinois and had same timeout issues. I really do not want my web to be unstable...

 

Just tested Vultr in Illinois with Centos 6.5_64 and seems running fine with network for hours
I opened ticket to Vultr and they answered problem has been fixed, I'll try again with Centos 7 with your beta script if network is working fine.

 

It seems that time-out problem comes from Centos 7 & centminmod 8beta...
I tested with Centos 6 & centminmod 7, it worked fine.
Cenminmod beta should be tested in more other cloud vps before to be stable....

 

Just found that something has removed my route table in Vultr vps; I installed everything Centos 7 & centminmod beta fresh
Before:

After:

I did not have this issue in centos 6.5 & centminmod 7 stable.
Do you have any ideas why it's removed and how to see the log of it?
Temporary solution for me now to restart vps then the route automatically added like Before. After some minutes, it happens again.
Or I used "ifdown eth0" and "ifup eth0" from Vultr console window, it's working again for a while...

 

Here is my eth0 config:

Code:

[root@vu7 network-scripts]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
HWADDR="52:54:00:9A:22:9E"
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="eth0"
UUID="7cd72280-8d4a-44ef-a73a-e3499ded7efc"
ONBOOT="yes"

Does dhcpclient impact to this interface?
Vultr status:

Code:

[root@vu7 network-scripts]# systemctl status NetworkManager
NetworkManager.service - Network Manager
  Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
  Active: active (running) since Thu 2014-09-18 07:05:34 UTC; 2h 17min ago
 Main PID: 593 (NetworkManager)
  CGroup: /system.slice/NetworkManager.service
  ├─ 593 /usr/sbin/NetworkManager --no-daemon
  └─3121 /sbin/dhclient -d -sf /usr/libexec/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/NetworkManage...
Sep 18 09:22:17 vu7 dhclient[3121]: dhclient.c:2676: Failed to send 300 byte long packet over fallback interface.
Sep 18 09:22:17 vu7 NetworkManager[593]: DHCPREQUEST on eth0 to 107.191.50.16 port 67 (xid=0x1a3829aa)
Sep 18 09:22:17 vu7 NetworkManager[593]: send_packet: Operation not permitted
Sep 18 09:22:17 vu7 NetworkManager[593]: dhclient.c:2676: Failed to send 300 byte long packet over fallback interface.
Sep 18 09:22:30 vu7 dhclient[3121]: DHCPREQUEST on eth0 to 107.191.50.16 port 67 (xid=0x1a3829aa)
Sep 18 09:22:30 vu7 dhclient[3121]: send_packet: Operation not permitted
Sep 18 09:22:30 vu7 dhclient[3121]: dhclient.c:2676: Failed to send 300 byte long packet over fallback interface.
Sep 18 09:22:30 vu7 NetworkManager[593]: DHCPREQUEST on eth0 to 107.191.50.16 port 67 (xid=0x1a3829aa)
Sep 18 09:22:30 vu7 NetworkManager[593]: send_packet: Operation not permitted
Sep 18 09:22:30 vu7 NetworkManager[593]: dhclient.c:2676: Failed to send 300 byte long packet over fallback interface.

But my RAMnode is fine, in the same way I installed:

Code:

[root@ramnode ~]# systemctl status NetworkManager
NetworkManager.service - Network Manager
  Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
  Active: active (running) since Sat 2014-09-13 07:42:55 UTC; 5 days ago
 Main PID: 576 (NetworkManager)
  CGroup: /system.slice/NetworkManager.service
  ├─576 /usr/sbin/NetworkManager --no-daemon
  └─694 /sbin/dhclient -d -sf /usr/libexec/nm-dhcp-helper -pf /var/r...
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Any help from you is really appreciate.

 

Found interesting messages log about avahi-daemon:


And avahi-daemon status:


Should I stopped or removed it from system? As in RAMnode this service is running without issue.

 

Just follow your steps, hope it will be fine Thank you so much

 

I already changed it and will give feedbacks in hours later to test;
Come back to my RamNode VPS; CSF config is same, but it does not have this problem:

Code:

[root@ramnode ~]# grep UDP_ /etc/csf/csf.conf
UDP_IN = "111,2049,1110,20,21,53"
UDP_OUT = "111,2049,1110,33434:33523,20,21,53,113,123"

[root@ramnode ~]# grep DROP_NOLOG /etc/csf/csf.conf
DROP_NOLOG = "67,68,111,113,135:139,445,500,513,520"

Not sure why, I asked Vultr but he had no ideas at all.

 

My Vultr VPS is still running, seems that it's ok now