If you cannot connect to the internet at work, you cannot send emails, access files, or do your job, and your boss will assume you are not working. This chapter is about understanding the invisible chain of events that happens when your computer talks to another computer, and learning how to diagnose why that chain breaks. For the LFCS exam, you must know the standard tools and commands to check each link in that chain, from your own network card to the remote server.
Jump to a section
A simple way to picture Network Services and Connectivity Troubleshooting
The Front Desk Receptionist at a busy office building. This person manages all incoming and outgoing communication for the entire floor. When a delivery person arrives with a package for someone in the building, the receptionist checks a directory, finds the correct office number, and either calls the recipient to come down or arranges for the package to be brought up. If the delivery person has the wrong address, the receptionist politely tells them they have the wrong building. If the phone rings, the receptionist answers, listens to the request, and connects the caller to the correct extension. If the line is busy, the receptionist takes a message. If the network cables in the building are the physical phone lines and mail slots, the receptionist is the DNS server, translating a name like 'Bob in Accounting' into the correct internal extension. They are also the router, deciding which path a phone call or package should take to reach its destination efficiently. When something goes wrong — a caller says they can't get through, or a package never arrives — the receptionist is the first person you ask. They check the call log, see if the line was busy, confirm the package was signed for, and trace the path of the communication. This is exactly what troubleshooting network services and connectivity means: checking each step of the communication path, from your computer's request all the way to the server's response, and finding where the chain broke. The receptionist doesn't build the building or lay the phone cables, but they are the expert on how the communication system is supposed to work and where it fails.
Imagine you want to visit a friend's house in a city you have never been to before. First, you need your friend's exact street address. In networking, that address is an IP address, a unique number assigned to every device on a network. But humans are bad at remembering numbers, so we use names like 'google.com'. The system that translates these names into IP addresses is called DNS, which stands for Domain Name System. You can think of it as the phone book of the internet. When you type a website name into your browser, your computer asks a DNS server to look up the IP address.
Once your computer knows the IP address, it needs to figure out how to get there. It checks its own routing table, which is like a map of the local neighbourhood. If the destination is on the same local network, your computer sends the request directly. If it is outside your local network, the request goes to your default gateway, usually your home router. The router acts like a post office sorting facility: it reads the destination address and decides which road to send the data down next. Each data packet, which is a small chunk of information, hops from router to router until it reaches the destination.
This process relies on several services running on the machines involved:
DHCP (Dynamic Host Configuration Protocol): When you plug your computer into a network, DHCP automatically gives it an IP address, a subnet mask (which defines your local network size), and the address of the default gateway and DNS server. Without DHCP, you would have to type these numbers in manually.
ARP (Address Resolution Protocol): On a local network, devices don't talk to each other using IP addresses directly. They use a hardware address called a MAC address, which is burned into your network card. ARP is the protocol that asks 'Who has this IP address?' and gets the answer 'I do, and here is my MAC address.' It is like asking a classroom 'Who is John?' and someone raises their hand.
ICMP (Internet Control Message Protocol): This is the protocol used by the ping command. It sends a small message to a remote computer asking 'Are you there? If so, please send a reply back.' It is the simplest way to check if a remote machine is reachable and how long the round trip takes.
When something goes wrong, the problem could be at any of these layers. For example, if you cannot reach google.com: 1. Check your own network interface: Is your computer actually connected to the network? The command 'ip a' shows your network interfaces and their IP addresses. If your interface shows no IP address, DHCP might have failed. 2. Check connectivity to your gateway: Use 'ping' on your default gateway IP. If that fails, the problem is local — your cable, your switch port, or your router. 3. Check DNS: Use 'nslookup google.com' or 'dig google.com' to see if DNS can resolve the name. If this fails, DNS is broken. If it succeeds, you get an IP address back. 4. Check the path: Use 'traceroute' (or 'tracepath' on some systems) to see the exact route your packets take. This shows each router hop. If the path stops at a certain hop, that router is either down or blocking your traffic. 5. Check the remote server: Use 'curl -I http://google.com' to see if the web server responds with an HTTP header. If ping works but curl fails, the problem is at the application layer — the web service might be down but the machine itself is alive.
Troubleshooting tools also include: - 'ss' or 'netstat': Shows open network connections and listening services on your machine. This tells you if your local web server is actually running and waiting for connections. - 'iptables' or 'nftables': Firewall rules that can block or allow traffic. If you can ping from the server but not to the server, a firewall might be blocking incoming connections. - 'tcpdump': Captures all network traffic passing through an interface. This is the most powerful tool, letting you see exactly what packets are being sent and received.
Each of these tools checks a specific layer of the network stack. The key principle is systematic elimination: start at the bottom (physical connection) and work your way up (to application). Never guess — always verify with a specific command.
Check Local Network Interface
Run 'ip a' to see all network interfaces. Verify that your ethernet or wifi interface has an IP address assigned and is in the 'UP' state. If the interface is 'DOWN', use 'sudo ip link set <interface> up' to bring it up. If there is no IP address, run 'sudo dhclient <interface>' to request one from DHCP. This step confirms your machine is correctly connected to the local network.
Check Connectivity to Default Gateway
Run 'ip route' to find your default gateway IP. Then ping that IP using 'ping <gateway-ip>'. If you get replies, your machine can talk to the router and the local network is working. If you get 'Destination Host Unreachable', the problem is between your machine and the router — check cables, switch ports, or the router itself.
Test DNS Resolution
Use 'dig google.com' or 'nslookup google.com' to see if your system can resolve the hostname to an IP address. If the command returns an IP address, DNS is working. If it says 'connection timed out; no servers could be reached', your DNS server is unreachable or misconfigured. Check /etc/resolv.conf to see which DNS servers your system is using.
Check Path to Remote Destination
Run 'traceroute <ip-or-hostname>' to see the route your packets take to the destination. Each line is a router hop. If you see stars (* * *) or '!H' for a particular hop, that router is not responding to traceroute, or it has no route back to you. This helps pinpoint where the connection is failing in the wider network.
Verify Remote Service is Running
Use 'curl -I http://<ip-or-hostname>' for web servers, or 'telnet <ip> <port>' for any TCP service. If you get a response, the service is reachable and running. If the connection is refused or times out, but ping works, the specific service is either not running, blocked by a firewall, or listening on a different port. Check with 'ss -tuln | grep <port>' both on your machine and the remote machine.
You are the sole IT administrator for a small company with fifty employees. The sales team reports that they cannot access the company's customer relationship management (CRM) web application, which is hosted on an internal server in the server room. They get an error in their browser saying 'cannot reach this page'. Your job is to find and fix the problem.
Step one: You walk to a desk on the sales floor and open a terminal. You run 'ip a'. You see the workstation has an IP address of 192.168.1.42, which looks correct for the local network. This confirms the network cable is plugged in and DHCP worked. Next, you ping the default gateway, which is 192.168.1.1. You get replies successfully, so the workstation can talk to the router. The local network is fine.
Step two: You try to ping the CRM server itself. You know its IP address is 192.168.1.50 because you set it up last month. You run 'ping 192.168.1.50' and get no response — 'Destination Host Unreachable'. This tells you the problem is between the workstation and the server, but both are on the same subnet. You run 'arp -n' to see if the workstation knows the MAC address of the server. The ARP table shows an entry for 192.168.1.50 with an incomplete MAC address. This means the ARP request went out but got no reply. The server is either powered off or the network cable is unplugged.
Step three: You walk to the server room. The CRM server is powered on and has lights on its network port. You plug a monitor and keyboard into the server. You log in and run 'ip a'. The server shows no IP address assigned to its ethernet interface. The interface says 'state DOWN'. You run 'sudo ip link set eth0 up' to bring the interface up. Then you run 'sudo dhclient eth0' to request a new IP address from DHCP. The interface now gets an IP address of 192.168.1.50. You run 'systemctl status httpd' to check the web server service — it is running.
Step four: You go back to the sales desk. You ping 192.168.1.50 and get replies. You open a browser and the CRM loads perfectly. The problem was that the server's network interface had been disabled, likely after a power fluctuation or an accidental command.
This real-world scenario shows the step-by-step approach: check local interface, check gateway, check DNS (not needed here since you used an IP), check target machine, check the service itself. Using the right tool at each step, in the right order, is the difference between a ten-minute fix and an hour of frustration.
The LFCS exam specifically tests your ability to use command-line tools to diagnose network issues. You will not be asked to configure a network from scratch; you will be given a scenario where something is broken, and you must choose the correct command to identify the problem or fix it.
The exam loves these exact topics:
Checking network interface configuration: 'ip a' and 'ip link'. They will ask what command shows the MAC address of your ethernet card. The answer is 'ip a' — look for 'link/ether'.
Checking the routing table: 'ip route'. They may give you a scenario where a computer cannot reach the internet but can reach local devices. The cause is a missing or incorrect default gateway. The command to see the default gateway is 'ip route' and look for 'default via'.
DNS resolution: 'dig' and 'nslookup'. They often ask: 'A user can ping 8.8.8.8 but cannot ping google.com. What is the most likely problem?' Answer: DNS resolution failure. The tool to confirm is 'dig google.com'.
Checking listening ports: 'ss -tuln'. This shows all TCP and UDP ports that are currently listening for connections. A common trap: they say 'the web server is running but users cannot connect'. You check 'ss -tuln' and see that port 80 is not listed. The web server process might be running but listening on a different port (for example, 8080) or not at all.
Firewall rules: 'iptables -L -n' or 'nft list ruleset'. If a service is running and listening but still unreachable, the firewall is often blocking traffic. They will test whether you know how to list rules and add a rule to allow traffic on a specific port.
Connectivity testing: 'ping', 'traceroute', 'curl'. They will ask: 'What is the first command to check if a remote server is reachable?' The answer is ping. They will ask: 'What command checks the path packets take to a destination?' Answer: traceroute.
Common traps on the exam:
They give an error message like 'ping: connect: Network is unreachable'. This means the machine has no route to the destination, not that the destination is down. The cause is a missing default gateway.
They say 'DNS works fine, but the website still doesn't load'. The trap is confusing DNS resolution with web service availability. You need 'curl' to check the web server, not 'ping'.
They ask about the difference between 'ping' and 'traceroute'. Ping checks reachability; traceroute shows the path and where it breaks.
Key definitions to memorise: - 'localhost' or 127.0.0.1: The loopback address, always refers to your own machine. - Netmask: Defines which part of an IP address identifies the network and which part identifies the host. - Default gateway: The router that sends traffic to destinations outside the local network. - DNS resolver: The component on your system that performs DNS lookups, configured in /etc/resolv.conf.
Always start troubleshooting from the bottom of the OSI model: check physical connection, then local IP, then gateway, then DNS, then the remote server.
The 'ip a' command shows your network interfaces, their IP addresses, and their MAC addresses — it is the first command to run when diagnosing connectivity issues.
Ping uses ICMP and tests basic IP connectivity, but a successful ping does not mean a web server or other application service is running.
DNS translates human-readable hostnames into IP addresses; use 'dig' or 'nslookup' to test it, never rely on ping to a hostname as a DNS test.
The 'ss -tuln' command lists all TCP and UDP ports on which your machine is listening for connections — essential for verifying that a service is actually bound to the correct port.
A firewall can block traffic even if the service is running and the network is fully connected; use 'iptables -L -n' or 'nft list ruleset' to inspect firewall rules.
The default gateway is the router that sends traffic to destinations outside your local subnet; check it with 'ip route' and look for 'default via'.
Always verify with a specific tool for the specific layer — do not assume one tool tests everything.
These come up on the exam all the time. Here's how to tell them apart.
Ping
Tests basic reachability using ICMP echo requests.
Provides round-trip time statistics.
Does not show the path or intermediate routers.
Traceroute
Shows each router hop along the path to the destination.
Uses increasing TTL values to discover each hop.
Can identify exactly where packets are being dropped or delayed.
nslookup
Older DNS lookup tool, still widely available.
Returns simpler output with less detail.
Often uses the system's resolver library, which may be affected by local configuration.
dig
Newer, more feature-rich DNS lookup tool.
Returns detailed information including query time, authoritative servers, and TTL values.
Allows specific query types like A, MX, or NS records.
ifconfig (deprecated)
Legacy command from the net-tools package.
Does not show all information on newer kernels.
Replaced by the ip command in modern distributions.
ip a (modern)
Part of the iproute2 package, current standard.
Shows comprehensive interface information including MAC address, MTU, and state.
Supports all modern network features like namespaces and VRF.
Mistake
Ping is the only tool you need to check if a remote server is working.
Correct
Ping checks ICMP reachability, but a server can respond to ping while its web service is down. You must use application-specific tools like curl or telnet to check the actual service.
Beginners think ping is a universal health check because it is simple and always taught first. They don't understand that firewalls can block ICMP while allowing HTTP, or that a server can be up but its web server process can be crashed.
Mistake
If you can ping a host by IP address, DNS is working correctly.
Correct
Ping does not use DNS if you provide an IP address. To test DNS, you must resolve a hostname using nslookup or dig. Ping by IP works even if DNS is completely broken.
People think ping somehow 'tests' everything because it gives a success/failure message. They don't realise that ping with an IP address bypasses the DNS system entirely.
Mistake
A firewall always blocks all traffic unless you explicitly allow it.
Correct
Firewalls have a default policy. It might be 'allow all' or 'deny all'. You have to check the default policy and the rules. A common default is to allow outgoing traffic but deny incoming traffic.
Beginners hear 'firewall' and assume it blocks everything. In many Linux distributions, the default firewall policy allows all traffic until you start adding rules. Conversely, some security-hardened systems have a default deny policy.
Mistake
If a network cable is plugged in, the interface is definitely working.
Correct
The cable can be physically plugged in but the interface can be administratively down ('ip link set eth0 down'), or the cable itself can be faulty. You must check the interface state with 'ip link' to see if it is UP.
People trust physical connectivity too much. The link light on a network card can be on even if the operating system has disabled the interface. They don't think to check the software state.
Mistake
Traceroute stops at a router that is blocking traffic, so that router must be the problem.
Correct
Traceroute works by sending packets with increasing TTL values. Some routers are configured to not send back the ICMP responses that traceroute relies on, so a hop shows as '*' even though traffic passes through fine. The problem could be later in the path.
Beginners see a star and immediately blame that hop. They don't understand the mechanics of how traceroute works and that routers can be configured to be invisible to traceroute but still forward traffic normally.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Ping simply checks if a remote host is reachable and measures the round-trip time. Traceroute shows the exact path your packets take through each router hop, so you can see exactly where the connection is slow or broken.
You can reach the internet by IP, so your network and gateway are fine. The problem is DNS — your system cannot translate 'google.com' into an IP address. Check your DNS configuration with 'dig google.com' or look at /etc/resolv.conf.
Use 'ss -tuln'. This shows all TCP and UDP ports that are currently listening for connections, along with the IP address they are bound to. The '-t' flag shows TCP, '-u' shows UDP, '-l' shows listening sockets, and '-n' shows numeric addresses and ports.
It means your machine cannot find a route to the destination. Either the destination does not exist on the local network, or your machine has no default gateway configured to send traffic outside the local network. Check your routing table with 'ip route'.
First check if the port is listening with 'ss -tuln'. If it is listening but you still cannot connect from another machine, list your firewall rules with 'sudo iptables -L -n' or 'sudo nft list ruleset'. Look for rules that drop or reject traffic on that port.
The loopback address is 127.0.0.1, and it always refers to your own machine. It is useful for testing services locally: if you run 'ping 127.0.0.1' and it works, your network stack is functioning at a basic level, even if your physical network interface is down.
You've finished Network Services and Connectivity Troubleshooting. Continue through the LFCS study guide to build a complete picture of the exam.
Done with this chapter?