# Module 3

## Network Configuration and Troubleshooting

### 🎯 Learning Objectives

After completing this module, you will be able to:

- Configure static IP addresses using netplan
- Manage DNS resolver settings
- Diagnose network connectivity issues using diagnostic tools
- Verify network service status and port availability

Click Next → to begin.

## Linux Networking Architecture Overview

## Understanding Linux Network Stack

Linux networking operates through a layered architecture that handles everything from physical hardware to application protocols. At the foundation, network interface cards (NICs) connect your system to the network. The Linux kernel manages these interfaces through drivers, presenting them as logical devices you can configure and monitor.

Modern Ubuntu systems use netplan as the network configuration abstraction layer. Netplan simplifies network management by using YAML configuration files that are then rendered into configurations for the underlying network daemons—either NetworkManager for desktop systems or systemd-networkd for servers.

## Key Components of Linux Networking

The primary components you'll work with include:

- Network interfaces: Physical or virtual devices (eth0, ens33, wlan0)
- IP addressing: IPv4 and IPv6 addresses assigned to interfaces
- Routing tables: Rules determining how packets reach their destinations
- DNS resolution: Translation of hostnames to IP addresses
- Network services: Applications listening on specific ports

## The Role of systemd-resolved

Ubuntu uses systemd-resolved for DNS resolution, replacing the traditional `/etc/resolv.conf` approach. This service provides DNS caching, DNSSEC validation, and integration with modern network management tools. It maintains a stub resolver that applications use to perform name lookups efficiently.

Understanding this architecture helps you diagnose problems systematically, starting from the physical layer and working up through routing, DNS, and application-level connectivity.

Illustration showing the layered Linux networking architecture from hardware to applications

#### 💡 Key Takeaways

- Netplan abstracts network configuration into YAML files
- systemd-resolved handles modern DNS resolution
- Network interfaces are managed by the Linux kernel
- Understanding the layered architecture aids troubleshooting

## Network Interface Identification and Management

## Discovering Network Interfaces

The `ip` command is your primary tool for network interface management in modern Linux systems, replacing the older `ifconfig` utility. To view all network interfaces on your system, use:

    ip addr show

This displays detailed information including interface names, MAC addresses, IP addresses, and interface states (UP or DOWN). Modern naming conventions use predictable interface names like `ens33` (Ethernet), `wlp3s0` (wireless), or `enp0s31f6` (PCI-based Ethernet).

## Interface States and Information

Each interface has several attributes you need to understand:

- State: UP (active) or DOWN (inactive)
- MAC address: Hardware identifier (link/ether)
- IPv4 address: Shown with subnet mask in CIDR notation (e.g., 192.168.1.100/24)
- IPv6 address: Modern systems typically have multiple IPv6 addresses
- MTU: Maximum transmission unit size

## Viewing Routing Information

To see how your system routes network traffic, use:

    ip route show

This displays the routing table, including your default gateway—the router that handles traffic destined for networks outside your local subnet. The default route typically appears as `default via 192.168.1.1 dev ens33`.

## Link Layer Details

For hardware-level information, use:

    ip link show

This provides link-layer status without IP configuration details, useful for diagnosing physical connectivity issues before investigating higher-level problems.

Illustration showing a system administrator examining network interface information displayed on a terminal screen

#### 💡 Key Takeaways

- The ip command replaces older ifconfig utility
- Modern interfaces use predictable naming conventions
- Interface state, MAC, and IP information are critical for troubleshooting
- Routing tables determine packet forwarding decisions

## Netplan Configuration Syntax and Structure

## Understanding Netplan YAML Files

Netplan configuration files live in `/etc/netplan/` and use YAML syntax—a human-readable data format that relies on indentation. A typical configuration file is named `00-installer-config.yaml` or `01-netcfg.yaml`, with lower numbers processed first.

## Basic Configuration Structure

A netplan configuration follows this structure:

    network:
      version: 2
      renderer: networkd
      ethernets:
        ens33:
          dhcp4: false
          addresses:
            - 192.168.1.100/24
          routes:
            - to: default
              via: 192.168.1.1
          nameservers:
            addresses:
              - 8.8.8.8
              - 8.8.4.4

## Key Configuration Elements

Renderer: Specifies whether to use `networkd` (servers) or `NetworkManager` (desktops).

DHCP settings: `dhcp4: true` enables automatic configuration; `dhcp4: false` requires manual settings.

Addresses: IP addresses in CIDR notation as a list (note the dash).

Routes: The gateway router IP address for reaching external networks, specified with `to: default` and `via: <gateway_ip>`.

Nameservers: DNS server addresses for hostname resolution.

## YAML Syntax Requirements

YAML is strict about formatting:

- Use spaces only, never tabs
- Maintain consistent indentation (2 spaces per level)
- Lists use dash (-) followed by space
- Colons (:) require space after them

## Applying Configuration Changes

After editing netplan files, test your configuration:

    sudo netplan try

This applies changes with automatic rollback if you don't confirm. To apply permanently:

    sudo netplan apply

Illustration showing a YAML configuration file as a structured document with hierarchical organization

#### 💡 Key Takeaways

- Netplan uses YAML syntax with strict indentation rules
- Configuration files in /etc/netplan/ define network settings
- Always use 'netplan try' to test changes safely
- Both static and DHCP configurations are supported

## DNS Resolution and systemd-resolved

## How DNS Resolution Works in Ubuntu

Domain Name System (DNS) resolution translates human-readable hostnames like `google.com` into IP addresses that computers use for communication. Ubuntu uses systemd-resolved as the DNS resolver service, providing caching, DNSSEC validation, and per-link DNS configuration.

## The Stub Resolver Concept

systemd-resolved creates a stub resolver at `127.0.0.53` that applications query for DNS lookups. The service maintains a cache of recent queries, reducing latency and network traffic. It also integrates with netplan, automatically configuring DNS servers specified in your network configuration.

## Configuration Files and Locations

DNS configuration exists in several places:

Primary configuration: `/etc/systemd/resolved.conf` contains global DNS settings.

Legacy compatibility: `/etc/resolv.conf` is typically a symlink to `/run/systemd/resolve/stub-resolv.conf`.

Runtime state: `/run/systemd/resolve/resolv.conf` shows currently active DNS servers.

## Managing DNS Settings

To check DNS status:

    systemd-resolve --status

This displays current DNS servers, search domains, and DNSSEC status per interface. You can configure DNS servers in netplan (recommended) or directly in `resolved.conf`:

    [Resolve]
    DNS=8.8.8.8 8.8.4.4
    FallbackDNS=1.1.1.1

After editing `resolved.conf`, restart the service:

    sudo systemctl restart systemd-resolved

## Testing DNS Resolution

Verify DNS functionality with:

    ping www.google.com

This shows how the system resolves a hostname and confirms the response, including which DNS server provided the answer through successful IP connectivity.

Illustration showing DNS resolution process from hostname query to IP address response

#### 💡 Key Takeaways

- systemd-resolved provides DNS caching and resolution
- DNS servers are configured via netplan or resolved.conf
- The stub resolver at 127.0.0.53 handles application queries
- Use resolvectl to manage and test DNS configuration

## Network Connectivity Troubleshooting Tools

## The ping Command

`ping` is your first-line diagnostic tool for testing network connectivity. It sends ICMP echo requests and measures response time:

    ping -c 4 google.com

The `-c 4` flag limits output to 4 packets. Successful responses confirm:

- DNS resolution is working (if using hostname)
- Network path exists to destination
- Remote host is responding
- Basic latency metrics

If ping fails to a hostname but succeeds to an IP address (like `ping 8.8.8.8`), you have a DNS problem, not a connectivity issue.

## The traceroute Command

`traceroute` maps the path packets take to reach a destination:

    traceroute google.com

Each line shows a "hop"—a router along the path—with three response times. This identifies where connectivity breaks:

- Timeouts early in the path suggest local network problems
- Timeouts near the destination may indicate firewall blocking
- Increasing latency reveals network congestion points

## Using netstat for Connection Status

The `netstat` command displays network connections and listening ports:

    netstat -tuln

Flags mean:

- `-t`: TCP connections
- `-u`: UDP connections
- `-l`: Listening sockets
- `-n`: Show numeric addresses (skip DNS lookups)

This reveals which services are listening and on which ports, essential for troubleshooting service accessibility.

## The ss Command Alternative

`ss` is the modern replacement for netstat, offering faster performance:

    ss -tuln

Use `ss -tunap` to include process information, showing which application owns each connection.

Illustration showing network diagnostic tools in action, depicting the journey of network packets through multiple routers

#### 💡 Key Takeaways

- ping tests basic connectivity and measures latency
- traceroute maps the network path to identify failure points
- netstat and ss display connection states and listening ports
- Systematic tool use isolates problems to specific network layers

## Service Port Verification and Network Testing

## Understanding Network Ports and Services

Network services listen on specific TCP or UDP ports—numbered endpoints that identify different applications. Web servers typically use port 80 (HTTP) or 443 (HTTPS), SSH uses port 22, and DNS uses port 53. Verifying which ports are open is crucial for troubleshooting service accessibility.

## Using ss to Identify Listening Ports

The `ss` command shows detailed socket statistics:

    ss -tlnp

This displays TCP listening ports with process information. Look for:

- State: LISTEN indicates the service is waiting for connections
- Local Address: IP and port (0.0.0.0:80 means listening on all interfaces)
- Process: Which program owns the socket

## Testing Port Connectivity with netcat

Netcat (`nc`) tests whether you can reach a specific port:

    nc -zv 192.168.1.50 22

Flags:

- `-z`: Zero-I/O mode (just scan, don't send data)
- `-v`: Verbose output

Successful connection proves:

- Network path exists to the host
- Firewall allows the port
- Service is listening on that port

## Testing Remote Services

To test if a web server is responding:

    nc -zv google.com 443

Or send an actual HTTP request:

    printf "GET / HTTP/1.0\r\n\r\n" | nc google.com 80

## Firewall Considerations

If a service listens locally but isn't accessible remotely, check Ubuntu's firewall (ufw):

    sudo ufw status

Verify the required port is allowed:

    sudo ufw allow 22/tcp

Systematic port verification helps isolate whether problems lie in service configuration, firewall rules, or network connectivity.

Illustration showing network ports as numbered doors on a server building, with some open and accessible, others closed or blocked by a firewall wall

#### 💡 Key Takeaways

- Services listen on specific TCP or UDP port numbers
- ss command shows which ports are listening locally
- netcat tests remote port accessibility
- Firewall rules can block port access even when services are running

## 🔬 Configuring Static IP and Troubleshooting Network Connectivity

Objective: Configure a static IP address on an Ubuntu VM using netplan, modify DNS settings, and use diagnostic tools to verify network connectivity and troubleshoot common issues.

⏱ Estimated time: 45 minutes💻 Platform: Ubuntu Linux VM on VirtualBox (Windows host)
Prerequisites:

- VirtualBox installed on Windows computer
- Ubuntu 22.04 or later VM created and running
- VM configured with at least one network adapter
- Basic text editor skills (nano or vim)
- Terminal access to Ubuntu VM

### Procedures

1 Open a terminal in your Ubuntu VM and identify your primary network interface name

Launch the terminal application using `Ctrl+Alt+T` or by clicking the terminal icon in the application menu.

Run the following command to list all network interfaces:

    ip link show

Identify your primary Ethernet interface. It will typically be named `enp0s3`, `eth0`, or similar. Wireless interfaces are usually named `wlan0` or `wlp2s0`.

✓ Expected Output

    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: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
        link/ether 08:00:27:3f:a2:b1 brd ff:ff:ff:ff:ff:ff

🔍 Verify: Your primary network interface should show state UP. Note the interface name (e.g., enp0s3) for use in subsequent steps.
2 Check the current IP address configuration of your network interface

Use the `ip address show` command to view the current IP configuration. Replace `enp0s3` with your actual interface name:

    ip address show enp0s3

This shows your current IP address, subnet mask, and broadcast address. Record your current IP address and gateway for reference.

✓ Expected Output

    2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether 08:00:27:3f:a2:b1 brd ff:ff:ff:ff:ff:ff
        inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
           valid_lft 86396sec preferred_lft 86396sec
        inet6 fe80::a00:27ff:fe3f:a2b1/64 scope link
           valid_lft forever preferred_lft forever

🔍 Verify: You should see an inet line showing your current IPv4 address. The word 'dynamic' indicates DHCP is currently being used.
3 View the current default gateway and routing table

Display the routing table to identify your default gateway:

    ip route show

The line beginning with `default via` shows your gateway IP address. Record this address as you'll need it for your static configuration.

✓ Expected Output

    default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
    10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100

🔍 Verify: Note the IP address after 'default via' - this is your gateway (typically 10.0.2.2 for VirtualBox NAT networking).
4 Navigate to the netplan configuration directory and list existing configuration files

Change to the netplan configuration directory:

    cd /etc/netplan
    ls -la

You should see one or more YAML files. The default file is typically named `01-netcfg.yaml`, `00-installer-config.yaml`, or `50-cloud-init.yaml`.

✓ Expected Output

    total 12
    drwxr-xr-x  2 root root 4096 Jan 15 10:23 .
    drwxr-xr-x 95 root root 4096 Jan 15 09:45 ..
    -rw-r--r--  1 root root  116 Jan 15 10:23 00-installer-config.yaml

🔍 Verify: Identify the existing netplan YAML configuration file name. You'll edit this file in the next step.
5 Back up the existing netplan configuration file

Create a backup of your current network configuration before making changes. Replace `00-installer-config.yaml` with your actual filename:

    sudo cp 00-installer-config.yaml 00-installer-config.yaml.backup
    ls -la

This ensures you can restore the original configuration if needed.

✓ Expected Output

    total 16
    drwxr-xr-x  2 root root 4096 Jan 15 10:25 .
    drwxr-xr-x 95 root root 4096 Jan 15 09:45 ..
    -rw-r--r--  1 root root  116 Jan 15 10:23 00-installer-config.yaml
    -rw-r--r--  1 root root  116 Jan 15 10:25 00-installer-config.yaml.backup

🔍 Verify: Confirm the backup file exists with the .backup extension.
6 Open the netplan configuration file in a text editor and view its current contents

Use nano to edit the configuration file with sudo privileges:

    sudo nano 00-installer-config.yaml

You'll see the current DHCP configuration. It should look similar to:

    network:
      version: 2
      ethernets:
        enp0s3:
          dhcp4: true

🔍 Verify: The nano editor opens showing the current netplan YAML configuration.
7 Replace the DHCP configuration with a static IP configuration

Delete the existing content and replace it with the following static IP configuration. Replace `enp0s3` with your interface name, and adjust the IP addresses to match your network:

    network:
      version: 2
      renderer: networkd
      ethernets:
        enp0s3:
          dhcp4: false
          addresses:
            - 10.0.2.50/24
          routes:
            - to: default
              via: 10.0.2.2
          nameservers:
            addresses:
              - 8.8.8.8
              - 8.8.4.4

Important: YAML is whitespace-sensitive. Use exactly 2 spaces for each indentation level. Do not use tabs.

Save the file by pressing `Ctrl+O`, then `Enter`, then exit with `Ctrl+X`.

🔍 Verify: The file is saved. You should be back at the command prompt.
8 Validate the netplan configuration syntax before applying

Before applying changes that could break your network connection, test the configuration:

    sudo netplan try

This command will apply the configuration temporarily and automatically revert after 120 seconds unless you confirm. If there are syntax errors, they will be displayed immediately.

✓ Expected Output

    Warning: Stopping systemd-networkd.service, but it can still be activated by:
      systemd-networkd.socket
    Do you want to keep these settings?

    Press ENTER before the timeout to accept the new configuration

    Changes will revert in 120 seconds

🔍 Verify: If no errors appear and you see the timeout prompt, your YAML syntax is correct. Press Enter to accept the changes.
9 Verify the static IP address has been applied to your interface

Check that your network interface now has the static IP address:

    ip address show enp0s3

The inet line should now show your static IP (10.0.2.50) instead of the previous DHCP address.

✓ Expected Output

    2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
        link/ether 08:00:27:3f:a2:b1 brd ff:ff:ff:ff:ff:ff
        inet 10.0.2.50/24 brd 10.0.2.255 scope global enp0s3
           valid_lft forever preferred_lft forever
        inet6 fe80::a00:27ff:fe3f:a2b1/64 scope link
           valid_lft forever preferred_lft forever

🔍 Verify: The inet line shows 10.0.2.50/24 and no longer says 'dynamic'. The scope should be 'global'.
10 Test basic network connectivity using ping

Test connectivity to your gateway:

    ping -c 4 10.0.2.2

Then test internet connectivity by pinging a public DNS server:

    ping -c 4 8.8.8.8

The `-c 4` option limits the ping to 4 packets. Both tests should succeed with 0% packet loss.

✓ Expected Output

    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=14.2 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=13.8 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=14.1 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=14.0 ms

    --- 8.8.8.8 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3005ms
    rtt min/avg/max/mdev = 13.784/14.025/14.197/0.156 ms

🔍 Verify: You should see replies from the IP address with 0% packet loss. If ping fails, verify your gateway address is correct in the netplan configuration.
11 Verify DNS resolution is working correctly

Test that your DNS nameservers are functioning by resolving a domain name:

    ping -c 4 www.google.com

If this works, DNS resolution is successful. You can also check the DNS resolver status:

    systemd-resolve --status

This shows which DNS servers are configured and being used.

✓ Expected Output

    PING www.google.com (142.250.185.68) 56(84) bytes of data.
    64 bytes from lga34s32-in-f4.1e100.net (142.250.185.68): icmp_seq=1 ttl=118 time=15.3 ms
    64 bytes from lga34s32-in-f4.1e100.net (142.250.185.68): icmp_seq=2 ttl=118 time=14.9 ms

    --- www.google.com ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3005ms

🔍 Verify: The domain name resolves to an IP address and ping succeeds. The systemd-resolve output should show 8.8.8.8 and 8.8.4.4 as DNS servers.
12 Use traceroute to trace the network path to an external host

Install traceroute if it's not already available:

    sudo apt-get update
    sudo apt-get install -y traceroute

Then trace the route to a public server:

    traceroute -n 8.8.8.8

The `-n` option prevents DNS lookups for faster results. This shows each network hop from your VM to the destination.

✓ Expected Output

    traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
     1  10.0.2.2  0.325 ms  0.298 ms  0.286 ms
     2  192.168.1.1  2.156 ms  2.142 ms  2.129 ms
     3  10.45.32.1  8.234 ms  8.221 ms  8.208 ms
     4  * * *
     5  8.8.8.8  14.567 ms  14.554 ms  14.541 ms

🔍 Verify: The first hop should be your gateway (10.0.2.2). Subsequent hops show the path through your ISP's network to reach Google's DNS server.
13 Check active network connections and listening ports using ss

Display all listening TCP ports:

    ss -tuln

The options mean:

- `-t`: TCP sockets
- `-u`: UDP sockets
- `-l`: Listening sockets
- `-n`: Show numerical addresses (don't resolve hostnames)

To see which processes are using these ports, add the `-p` option:

    sudo ss -tulnp

✓ Expected Output

    Netid State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
    tcp   LISTEN 0      128          0.0.0.0:22        0.0.0.0:*
    tcp   LISTEN 0      4096   127.0.0.53%lo:53        0.0.0.0:*
    tcp   LISTEN 0      128             [::]:22           [::]:*
    udp   UNCONN 0      0      127.0.0.53%lo:53        0.0.0.0:*

🔍 Verify: You should see SSH (port 22) and systemd-resolved (port 53) listening. The 0.0.0.0 means listening on all interfaces, while 127.0.0.53 is localhost only.
14 Test port connectivity to a remote service using netcat

Install netcat if needed:

    sudo apt-get install -y netcat

Test if you can connect to a remote web server on port 80:

    nc -zv google.com 80

The options mean:

- `-z`: Zero-I/O mode (just scan, don't send data)
- `-v`: Verbose output

You can also test port 443 (HTTPS):

    nc -zv google.com 443

✓ Expected Output

    Connection to google.com (142.250.185.46) 80 port [tcp/http] succeeded!

🔍 Verify: A 'succeeded' message indicates the port is open and accessible. A timeout or 'refused' message indicates the port is blocked or closed.
15 View and verify the complete network configuration summary

Display a comprehensive overview of your network configuration:

    ip addr show
    ip route show
    cat /etc/netplan/00-installer-config.yaml

Take a screenshot or record this information as documentation of your static IP configuration.

✓ Expected Output

    The ip addr output shows your interface with the static IP 10.0.2.50/24, the ip route shows your default gateway as 10.0.2.2, and the netplan file displays your complete YAML configuration with static addresses, routes, and nameservers.

🔍 Verify: All three outputs should be consistent: the same IP address, gateway, and configuration that you specified in the netplan YAML file.

### ⚠️ Troubleshooting

After applying netplan, you lose network connectivity completely

Reboot the VM or wait 120 seconds if you used 'netplan try'. The configuration will automatically revert. If the VM is rebooted, boot into recovery mode, mount the filesystem as read-write, and restore the backup: `sudo cp /etc/netplan/00-installer-config.yaml.backup /etc/netplan/00-installer-config.yaml`. Common causes include incorrect YAML indentation (use spaces, not tabs), wrong IP address format, or incorrect gateway IP.

Ping to gateway succeeds but ping to external IPs fails

This indicates a routing problem. Verify your gateway address is correct: `ip route show`. The gateway IP should match your VirtualBox network settings. For NAT networking, it's typically 10.0.2.2. Check your VirtualBox network adapter settings: Right-click the VM → Settings → Network → Adapter 1 should be 'Attached to: NAT' or 'Bridged Adapter'.

DNS resolution fails (ping to IP works but ping to domain names fails)

Check your nameserver configuration: `systemd-resolve --status`. Verify the DNS servers in your netplan file are correct. If using Google DNS (8.8.8.8), test connectivity: `ping 8.8.8.8`. If this fails, your firewall might be blocking DNS. Restart the resolved service: `sudo systemctl restart systemd-resolved`. You can also temporarily test with different DNS servers like 1.1.1.1 (Cloudflare) in your netplan configuration.

netplan apply returns 'Permissions denied' error

You must run netplan commands with sudo: `sudo netplan apply`. Also ensure your configuration file has correct permissions: `sudo chmod 600 /etc/netplan/*.yaml`. The netplan directory and files should be owned by root: `sudo chown root:root /etc/netplan/*.yaml`.

YAML syntax errors when running netplan apply

YAML is strict about indentation. Use exactly 2 spaces per indentation level, never tabs. Common errors include: (1) Inconsistent spacing, (2) Missing colons after keys, (3) Incorrect list syntax (items should start with '- '), (4) Quotes around IP addresses (not needed). Use `sudo netplan --debug try` to see detailed error messages. Validate YAML syntax online at yamllint.com before applying.

### 🏆 Configure a Secondary IP Address and Test Port Forwarding

Apply what you learned — complete this task without step-by-step guidance.

Extend your networking skills by completing these tasks:

1. Add a secondary IP address to your network interface (IP alias) using netplan. Configure your interface with both 10.0.2.50/24 and 10.0.2.51/24. Research the correct YAML syntax for multiple addresses in netplan.

2. Install and configure a web server (nginx or apache2) to listen on port 8080. Verify it's running and accessible locally.

3. Document all listening services on your system. Create a text file listing all open TCP ports, the service name, and process ID using the `ss` command with appropriate options.

4. Test connectivity between two points using traceroute to map the complete path from your VM to www.ubuntu.com. Save the output and identify how many hops are required.

5. Simulate a DNS failure by temporarily changing your nameservers in netplan to an unreachable IP (1.2.3.4) and document what error messages you receive when trying to ping domain names. Then restore the working configuration.

Submit your working netplan configuration file, the web server status output, your ports documentation file, and notes about what you learned from the DNS failure simulation.

I have completed this lab exercise

## 📝 Knowledge Check

Test your understanding of the material covered in this module. Select the best answer for each question.

#### Question 1

Which command displays detailed network interface information including IP addresses and interface states in modern Linux systems?

A) ip addr show B) ifconfig -a C) netstat -i D) show interfaces

#### Question 2

What is the correct indentation character to use in netplan YAML configuration files?

A) Tab characters B) Spaces only C) Either tabs or spaces D) No indentation required

#### Question 3

Which netplan command applies network configuration changes with automatic rollback if not confirmed?

A) netplan apply B) netplan test C) netplan try D) netplan verify

#### Question 4

What service handles DNS resolution in modern Ubuntu systems?

A) bind9 B) dnsmasq C) systemd-resolved D) named

#### Question 5

If ping succeeds to an IP address (8.8.8.8) but fails to a hostname (google.com), what is the most likely problem?

A) Network cable is disconnected B) DNS resolution is not working C) Default gateway is incorrect D) Firewall is blocking ICMP

#### Question 6

Which command maps the network path packets take to reach a destination, showing each router hop?

A) ping -r B) netstat -r C) traceroute D) route trace

#### Question 7

What does the netstat flag combination '-tuln' display?

A) All established TCP and UDP connections B) TCP and UDP listening ports with numeric addresses C) Transmission statistics for network interfaces D) Routing table entries

#### Question 8

Which command tests connectivity to a specific port on a remote host?

A) ping -p port hostname B) nc -zv hostname port C) telnet port hostname D) test-port hostname

#### Question 9

In a netplan configuration, what does 'dhcp4: false' indicate?

A) IPv4 is completely disabled B) Static IP configuration is required C) Only IPv6 will be used D) DHCP server mode is enabled

## 🎯 Module Summary

This module covered essential Linux networking skills including network interface management with the `ip` command, static IP configuration using netplan's YAML syntax, and DNS resolution through systemd-resolved. You learned systematic troubleshooting approaches using tools like `ping` for connectivity testing, `traceroute` for path analysis, and `netstat`/`ss` for service verification. Understanding these fundamentals enables effective network configuration and rapid problem diagnosis in Linux environments.

### Learning Objectives — Review

- Configure static IP addresses using netplan
- Manage DNS resolver settings
- Diagnose network connectivity issues using diagnostic tools
- Verify network service status and port availability

🎉

### Module Complete!

You have completed all sections of this module.