|
| 1 | +--- |
| 2 | +meta: |
| 3 | + title: Connectivity tests for unreachable Instances in a Private Network |
| 4 | + description: When your Scaleway Instance is unreachable via its attached Private Network, this page sets out a detailed testing process to help you diagnose and resolve the issue. |
| 5 | +content: |
| 6 | + h1: Connectivity tests for unreachable Instances in a Private Network |
| 7 | + paragraph: When your Scaleway Instance is unreachable via its attached Private Network, this page sets out a detailed testing process to help you diagnose and resolve the issue. |
| 8 | +tags: resource private-network connectivity ping test |
| 9 | +dates: |
| 10 | + validation: 2025-05-30 |
| 11 | + posted: 2025-05-30 |
| 12 | +categories: |
| 13 | + - network |
| 14 | +--- |
| 15 | + |
| 16 | +When an Instance becomes unreachable over a Private Network, it can be challenging to diagnose and resolve the issue. |
| 17 | + |
| 18 | +To help streamline the troubleshooting process, the Scaleway Network team has developed a step-by-step technique that can help identify and potentially fix connectivity problems. |
| 19 | + |
| 20 | +This technique involves a series of tests and checks to determine the root cause of the issue, including DNS resolution, ARP table verification, and Link-Local Address (LLA) calculation. |
| 21 | + |
| 22 | +By following these steps, you can quickly determine if the issue is related to DNS, network configuration, or resource-specific problems, and take corrective action to restore connectivity. |
| 23 | + |
| 24 | +It is particularly useful to carry out these steps before opening a support ticket, and supplying the results of the tests. This enables a swifter and more efficient resolution of your problem. |
| 25 | + |
| 26 | +## Step-by-step connectivity testing process |
| 27 | + |
| 28 | +### Step 1: Ping the non-communicating Instance from another Instance in the Private Network |
| 29 | + |
| 30 | +1. [Connect to another Instance](/instances/how-to/connect-to-instance/) in the same Private Network as the non-communicating Instance. |
| 31 | + |
| 32 | +2. Try to reach the non-communicating Instance with a ping via `ping instance-name` (where `instance-name` is the name you gave your Instance upon creation.) |
| 33 | + |
| 34 | +3. Carry out the same test for both IPv4 and IPv6, ie `ping -4 instance-name` and `ping -6 instance-name`. |
| 35 | + |
| 36 | + - If these tests fail, there may be a DNS issue meaning the Instance's hostname cannot be resolved, see step 4 directly below. |
| 37 | + - Otherwise, if the tests succeed, continue to the section [Check ARP](#step-2-check-arp) |
| 38 | + |
| 39 | +4. Consider checking DNS records via the Scaleway Domains and DNS CLI as documented [here](/vpc/reference-content/dns/#troubleshooting), to see if the private DNS zone is correctly configured and the Instance's DNS records are up-to-date. |
| 40 | + |
| 41 | + <Message type="important"> |
| 42 | + Note that we do not recommend editing these records yourself, rather open a support ticket with the information you have gathered. |
| 43 | + </Message> |
| 44 | + |
| 45 | +### Step 2: Check ARP |
| 46 | + |
| 47 | +A server's **A**ddress **R**esolution **P**rotocol (ARP) table maps IP addresses to MAC addresses on a local network. Use this data to find the probe state for the target Instance's MAC address. |
| 48 | + |
| 49 | +1. From another Instance in the same Private Network as the non-communicating Instance, view ARP information via an `ip neigh` command. |
| 50 | + |
| 51 | + You should see an output of many lines in the following format: |
| 52 | + |
| 53 | + ``` |
| 54 | + 172.16.8.2 dev ens5 lladdr 02:00:00:1c:0d:9b REACHABLE |
| 55 | + ``` |
| 56 | + |
| 57 | +2. Find the line beginning with the non-communicating Instance's private IP address, and containing also its MAC address. You can check both via the Scaleway console in the Private Network's **Attached resources** tab. You can use the following command to identify the line, replacing `<MAC_ADDRESS>` with the Instance's MAC address: |
| 58 | + |
| 59 | + ``` |
| 60 | + ip neigh | grep --ignore-case <MAC_ADDRESS> |
| 61 | + ``` |
| 62 | + |
| 63 | + The line ends with the state of the probe for that Instance's MAC address. |
| 64 | + |
| 65 | + `FAILED` shows that the system tried to resolve the MAC address but did not get a response. |
| 66 | + |
| 67 | + Continue to the next stage of testing. |
| 68 | + |
| 69 | +### Step 3: Try reaching the Instance using its LLA |
| 70 | + |
| 71 | +If the Instance could not be reached via the resolution of its MAC address, next you should try to reach it via its IPv6 **L**ink **L**ocal **A**ddress (LLA) in the Private Network. |
| 72 | + |
| 73 | +The LLA is calculated from the Instance's MAC address. |
| 74 | + |
| 75 | +1. Use an online tool or guide to carry out the standardized process of calculating the Instance's LLA from its MAC address. Remember that you can view its MAC address from the Scaleway console, in the Private Network's **Attached Resources** tab. |
| 76 | + |
| 77 | + <Message type="tip"> |
| 78 | + You can use the following code snippet to calculate the LLA: |
| 79 | + |
| 80 | + ``` |
| 81 | + bash-5.2$ mac_to_ipv6_ll() { |
| 82 | + IFS=':'; set $1; unset IFS |
| 83 | + echo "fe80::$(printf %02x $((0x$1 ^ 2)))$2:${3}ff:fe$4:$5$6" |
| 84 | + } |
| 85 | + ``` |
| 86 | + <br/> |
| 87 | + Example usage and output for a MAC address of `02:00:00:23:e4:01`: |
| 88 | + |
| 89 | + ``` |
| 90 | + bash-5.2$ mac_to_ipv6_ll 02:00:00:23:e4:01 |
| 91 | + fe80::0000:00ff:fe23:e401 |
| 92 | + ``` |
| 93 | + </Message> |
| 94 | + |
| 95 | +2. Ping the LLA. Ensure that you specify which interface to ping over (the Private Network) by adding the `%interface` zone index to the end of the ping command. For example, for a LLA of `fe80::0:0ff:fe1c:d9b` and a Private Network interface name of `ens5`, use the following command: |
| 96 | + |
| 97 | + ``` |
| 98 | + ping -6 fe80::0:0ff:fe1c:d9b%ens5 |
| 99 | + ``` |
| 100 | + |
| 101 | + <Message type="tip"> |
| 102 | + The interface name depends on the Instance type and OS. You can use the following command to get a compact summary of all network interfaces on your Instance: |
| 103 | + |
| 104 | + ``` |
| 105 | + ip -brief -color addr show |
| 106 | + ``` |
| 107 | + </Message> |
| 108 | + |
| 109 | + A successful ping will show results similar to the following: |
| 110 | + |
| 111 | + ``` |
| 112 | + PING fe80::0:0ff:fe1c:d9b%ens5 (fe80::ff:fe1c:d9b%ens5) 56 data bytes |
| 113 | + 64 bytes from fe80::ff:fe1c:d9b%ens5: icmp_seq=1 ttl=64 time=1.27 ms |
| 114 | + 64 bytes from fe80::ff:fe1c:d9b%ens5: icmp_seq=2 ttl=64 time=0.652 ms |
| 115 | + 64 bytes from fe80::ff:fe1c:d9b%ens5: icmp_seq=3 ttl=64 time=0.632 ms |
| 116 | + --- fe80::0:0ff:fe1c:d9b%ens5 ping statistics --- |
| 117 | + 3 packets transmitted, 3 received, 0% packet loss, time 2042ms |
| 118 | + rtt min/avg/max/mdev = 0.632/0.850/1.266/0.294 ms |
| 119 | + ``` |
| 120 | + |
| 121 | + This response suggests the Instance is attached to the Private Network, but has lost its IPAM-provided IPv4 and IPv6 addresses. There could be a configuration issue on the Instance, such as DHCP client issue, a problem with `iptables` rules, or another parameter you may have manually altered. |
| 122 | + |
| 123 | + You can connect to your Instance via SSH using the LLA, to take control and attempt to fix the issue. |
| 124 | + |
| 125 | + If you do not believe you have modified any parameters affecting the Instance's DHCP or IP configuration over the Private Network, open a support ticket providing the full output from all of the above tests. |
0 commit comments