All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
MassiveGRID Problem in data center in New York
I've been experiencing crashes on my VPS and my website out of the blue since today. Has anyone else had a problem?
The data center is in New York
I bought this VPS from MassiveGRID and since today I have had disconnection failures. My website stops responding and my VPS also. I made a script to monitor the network status from the VPS with Pig. The drops are surprising. If anyone else has experienced this problem please
I bought this vps from MassiveGRID since today I have had disconnection failures, my website stops responding and my vps also I made a script to monitor the network status from the vps with pig the drops are surprising if anyone else has experienced this problem please
This is the result in less than 30 minutes of the script
2024-11-16 00:54:50 - Network failure: Could not reach 8.8.8.8
2024-11-16 00:56:55 - Network failure: Could not reach 8.8.8.8
2024-11-16 00:58:00 - Network failure: Could not reach 8.8.8.8
2024-11-16 01:00:05 - Network failure: Could not reach 8.8.8.8
2024-11-16 01:02:10 - Network failure red: Could not reach 8.8.8.8
Comments
No problems. The VPS is still able to connect to sites and running what I have on it just fine.
😢😢😢
2024-11-16 00:54:50 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 00:56:55 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 00:58:00 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:00:05 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:02:10 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:04:15 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:09:22 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:11:24 - Network Failure: Could not reach 8.8.8.8
In what location is your VPS?
maybe your script sucks.
NY
It seems that at home they did not give you an education, right? They did when it came to helping.
😂👌🤡🤡🤡
If you respond like that, I can imagine how you respond to your family.
Thanks for answering, I will do more tests
May I ask if MassiveGRID allows SMTP ports especially 587? I'm interested in their deals but still considering. I use port 587 only for transactional emails.
@MassiveGRID
If the port can be used, I even sent a tick to enable port 25. It works very well, but I'm having a problem with disconnection every now and then on my VPS.
if the port can be used I even sent a tick to enable port 25 it works very well but I'm having a disconnection problem every time on my vps
2024-11-16 00:54:50 - Network Failure: Could not reach 8.8.8.8
2024-11-16 00:56:55 - Network Failure: Could not reach 8.8.8.8
2024-11-16 00:58:00 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:00:05 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:02:10 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:04:15 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:09:22 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:11:24 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:13:29 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:16:34 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:18:39 - Network Failure: Could not reach 8.8.8.8
2024-11-16 01:21:44 - Network Failure: Could not reach reach 8.8.8.8
2024-11-16 01:26:49 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:28:54 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:29:59 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:31:04 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:35:09 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:36:14 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:38:21 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:39:23 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:44:29 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:45:32 - Network Failure: Unable to reach 8.8.8.8
2024-11-16 01:47:35 - Network Failure: Unable to reach 8.8.8.8
I'm not the only one who has this problem apparently.
Getting 36% packet loss in NY (both inbound and outbound ICMP) for last 1 hour
I am having network issue as well in NYC.
such cheap deals never give a customer a premium service. cheap prices comes with such performing servers/network/support etc. What you paid you've got! No use of complaining.
Can confirm having constant disconnects to my VPS in NYC, been happening for the past hour or so.
And this is just the beginning!!!
Well, they have surely sent you a ticket and have not wanted to solve the problem.
@MassiveGRID has not responded to the offer for several days 😂😂😂😂😂🫥🫥
MTR's both ways?
Seeing zero latency and no jitter (0.2ms) on my IPs there. Taking Cogent in and out.
Can y'all post some MTR's, what /24 you're on? I got two VMs here as canaries in the coal mine, and neither have dropped.
When sending in a ticket to get these things looked at, make sure to provide your source IP, and an MTR inbound so the NOC can augment routes if needed.
Bonus points for an MTR outbound from your server.
Ignore any middle latency that does not continue down the path. Most routers in the middle have ICMP de-prioritized. If the packet loss say starts at hop 6, and continues from 7, 8, 9 to your IP, that's proper packet loss.
Example: If hop 3-6 in the middle says it's losing 24% but gets to destination IP with 0.0% loss, that's fake latency. (page 37)
Hope this helps. I'm on a .236 subnet, no issues currently in NY.
I do see occasional downs on kuma but not this bad tho.
mgrid is the hostname I gave to my VPS, I don't know why but mtr lists everything with mgrid after running for a while.
So looks like their 165.0/24 subnet is the issue.
It's fine over LAN from another VM, so someone on the node you guys are on is getting slapped.
Network's saturated outbound or inbound, both GTT and Cogent.
No nulls appear present from route views, Cogent and GTT make it to NYC, but it's hard down.
RP/0/RSP0/CPU0:route-server.newyork.ny.ibone#ping 185.122.165.3 Sat Nov 16 08:01:25.027 utc Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 185.122.165.3, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) RP/0/RSP0/CPU0:route-server.newyork.ny.ibone#traceroute 185.122.165.3 Sat Nov 16 08:01:40.853 utc Type escape sequence to abort. Tracing the route to 185.122.165.3 1 te-0-3-0-25-1-pe11.newyork.ny.ibone.comcast.net (66.208.229.9) 3 msec 1 msec 1 msec 2 be-3111-pe11.111eighthave.ny.ibone.comcast.net (96.110.34.18) 1 msec be-3411-pe11.111eighthave.ny.ibone.comcast.net (96.110.34.30) 1 msec be-3211-pe11.111eighthave.ny.ibone.comcast.net (96.110.34.22) 1 msec 3 * * * 4 be3496.ccr42.jfk02.atlas.cogentco.com (154.54.0.141) 1 msec 1 msec be3495.ccr41.jfk02.atlas.cogentco.com (66.28.4.181) 1 msec 5 be2273.rcr21.ewr03.atlas.cogentco.com (154.54.83.206) 1 msec be2262.rcr21.ewr03.atlas.cogentco.com (154.54.47.122) 2 msec be2273.rcr21.ewr03.atlas.cogentco.com (154.54.83.206) 2 msec 6 38.142.53.178 1 msec 1 msec 1 msec 7 * * *Can you show your workings of this conclusion?
Again, how did you ascertain this?
Hypervisor overselling, abuse and hardware failure can manifest in many ways. This could be CPU exhaustion, RAM exhaustion, overwhelming hardware interrupts (abuse/failure), local bridge broadcast/traffic storm/DDoS, NIC/driver issue, or many other things.
As above, this has nothing to do with the provider's network upstreams. Every server, hypervisor, VM, customer and prefix would experience the same symptom if this was the case. Thus, the network jitter and packet loss is a symptom, not a cause.
Woeful misinformation here. 38.142.53.178 is the provider's Cogent demarcation point, and the ICMP echo is from their border. Not sure what you'd even define as "hard down". Other IPs in the /24 respond just fine (eg .50, .51, .100 etc etc) and no abnormal flaps or nulls are present.
Ticket response from Massive:
Unfortunately, the outages are still happening.
So we customers have to send a ticket so that they themselves realize the problem. 🤡🤡🤡🤡🤡🤡🤡🤣🤣🤣 I thought the service was of high quality
look on the bright side, you got 4 years left.
Unmatched High Availability: Downtime? What's that? Our H/A is enabled automatically to keep your services running smoothly 24/7.
not oly 165.x .. I think it's a system problem, either with the routes or the hardware in general.
debian (172.82.65.xxx) -> 8.8.8.8 (8.8.8.8) 2024-11-16T16:59:21+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 172.82.65.xxx 6.2% 32 0.5 2.3 0.3 54.1 9.8
2. te0-7-0-22.rcr21.ewr03.atlas.cogentco.com 3.1% 32 0.9 32.1 0.8 964.5 173.0
3. be2262.ccr42.jfk02.atlas.cogentco.com 3.1% 32 1.2 29.2 1.2 863.2 154.8
4. be3295.ccr31.jfk05.atlas.cogentco.com 3.1% 32 1.8 26.4 1.7 761.5 136.4
5. 154.54.11.202 40.6% 32 1.4 1.8 1.2 2.4 0.4
6. if-be-9-2.ecore1.n75-newyork.as6453.net 3.1% 32 1.5 19.9 1.5 559.2 100.1
7. 72.14.221.146 0.0% 32 3.4 69.6 3.2 1564. 289.7
8. 142.251.225.91 0.0% 32 1.2 61.3 1.2 1463. 268.1
9. 142.250.46.193 0.0% 31 6.6 133.9 1.8 2369. 484.5
10. dns.google
It's not healthy behavior and it's not serious to propose such a thing with an HA note.