In this article, I will just talk about a few commands I find useful for different situations. Also, I'm currently a Windows user so I might not dive deep into their variation on different OS.
1. Ping
ping [IP address or domain name]
You can basically use ping with either IP address or domain name (ping will check on the DNS system behind the scene). By default, at least in Windows, ping will send 4 requests to the destination and tell you if any of the packets is lost on the way. If there is none, that means the server is still up and running (and your internet connection is running smoothly).
My Use Case: Basically, I would use this to check whether the destination server is up or not, but make sure that your internet connection is not down too.
2. Telnet
As ping works at the network level, it won't know about the concept of port which is at the session layer. So telnet comes to the rescue.
telnet [IP address or domain name] [port]
As you know, any server can specifically allow only the desired port for security purposes. For instance, you might be able to ping to an address like xxx.xxx.x.x, but the destination might not allow you to connect to its port 8080 (supposedly say that 8080 is its Spring Boot server port). So if you need to work on any specific port, always telnet to check it first. Perhaps the problem might not come from your side.
My Use Case: Sometimes when you get an integration work you might need your client's IT or security team to allow you to access some of their specific service which is running on a specific port. You could use telnet to check whether they have allowed you to access it already or not.
The process could take a few minutes, but mostly because the destination is not contactable and after a while you'll get this message.
On the other hand, if the port is open you will almost get a response immediately and the successful response will result in a blank screen showing up which means the port is open and you could connect to it.
However, unlike ping, telnet isn't available by default on any OS (as far as I know).
In Windows, you have to turn it on by going to Control Panel > Programs > Programs and Features then, on the sidebar, select Turn Windows features on or off.
A new window will be opened, just scroll down until you find 'Telnet Client'. Make sure you check that box then click OK. Now, you will be able to use telnet on your command prompt or any other CLI.
If you're a Mac OS user, just install it using your Homebrew.
brew install telnet
3. Trace Route
As the name suggests, this command will trace the router in the path to a given destination and back so it tells us more information than ping. It's like pinging each router on the way to the destination instead of just the destination itself.
TraceRoute is available by default in both Windows and Mac OS (but not in Linux) though with a different command. It's tracert in Windows but traceroute in Mac OS.
tracert [IP address or domain name]
So you could use these commands to troubleshoot some problems, like bottlenecks in which you could pinpoint the router that cause the problem. You might need some domain knowledge here, since you have to know who is responsible for each address. It might be your VPN provider, your partners, your client or whoever.
The point is, with this command, you can pinpoint that there is something wrong that causes packet loss along the way and now you know that you should get some network engineer to look into this.
My Use Case: It's quite confusing, but there was once a time I can't connect to my client's internal database although I can telnet to that database port. I thought there was something wrong with my database connection string. It turned out that there was a problem with the path on the way back. I mean, to access that internal DB, I have to go through remote access with VPN proxy and pass through some partners' routers then land on the client's LAN which works out perfectly and result in a successful telnet response. However, on the way back, some client's IT guy configures it so that it will use a different path on the way back and some routers on that path have firewalls that didn't allow me yet. That's why I can telnet just fine, but still can't connect to the DB which I can successfully sign in, but failed to handshake with it due to the obstructed routing path on the way back.
For further knowledge about trace route, you might find this article useful How to Read a Traceroute - InMotion Hosting Support Center
These are the basic commands I find useful in daily work. I believe you could learn more related flags elsewhere. I just want to give a vivid picture of how these can be useful in your line of work as a developer. I hope you find it somehow useful. Till next time.
Top comments (0)