Networking Commands

When a network misbehaves — a site won't load, a service is unreachable, traffic is going somewhere it shouldn't — these commands are how you find out what is actually happening. They are the stethoscope of the security analyst: cheap, built into almost every operating system, and precise. Each one answers a different question. ping asks *is that host alive?* ip addr and ipconfig ask *what is my own address?* ss and netstat ask *what is connected and what ports are open?* dig and nslookup ask *what IP does this name resolve to?* traceroute asks *what path does my traffic take?* And arp asks *who are my neighbors on this local network?* Learning to read their output is a defensive skill: the same tools that help you troubleshoot also let you spot a rogue listening port, an unexpected DNS answer, or a suspicious device on your subnet.

ping sends an ICMP echo request and waits for an echo reply. A reply means the host is up and reachable, and the round-trip time (RTT) tells you how fast the link is. No reply can mean the host is down, unreachable, or simply configured to ignore ICMP — many firewalls silently drop pings, so "no reply" is not proof a host is offline. On Linux ping runs forever until you press Ctrl+C; on Windows it sends 4 packets and stops.

Before you can diagnose anything you need to know your own network identity: your IP address, subnet mask, default gateway, and DNS servers. On Windows that is ipconfig. On Linux the old tool is ifconfig (deprecated but still common), and the modern replacement is the ip command — ip addr for addresses, ip route for the routing table, ip link for interfaces.

Every listening port is a door into the machine, so knowing which ports are open — and which programs own them — is core to defense. netstat is the classic tool; ss ("socket statistics") is the modern Linux replacement, faster because it reads socket data straight from the kernel. The most useful view is listening sockets: services sitting open, waiting for a connection. An unexpected listener is a red flag worth investigating.

The Domain Name System turns names like google.com into IP addresses. DNS runs on port 53. nslookup is available on every OS and is fine for quick checks. dig ("domain information groper") is the analyst's favorite on Linux/macOS: it shows the full query, the answer section, which server replied, and record types like MX (mail), NS (name servers), TXT, and PTR (reverse). Comparing what DNS *returns* against what you *expect* is how you catch DNS tampering or misconfiguration.

traceroute (Linux/macOS) and tracert (Windows) reveal every router hop between you and a destination. They work by sending packets with a deliberately small TTL (time-to-live) that increases by one each round: the first hop replies when TTL hits zero, then the second, and so on, until the packets reach the target. The result is a map of the route your traffic takes and where latency or loss appears. A row of * * * means a hop did not reply within the timeout — often a router configured to stay silent, not necessarily a failure.

Inside a single local network, machines actually deliver frames using MAC addresses (Layer 2), not IP addresses (Layer 3). The Address Resolution Protocol bridges the two: it maps an IP address to the MAC address that currently holds it, and caches the result in the ARP table. arp -a shows that table — a quick inventory of the devices your machine has recently talked to on the local segment. On modern Linux the successor command is ip neigh.

Every command on this page either stays entirely inside your own computer, or sends real packets out onto the network — and those are two very different situations for anyone watching. The table below rates each command's visibility to a network admin, a firewall or IDS, the destination host, a DNS resolver, or anyone else on the path your traffic takes.

These are the tools on the other side of the conversation — what a network administrator or defender runs to see what's happening on devices and networks they are authorized to monitor. Where the commands above answer *is this one host reachable?*, these answer *what is happening on my network right now?*

None of this puts your own machine on the network in a new way. ss, netstat, lsof, ip -s link, and the PowerShell cmdlets all read state the kernel already has — no different from the commands earlier on this page. tcpdump, tshark, iftop, nethogs, and pktmon are passive listeners: they read packets already arriving at your network card, so watching does not itself create outbound traffic another host or IDS could see. What they DO need is administrator or root privileges, because reading raw packets is treated as a privileged operation by the OS. On a switched network you generally only receive traffic addressed to your own machine plus broadcasts — capturing someone else's unicast traffic takes additional access, like a mirrored switch port, that a legitimate administrator sets up on purpose, not something you can casually add yourself.

Using network-diagnostics.txt, answer each question by reading the output of the command it names. grep with the right word pulls each answer out fast. 1. From the ip route output: what IPv4 address does this lab computer have (the src address), and what is its default gateway? 2. From the ping -c 5 to portal.kestrelvalley.test: what percentage of packets were lost, and which icmp_seq number never got a reply? 3. From the dig ... MX output: a mail server with a lower MX preference number is tried first. Which mail server is tried first for kestrelvalley.test? 4. From the traceroute output: how many numbered hop lines are listed, counting the destination itself, and which hop number did not answer? 5. From the arp -a output: one IP address other than the gateway shows the same MAC address as the gateway. Which IP address is it? ( grep ' at ', awk '{print $4}', sort, uniq -d, then grep the MAC ) Bonus: run the same read-only commands on your own machine, on a network you are allowed to use, and compare.