- Home /
- Resources /
- Learning center /
- Network Path Troub...
Network Path Troubleshooting with Linux
Learn the tools for network troubleshooting on Linux with Equinix Metal, from basic IP configurations to advanced routing diagnostics

On this page
Networking can be tricky. Plugging a bunch of boxes into other boxes is easy enough, but actually getting the right bits to flow from the right computers across the wilds of the internet and end up at the right destination, pointed to the correct port that’s open and listening for traffic, gets really complicated really fast. At the interconnect speeds Equinix can provide, you may run into some unfamiliar network behavior.
This guide will provide you with a solid foundation of network troubleshooting on Linux. While this is generically useful for anyone sending bits between servers, the focus will be on troubleshooting connections between you (or your data center) and Equinix. Even if this doesn’t solve your problems, you’ll be able to provide all the information needed to our customer success team to get you the rest of the way there.
Prerequisites
- An Equinix Metal Account with access to machines in question
- A local Linux system (some tools may require root/sudo access)
- Optionally, the Metal CLI tool
IPv4 and IPv6
Since we’re talking about networks, we’re going to be dealing with IP addresses. You’re likely familiar with these numbers from daily use, but having a little deeper understanding will help with figuring out where things are going wrong. For the most part, everything we’ll be dealing with uses the long-standing IPv4 format.
IPv4
In IPv4, any network connected device is given a unique identifier usually referred to as an IP address. IP stands for internet protocol and refers to a standard protocol used in networking connectivity. IP addresses consist of 32 bits, usually portrayed as four octets in dot-decimal notation (xxx.xxx.xxx.xxx). Any given IP address can be divided into two halves, the first set of bits being the network portion of the address and the remainder representing the host portion. This is represented in either CIDR (Classless Inter-Domain Routing) notation or by use of a subnet mask, the former just listing how many bits are used by the latter. For example, let’s say you have an IP from Equinix of 55.82.200.45/29. You can work backwards to determine the proper subnet mask and the other IP addresses available in that block. With 29 bits (/29) dedicated to the network, that means you have 3 host bits, resulting in a subnet mask of 255.255.255.248 (11111111.11111111.11111111.11111000 in binary). And with a bit of binary conversion you can tell that the 8 available IPs are going to be 55.82.200.40-48. Out of these, the very first (all 0s) host is usually reserved for the “network” address and the very last (all 1s) host being reserved for the network “broadcast” address. That’s probably a bit deeper than this guide needs to go.
The main takeaway from breaking down the 55.82.200.45/29 address is that the device with that IP will treat any addresses between 55.82.200.40 and .48 as local to it, only forwarding requests outside of said network to its default gateway or router. What is a gateway, though?
People tend to think of the internet as “one large network,” but that is slightly inadequate. Actually, the internet is more like huge amount of small networks joined together. Every network segment with connectivity to other networks on the internet is assigned a autonomous system number, also referred to as an AS number or ASN. ASNs are used by routers to announce to all other routers on the internet what IP address ranges they are responsible for. When a computer on network A needs to talk to a computer on network B (or any computer that is not part of its own local network), it will forward its request to the locally configured router, usually also referred to as a gateway or default gateway. The gateway will forward the packets to the router that has announced its public responsibility for the network that the target host’s IP address belongs to.
The path a packet needs to take to make it from its source to its target is usually referred to as a route. Your system will usually only know the route to its default gateway, from which routing will happen mostly dynamically based on the worldwide routing tables. This allows any arbitrary host in any subnet of the internet to communicate with any other arbitrary host, in general. (We're leaving out special cases such as firewalls for the sake of simplicity.)
So if you’re having trouble sending data from 55.82.200.45 to 55.82.200.46, you may need to check that they’re properly connected to the same network, or check their subnet masks to make sure each computer has a proper picture of its network connections. If those tests pass, checking for a problem with the gateway connectivity is the next logical step.
IPv6
As you might know, with a 32-bit number representing all devices on the internet, we’d only have room for about 4.3 billion internet connected devices, fewer when you consider the number of reserved IPs for local networks. And while even 3 billion feels like a big number, it’s certainly not when you consider the world population and the sheer number of internet connected devices we all have and interact with daily. Further, with the way IP address blocks can be subdivided and moved around, routing tables can get crowded quickly. In fact, most regional authorities have been down to their final block of /8 (~16 million) IP addresses since 2015.
IPv6 has been introduced to alleviate this with 128-bit addresses, providing 2^128 or 3.4 x 10^32 available IP addresses, or “probably good enough for the foreseeable future.” And instead of a mutable subnet mask, IPv6 uses a set 64 bits for the host and network portions of the address. Envisioned with the original end-to-end nature of the internet in mind, IPv6 is routed a bit differently than IPv4 with different and slightly simpler demands from the router devices themselves and more work done on the end nodes. There are further differences between the two protocol versions, but the major difference for the purposes of this guide is notation.
While IPv4 is written as 4 decimal octets (groups of 8 bits or bytes) separated by dots or periods, IPv6 is written as 8 hexadecimal hextets (16-bit groups or chomps) separated by colons. For convenience and clarity, IPv6 also includes some rules about abbreviating: all leading 0s can be dropped in each hextet and consecutive hextets of all 0s can be replaced with two colons (::). The latter condition can only be applied once in an address as multiple uses would render the address vague and indeterminate.
For example, you might get the IPv6 address of 2001:0db8:0000:0000:0000:ff00:0042:8329. After removing the leading 0s you’d be left with 2001:db8:0:0:0:ff00:42:8329 and after compressing consecutive hextets of 0, we are left with 2001:db8::ff00:42:8329. Recognizing, expanding and abbreviating IPv6 addresses as well as remembering the 64-bits for network and 64-bits for host are the biggest implications for troubleshooting IPv6, for this guide.
Finding your machine’s IP address
You can find your server's IP address from either the Equinix Metal console or from the CLI.
Using the Equinix Metal Web UI
From within the Console, open Organization > Project > Servers > Server Hostname (IPV4/6 address).
Using the Equinix Metal CLI
If you're using the Metal CLI:
To get all assigned IP addresses:
metal devices get -o json | jq '.[0].ip_addresses'
To get IP addresses assigned to a specific device, use:
metal devices get -i $device_id -o json | jq '.ip_addresses'
Verifying Web UI / CLI information with your systems
Getting the IP addresses through the Equinix Metal console or CLI is useful, but sometimes you'll want to go directly to the source. These techniques will let you retrieve networking information on the machine itself.
Most of the following tools will be available on standard Linux installations. If not, all are available via your distribution’s package management (apt, snap, rpm).
Finding your IP address from the machine command line
To find the IP address from the command line, use the ip
command in one of the following variations:
ip a
ip add
ip addr
ip -br -c a
brief + colors
For instance, to generate a concise overview of all interfaces and assigned addresses, use:
# ip -br -c a
lo UNKNOWN 127.0.0.1/8 ::1/128
enp1s0f0 UP
enp1s0f1 UP
bond0 UP 139.178.69.191/31 10.88.19.129/31 2604:1380:1000:c00::1/127 fe80::ec4:7aff:feb2:98dc/64
For more information about the use of the ip
command, see one of the many online guides.
Determining which ports are listening
To get information about available ports, use the ss
command (socket statistics):
ss -l
ss -lp
(show process)
lsof -i
For instance, to see a list of all listening ports on your current machine, use:
# ss -lp
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.53%lo:domain 0.0.0.0:* users:(("systemd-resolve",pid=888,fd=12))
tcp LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:* users:(("systemd-resolve",pid=888,fd=13))
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* users:(("sshd",pid=1476,fd=3))
tcp LISTEN 0 4096 *:5201 *:* users:(("iperf3",pid=14162,fd=3))
tcp LISTEN 0 128 [::]:ssh [::]:* users:(("sshd",pid=1476,fd=4))
For a list of all currently opened file descriptors, use:
# lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 888 systemd-resolve 12u IPv4 20923 0t0 UDP localhost:domain
systemd-r 888 systemd-resolve 13u IPv4 20924 0t0 TCP localhost:domain (LISTEN)
sshd 1476 root 3u IPv4 27081 0t0 TCP *:ssh (LISTEN)
sshd 1476 root 4u IPv6 27083 0t0 TCP *:ssh (LISTEN)
sshd 1969 root 4u IPv4 27199 0t0 TCP metal-guide-00:ssh->123-123-100-10.sbcglobal.net:51434 (ESTABLISHED)
For more information about the ss
command, see this guide.
Determining whether a remote machine is reachable
To find out if a machine is available on the network, use the ping
command:
ping [address]
Beyond determining if a machine exists, you might also want to know how long it takes to reach that machine, also known as latency. The output from ping
will tell you that as well.
The following example shows reachability of the remote host packet.com with a latency of roughly one millisecond:
# ping packet.com
PING packet.com (104.18.26.66) 56(84) bytes of data.
64 bytes from 104.18.26.66 (104.18.26.66): icmp_seq=1 ttl=58 time=1.02 ms
64 bytes from 104.18.26.66 (104.18.26.66): icmp_seq=2 ttl=58 time=1.04 ms
64 bytes from 104.18.26.66 (104.18.26.66): icmp_seq=3 ttl=58 time=0.881 ms
64 bytes from 104.18.26.66 (104.18.26.66): icmp_seq=4 ttl=58 time=1.03 ms
For more information about ping
, see this guide.
Checking if a specific remote port is reachable
For checking an IP address, ping
is a great tool. To check a specific port on another machine, use nc
or netcat
, like this:
nc -vz [address] [port]
To figure out if equinix.com port 443 is reachable from your machine, use:
# nc -vz equinix.com 443
Connection to equinix.com 443 port [tcp/https] succeeded!
For more information about the nc
command, see this guide.
Checking if a specific remote port is reachable with more information
If you want more detailed information about the port status, use nmap
:
nmap -p [port] [address]
The same task performed using the nmap tool:
# nmap -p 443 equinix.com
Starting Nmap 7.80 ( https://nmap.org ) at 2022-03-01 03:51 UTC
Nmap scan report for equinix.com (40.91.78.229)
Host is up (0.023s latency).
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds
For more information about using nmap
, see this guide.
Determining the route to a specified address
As noted earlier, routes are dynamic, so you want to determine the exact route being used to a specific destination, using the mtr
command:
mtr [address]
mtr -r -c 10 [address] (-cycles)
The mtr
command can also tell you how many hops are contained in a given route, and whether one of them is slower than acceptable.
Here is the example output for one host, using an IPv6 IP, trying to reach another host.
metal-guide-00 (2604:1380:1000:c00::1) 2022-03-01T03:56:07+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. _gateway 0.0% 28 7.8 3.0 1.0 8.6 2.5
2. 0.ae147.dsr1.r00c02.sjc1.packet.net 0.0% 28 9.4 23.0 1.5 401.7 75.8
3. 0.ae11.bsr1.sjc1.packet.net 0.0% 28 17.5 2.4 0.7 21.2 4.8
4. 0.et-0-0-11.bsr1.sv5.packet.net 0.0% 28 1.5 4.4 1.3 40.5 9.2
5. 2001:4860:1:1::1d7f 0.0% 27 1.4 1.4 1.2 1.8 0.1
6. 2607:f8b0:82c2::1 48.1% 27 2.2 2.4 2.2 2.7 0.2
7. any-in-2001-4860-4802-36--15.1e100.net 0.0% 27 1.5 1.4 1.2 1.5 0.1
For more information about mtr
, see this guide.
Testing connection speed
Sometimes you'll want to test the speed of a connection directly. For that, you'll need to install the speedtest utility:
apt install speedtest-cli
You can then run the test with:
speedtest
To perform a speedtest on the CLI, use:
# speedtest
Retrieving speedtest.net configuration...
Testing from Packet Host (139.178.69.191)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Ayera Technologies, Inc. (Modesto, CA) [97.79 km]: 7.473 ms
Testing download speed................................................................................
Download: 1142.73 Mbit/s
Testing upload speed......................................................................................................
Upload: 1656.41 Mbit/s
For more information about the Speedtest CLI tool, see the official documentation.
Measuring the speed of transfer between two machines
You can test the transfer speeds between two machines with the iPerf utility. You'll need to install iperf
on both the local and remote machines:
apt install iperf3
On the remote server, to start listening, use:
iperf3 -s
On your local system use:
iperf3 -c [target address]
iperf3 -c [target address] -R
(in reverse, remote -> local)
The output could look like this:
# iperf3 -c 139.178.69.191
Connecting to host 139.178.69.191, port 5201
[ 5] local 192.168.0.233 port 52106 connected to 139.178.69.191 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 35.2 MBytes 295 Mbits/sec
[ 5] 1.00-2.00 sec 53.8 MBytes 451 Mbits/sec
[ 5] 2.00-3.00 sec 27.0 MBytes 227 Mbits/sec
[ 5] 3.00-4.00 sec 51.8 MBytes 435 Mbits/sec
[ 5] 4.00-5.00 sec 43.6 MBytes 366 Mbits/sec
[ 5] 5.00-6.00 sec 38.7 MBytes 324 Mbits/sec
[ 5] 6.00-7.00 sec 41.5 MBytes 348 Mbits/sec
[ 5] 7.00-8.00 sec 43.7 MBytes 367 Mbits/sec
[ 5] 8.00-9.00 sec 44.5 MBytes 373 Mbits/sec
[ 5] 9.00-10.00 sec 46.1 MBytes 386 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 426 MBytes 357 Mbits/sec sender
[ 5] 0.00-10.06 sec 424 MBytes 354 Mbits/sec receiver
iperf Done.
For more information about iPerf, see the official documentation.
Viewing network load by device
To get a broader view of the network load on each of your devices, use the nload
utility:
nload
Use the arrow keys to cycle through the available devices, and press q to quit.
Here is some example output from nload
:
Device bond0 [139.178.69.191] (1/5):
===========================================================================================
Incoming:
#####################
#####################
.#####################
######################
######################
######################
######################
######################
###################### Curr: 2.91 kBit/s
###################### Avg: 125.98 MBit/s
###################### Min: 2.90 kBit/s
###################### Max: 317.84 MBit/s
###################### Ttl: 1.20 GByte
Outgoing:
Curr: 30.23 kBit/s
. .. Avg: 1.01 MBit/s
################## Min: 7.57 kBit/s
###################| Max: 2.42 MBit/s
.#################### Ttl: 159.86 MByte
For more information about nload
, see this guide.
Determining the owner of a domain
When you have a remote address, and want to confirm the owner and other registrar information, use the whois
command:
whois [address]
The following example shows the whois information for the equinix.com domain:
# whois equinix.com
Domain Name: EQUINIX.COM
Registry Domain ID: 2603897_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.corporatedomains.com
Registrar URL: http://cscdbs.com
Updated Date: 2021-08-22T05:11:35Z
Creation Date: 1998-08-27T04:00:00Z
Registry Expiry Date: 2022-08-26T04:00:00Z
Registrar: CSC Corporate Domains, Inc.
Registrar IANA ID: 299
Registrar Abuse Contact Email: domainabuse@cscglobal.com
Registrar Abuse Contact Phone: 8887802723
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited
Name Server: DNS1.P07.NSONE.NET
Name Server: DNS2.P07.NSONE.NET
Name Server: DNS3.P07.NSONE.NET
Name Server: DNS4.P07.NSONE.NET
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2022-03-01T04:03:24Z <<<
For more information on whois
, use this guide.
Determining the address of a domain name
The whois
command is great when you want to know about a domain, but sometimes you want to know the specific address a domain name resolves to. For that, you use nslookup
, or for a more detailed answer, use dig
:
nslookup [address]
dig +trace [address]
An example using nslookup
:
# nslookup equinix.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: equinix.com
Address: 40.91.78.229
The same example using dig
:
# dig +trace equinix.com
; <<>> DiG 9.16.1-Ubuntu <<>> +trace equinix.com
;; global options: +cmd
. 79825 IN NS e.root-servers.net.
. 79825 IN NS d.root-servers.net.
. 79825 IN NS g.root-servers.net.
. 79825 IN NS a.root-servers.net.
. 79825 IN NS k.root-servers.net.
. 79825 IN NS b.root-servers.net.
. 79825 IN NS i.root-servers.net.
. 79825 IN NS m.root-servers.net.
. 79825 IN NS l.root-servers.net.
. 79825 IN NS h.root-servers.net.
. 79825 IN NS j.root-servers.net.
. 79825 IN NS c.root-servers.net.
. 79825 IN NS f.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20220313210000 20220228200000 9799 . l/Qi4jz9Mm/17YNIjJM8Z9vBxY2LNM4EwJykZsFLMXg8AnbJDxaAGB3h 47gGMj8mzTpTpgRrmD6ohAh/HOpbzR74YlQze6rVp+fn5oBZGzxKlVvW jVhm0L2vVCBwoilPJJ13sWdVYxBYJC4E1H23vT4khtzEUtjHdNnSbTbl GrFk3DDb6oIR5AhPQZII+zbYWPgLxJS7MJ20ch9ZXpby44IQ/0L+cgly Il/y84Ix/jq4qpfMexbxjTBWa9cK3S+vBIpWnxv4372lEFTiN6SPFYfF YCQVafKCnNZxWq3DIdwDNJcgcZS4ezCkm08Y4PZ/phfHBWHoFaqNMMpw BSY0cg==
;; Received 1199 bytes from 192.112.36.4#53(g.root-servers.net) in 44 ms
equinix.com. 172800 IN NS dns1.p07.nsone.net.
equinix.com. 172800 IN NS dns2.p07.nsone.net.
equinix.com. 172800 IN NS dns3.p07.nsone.net.
equinix.com. 172800 IN NS dns4.p07.nsone.net.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20220304052328 20220225041328 38535 com. QBEVp5RQYWO4WbeNlRYtAg+ob5TeMdT9lidq3zTL5xoEWS8N9xGXMhjx JEnRCkf8+yirdIyLZvIqzKqKtvzr2WXVLpEDdoUsfpj3xdG1VDPXNbva 9bSOgIcOnfv0IUXJJXHhsp80NDWeFYbwR+wJMeEwgrHWQfyccyUejjpU JKK+uBrBP3D7wvHpnNIh1XnFk4f49bhdJCj5/ITzZyjR0Q==
2S6MCLRVGJJO7EJTAFM73G5O7INU7C84.com. 86400 IN NSEC3 1 1 0 - 2S6NAQI4JCBDB8UF5NFPLETQ9GTHE3P6 NS DS RRSIG
2S6MCLRVGJJO7EJTAFM73G5O7INU7C84.com. 86400 IN RRSIG NSEC3 8 2 86400 20220307055325 20220228044325 38535 com. RlR6BsuGKh937/apIR6FtvvQZ47Gv3CXUx0XotbbCGD3EtwsJfxY5bxa Yv3b2HnU+DqL1SChUD2MBAKr0SzNeTSa726Ymy6P75QDM7iGA9ObRRPP 6FEtkfcNxDqXx52pBQpiIQfVhRklW+VoRGD4V54vyC6jSq/PaOSoWCFE tD71VC4mvCbaox5KKUHPn2F8WH5rLFPqoRmHcFuAV01POw==
;; Received 678 bytes from 192.41.162.30#53(l.gtld-servers.net) in 24 ms
equinix.com. 300 IN A 40.91.78.229
;; Received 56 bytes from 2a00:edc0:6259:7:7::4#53(dns4.p07.nsone.net) in 0 ms
For more information about the nslookup
command, see this guide.
For more information about the dig
command, see this guide.
Determining the local hardware configuration
To retrieve detailed information about what hardware is in the system, use the lshw
(list hardware) command:
lshw
lshw -class network
lshw -class network -short
Here is example output from lshw
, which will often look crowded and chaotic:
# lshw -class network
*-network:0
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
logical name: enp1s0f0
version: 01
serial: 0c:c4:7a:b2:98:dc
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.6.0-k duplex=full firmware=1.52, 0x800007ae latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s
resources: irq:16 memory:88400000-8847ffff ioport:e020(size=32) memory:88580000-88583fff memory:88500000-8853ffff memory:88584000-885a3fff memory:885a4000-885c3fff
*-network:1
description: Ethernet interface
product: I350 Gigabit Network Connection
vendor: Intel Corporation
physical id: 0.1
bus info: pci@0000:01:00.1
logical name: enp1s0f1
version: 01
serial: 0c:c4:7a:b2:98:dc
size: 1Gbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.6.0-k duplex=full firmware=1.52, 0x800007ae latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s
resources: irq:17 memory:88480000-884fffff ioport:e000(size=32) memory:885c4000-885c7fff memory:88540000-8857ffff memory:885c8000-885e7fff memory:885e8000-88607fff
*-network
description: Ethernet interface
physical id: 3
logical name: bond0
serial: 0c:c4:7a:b2:98:dc
capabilities: ethernet physical
configuration: autonegotiation=off broadcast=yes driver=bonding driverversion=3.7.1 duplex=full firmware=2 ip=139.178.69.191 link=yes master=yes multicast=yes
For more information about the lshw
command, see this guide.
Getting specific network card info
To determine more specific information about the network card and the driver used in a specific machine, use ethtool
:
ethtool [DEVICE NAME]
ethtool -i [DEVICE NAME]
For more information about ethtool
, see this guide.
Figuring out firewall rules
Many Linux distributions pre-deploy firewall rules or services such as firewalld
for basic system security. Those may get in your way when setting up networks. On Linux systems, packet filters are implemented using iptables
or nftables
, the latter being newer but having a compatibility interface to iptables
. Here is how to get a list of all applied rules:
iptables -S
Remember that both iptables
and nftables
follow the “first rule match” principle. That means that an incoming packet is dealt with according to the first matching rule.
Deprecated tools
You may be familiar with older networking utilities such as arp
, ifconfig
, or route
. These tools are now deprecated and succeeded by ip
. The netstat
tool is superceded by ss
.
Conclusion
This article has provided an overview of various tools available on Linux systems for troubleshooting networking issues. Although these tools may not solve every networking problem, it's always good to know where to get the proper information. If nothing else, having this info readily available will make support calls go faster.
You may also like
Dig deeper into similar topics in our archives
Crosscloud VPN with WireGuard
Learn to establish secure VPN connections across cloud environments using WireGuard, including detailed setups for site-to-site tunnels and VPN gateways with NAT on Equinix Metal, enhancing...

Kubernetes Cluster API
Learn how to provision a Kubernetes cluster with Cluster API

Kubernetes with kubeadm
Learn how to deploy Kubernetes with kubeadm using userdata

OpenStack DevStack
Use DevStack to install and test OpenStack on an Equinix Metal server.