Skip to main content

When Your Node is Not Accessible

When a virtual node becomes unreachable, the goal is to isolate where the failure is: at the node itself, at the network in between, or at a service inside the node. This guide walks through the checks in order, from quickest to most involved.

Step 1: Check Reachability with Ping​

Before doing anything else, verify whether the network can reach your node.

ping xx.xx.xx.xx

Replace xx.xx.xx.xx with your server's public IP.

A reachable node responds like this:

e2e-Vostro-3546:~$ ping 164.52.200.65
PING 164.52.200.65 (164.52.200.65) 56(84) bytes of data.
64 bytes from 164.52.200.65: icmp_seq=1 ttl=52 time=313 ms
64 bytes from 164.52.200.65: icmp_seq=2 ttl=52 time=98.2 ms
64 bytes from 164.52.200.65: icmp_seq=3 ttl=52 time=76.9 ms
^C
--- 164.52.200.65 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

An unreachable node looks like this — no responses, 100% packet loss:

e2e-Vostro-3546:~$ ping 164.52.200.65
PING 164.52.200.65 (164.52.200.65) 56(84) bytes of data.
^C
--- 164.52.200.65 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6144ms
Note

If ICMP is disabled on the node, ping will fail even when the node is up. A ping failure is strong evidence, not proof. Move on to SSH/RDP.

Step 2: Try SSH (Linux) or RDP (Windows)​

SSH for Linux Nodes​

ssh username@xx.xx.xx.xx

Replace username with the actual user on your node and xx.xx.xx.xx with the node's IP.

RDP for Windows Nodes​

Use the Remote Desktop client for your operating system and connect to the node's public IP, for example xx.xx.xx.xx:3389. Replace the username and password with the configured Windows credentials.

If the connection fails to even open, the node is most likely down, hung, or has lost network configuration. Continue to Step 3.

Step 3: Check the Node State in MyAccount​

Open the MyAccount portal and confirm the node's state:

  • Running — the node is up. The problem is likely network, firewall, or service-level.
  • Powered off — restart it. Heavy CPU or memory pressure can sometimes power off a node.
  • Error / Stuck — see Step 5 (Access Console).

Step 4: Reboot the Node​

If the node is stuck in a hung state (no SSH, no console response, very high CPU), reboot it from the MyAccount portal. Rebooting often resolves out-of-memory conditions and crashed services.

Allow a few minutes for the node to come back up.

Step 5: Access the VNC Console​

A VNC console is available regardless of network configuration — it gives you a direct connection to the node's terminal even if the public IP, firewall, or network has been misconfigured. The console is the right tool for:

  • Logging in when SSH or RDP is blocked.
  • Reverting a bad firewall, network, or service configuration.
  • Reading the OOM-killer messages or kernel error on a hung node.
  • Confirming whether the node booted at all.

If the node has run out of memory or the kernel has crashed, the VNC console will show an OOM-killer trace or a blank screen — that confirms the node is hung and needs to be rebooted. After rebooting, increase the node's resources or fix the runaway process to prevent recurrence.

If the firewall or network configuration was changed and you have lost connectivity, log in to the console and revert the change.

Step 6: Check Resource Utilization​

A node that is constantly maxed out on CPU or memory will frequently become unresponsive. Use MyAccount's Monitoring section to review CPU, memory, and disk over the period the issue happened. If the node is consistently saturated, upgrade the plan or trace the runaway workload.

See High CPU Load Troubleshooting for how to identify and stop a runaway process from inside the node.

Step 7: Check Disk Utilization​

When disk usage reaches 99%, the node can become unresponsive or even drop to the Powered Off state. Open the Monitoring view in MyAccount and check the disk graph for the period.

If the disk is full and you cannot SSH in, log in via the VNC console and free space. If you cannot reach the console either, contact cloud-platform@e2enetworks.com.

See Running Out of Disk Space for what to clean up.

Step 8: Firewall or Network Configuration Damaged​

If a recent firewall or network change has cut off public access, two options exist:

  • If you have enabled CDP Backup, restore the most recent backup of the node.
  • If CDP Backup is not enabled, log in via the VNC console and revert the change manually. If the console is also inaccessible, contact cloud-platform@e2enetworks.com.

Step 9: Slowness and Network-Level Issues​

When the node is reachable but slow, or shows intermittent packet loss:

  • Run ping against both your node and a well-known destination (such as google.com or 8.8.8.8) at the same time.
  • If both show packet loss, the issue is likely on your local network.
  • If only your node shows packet loss while well-known destinations are clean, the issue is likely between you and the E2E network. Send the parallel ping reports and a traceroute to your node to cloud-platform@e2enetworks.com.
  • If possible, repeat the test from a different network provider (for example, switch from broadband to mobile data) to rule out a local ISP problem.

For more detail on ping and traceroute, see Network Troubleshooting.

Still Stuck?​

If you have walked through the steps above and the node is still not accessible, contact cloud-platform@e2enetworks.com with:

  • The node ID or name.
  • The IP you are trying to reach.
  • The output of ping and traceroute from your machine.
  • Whether SSH/RDP, the VNC console, and the MyAccount node state are reachable.
Last updated on May 15, 2026.