- I tested Samsung's 98-inch 4K QLED TV, and here's why it might be worth the $13,000
- My favorite bone conduction headphones just got a waterproof upgrade - and they're very comfortable
- Bye bye, Wi-Fi: How to add a wired network to your home without running Ethernet
- Why I no longer recommend this Windows-like Linux distro
- How to buy Casio's tiny digital watch for your finger in the US this week
7 ways to look at network connections on Linux
Whether you’re managing a network at work or just watching out for your home systems, it’s important to understand your network connections–how you communicate with public systems and those on the local network. This article covers some of the most important commands available on Linux to help you get a clear understanding of your local network and how it reaches outside.
While the links provided include important tips on using network commands, some include commands that have been deprecated in favor of newer commands. Some of the most important commands to know today include ip a, ip neigh, ping, tracepath, dig, tcpdump and whois.
(If a command is deprecated, it doesn’t mean it doesn’t work or isn’t available. It means that the command has been replaced with a newer command that serves the same purpose and is likely better supported.)
ip a
The ip a command will provide information on your network interface. This includes your assigned IP address (even if assigned automatically) and the loopback address that is used when the system needs to communicate with itself, the benefit being that it remains stable where the assigned IP address may not always be the same.
The ip a command has largely replaced the deprecated ifconfig command. It provides the same variety of data, but in a different format. The output below shows the loopback (lo) address (127.0.0.1) and the system’s assigned (enp0s25) address (192.168.0.7).
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1d:09:77:9d:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.7/24 brd 192.168.0.255 scope global dynamic noprefixroute enp0s25
valid_lft 74857sec preferred_lft 74857sec
inet6 fe80::bb32:464a:77a3:acd7/64 scope link noprefixroute
valid_lft forever preferred_lft forever
The ip link command provides similar information, but less of it.
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:1d:09:77:9d:08 brd ff:ff:ff:ff:ff:ff
ip neigh
$ arp -a _gateway (192.168.0.1) at 1c:64:99:ec:b1:97 [ether] on enp0s25 ? (192.168.0.6) at b0:c0:90:3f:10:15 [ether] on enp0s25 ? (192.168.0.4) at 74:e2:0c:da:27:53 [ether] on enp0s25 ? (192.168.0.18) at cc:3d:82:39:78:85 [ether] on enp0s25 ? (192.168.0.22) at <incomplete> on enp0s25
$ ip neigh 192.168.0.1 dev enp0s25 lladdr 1c:64:99:ec:b1:97 STALE 192.168.0.6 dev enp0s25 lladdr b0:c0:90:3f:10:15 REACHABLE 192.168.0.4 dev enp0s25 lladdr 74:e2:0c:da:27:53 REACHABLE 192.168.0.18 dev enp0s25 lladdr cc:3d:82:39:78:85 REACHABLE 192.168.0.22 dev enp0s25 FAILED fe80::1e64:99ff:feec:b197 dev enp0s25 lladdr 1c:64:99:ec:b1:97 router STALE
The ip neigh command can provide even more detail about systems on your network including MAC address, and it supports removing IP addresses from your arp table.
ping
The ping command continues to be very useful by sending packets to another system to gather a response that shows that the system is up and reachable.
$ ping www.networkworld.com PING idg.map.fastly.net (146.75.30.165) 56(84) bytes of data. 64 bytes from 146.75.30.165 (146.75.30.165): icmp_seq=1 ttl=57 time=49.2 ms 64 bytes from 146.75.30.165 (146.75.30.165): icmp_seq=2 ttl=57 time=32.4 ms 64 bytes from 146.75.30.165 (146.75.30.165): icmp_seq=3 ttl=57 time=125 ms 64 bytes from 146.75.30.165 (146.75.30.165): icmp_seq=4 ttl=57 time=75.9 ms --- idg.map.fastly.net ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3000ms rtt min/avg/max/mdev = 32.388/70.534/124.680/34.892 ms
tracepath
The tracepath command follows in the footsteps of the traceroute command. It allows you to see the route that a system takes to reach a remote system and is often used in troubleshooting connection problems. If you use tracepath to check your connection to your local router, the response should be short and quick. Remote systems usually require more time as tracepath moves between links and often descends into a series of “no reply” messages as routers along the way may not respond with details.
The tracepath command defaults to a limit of 30 hops (connections between routers), but this can be increased using the -m options (e.g., tracepath -m 50).
$ tracepath 192.168.0.1
1?: [LOCALHOST] pmtu 1500
1: _gateway 3.503ms reached
1: _gateway 2.558ms reached
Resume: pmtu 1500 hops 1 back 1
$ tracepath world.std.com
1?: [LOCALHOST] pmtu 1500
1: _gateway 3.526ms
1: _gateway 4.212ms
2: _gateway 7.928ms pmtu 1492
2: 10.226.32.1 40.141ms
3: 10.17.1.29 50.127ms
4: 10.17.0.221 68.552ms
5: 10.17.0.226 45.820ms asymm 4
6: 10.25.0.137 54.701ms asymm 5
7: rest-b2-link.ip.twelve99.net 75.532ms asymm 6
8: rest-bb1-link.ip.twelve99.net 66.185ms asymm 9
9: ash-b2-link.ip.twelve99.net 73.287ms asymm 6
10: no reply
11: no reply
12: ae23.cs1.lga5.us.eth.zayo.com 81.707ms asymm 13
13: ae8.mpr3.bos2.us.zip.zayo.com 82.203ms asymm 10
14: 64.124.51.229.t495-rtr.towerstream.com 58.666ms asymm 12
15: 69.38.149.18 66.011ms asymm 13
16: 64.119.137.154 74.448ms asymm 14
17: world.std.com 112.248ms reached
Resume: pmtu 1492 hops 17 back 14
nslookup and dig
While the nslookup command is still well used, the dig command has largely replaced it and is considered a better choice. Here are some samples of the kind of output the dig command will provide:
$ dig world.std.com ; <<>> DiG 9.16.33-RH <<>> world.std.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62339 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;world.std.com. IN A ;; ANSWER SECTION: world.std.com. 7180 IN A 192.74.137.5 ;; Query time: 2 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Mon Dec 12 11:19:00 EST 2022 ;; MSG SIZE rcvd: 58
tcpdump
The tcpdump command can print out the headers of network packets as they reach your server or can be used with various filters to select just the packets you want to see. You can also save packets for later analysis. Acting as a sniffer, tcpdump can be a valuable troubleshooting tool.
whois
The whois command can find a lot of information about a domain. The output below is truncated but shows the kind of information you can expect to retrieve.
$ whois networkworld.com | head -8 [Querying whois.verisign-grs.com] [Redirected to whois.markmonitor.com] [Querying whois.markmonitor.com] [whois.markmonitor.com] Domain Name: networkworld.com Registry Domain ID: 293248_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.markmonitor.com Registrar URL: http://www.markmonitor.com
Testing upload and download speeds
The speedtest tool, which you likely will have to install, can be used to calculate your upload and download speed.
$ speedtest Retrieving speedtest.net configuration... Testing from Shentel Communications (204.111.9.197)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by Lumos Fiber (Waynesboro, VA) [112.99 km]: 33.642 ms Testing download speed................................................................ Download: 6.87 Mbit/s Testing upload speed.................................................................. Upload: 1.38 Mbit/s
Wrap-Up
Linux provides a lot of very useful commands for checking network settings and testing connectivity.
Copyright © 2022 IDG Communications, Inc.
