RED HAT ENTERPRISE LINUX

TCP/IP Networking Basics

Network Concepts and Configuration Investigation

CIS126RH | RHEL System Administration 1
Mesa Community College

Welcome to this foundational module on TCP/IP networking in Red Hat Enterprise Linux. Networking is the backbone of modern computing - servers exist to provide services over networks, and understanding network concepts is essential for any system administrator. In this module, we'll cover the fundamental concepts of TCP/IP networking: what IP addresses are, how subnetting works, the difference between TCP and UDP, and how DNS translates names to addresses. Then we'll get hands-on with Linux commands to investigate your system's network configuration. You'll learn to use tools like ip, ss, and ping to examine interfaces, check connectivity, and troubleshoot problems. These skills are critical for configuring servers, diagnosing connectivity issues, and understanding how your systems communicate. Whether you're setting up a web server, troubleshooting a failed connection, or just trying to understand network traffic, this module provides the foundation.

Learning Objectives

Understand TCP/IP layers

Describe the network model and how data flows between layers

Work with IP addressing

Understand IPv4/IPv6 addresses, subnet masks, and CIDR notation

Investigate network configuration

Use ip, ss, and other tools to examine network settings

Test network connectivity

Verify connectivity with ping, traceroute, and DNS tools

We have four main learning objectives for this module. First, we'll understand the TCP/IP networking model - the layered architecture that enables network communication. Knowing the layers helps you understand where problems might occur and what tools to use for troubleshooting. Second, we'll master IP addressing. This includes understanding IPv4 and IPv6 address formats, how subnet masks define network boundaries, and how CIDR notation provides a compact way to specify addresses and their networks. Third, we'll investigate network configuration on a running system. You'll learn to use the ip command to view interfaces and addresses, the ss command to see active connections, and examine routing tables. Fourth, we'll test network connectivity. Tools like ping verify basic reachability, traceroute shows the path packets take, and DNS tools help troubleshoot name resolution. These are your go-to utilities when network access fails.

The TCP/IP Model

Application Layer

HTTP, HTTPS, SSH, DNS, FTP, SMTP

Transport Layer

TCP, UDP

Internet Layer

IP, ICMP, ARP

Link Layer

Ethernet, Wi-Fi, MAC addresses

Data Encapsulation: Data flows down through layers when sending (each layer adds headers) and up through layers when receiving (each layer removes headers).

The TCP/IP model describes how network communication works in layers. Each layer has specific responsibilities and communicates with the layers directly above and below it. The Application Layer is where user applications operate. When you browse a website, your browser uses HTTP at this layer. When you SSH to a server, the SSH protocol operates here. Other protocols include DNS for name resolution, FTP for file transfer, and SMTP for email. The Transport Layer provides end-to-end communication. TCP (Transmission Control Protocol) provides reliable, ordered delivery with error checking and retransmission. UDP (User Datagram Protocol) is faster but unreliable - no guarantee of delivery or order. Applications choose based on their needs. The Internet Layer handles addressing and routing. IP (Internet Protocol) provides addresses and determines how to get packets from source to destination across networks. ICMP is used for diagnostics like ping. ARP resolves IP addresses to MAC addresses. The Link Layer deals with the physical network - Ethernet cables, Wi-Fi signals, MAC addresses. It handles getting frames from one device to another on the same local network. When you send data, it flows down through these layers. Each layer adds its own header information. When data is received, it flows up through the layers, with each removing and processing its header.

TCP vs UDP

TCP (Transmission Control Protocol)

Connection-oriented - establishes session first
Reliable delivery - acknowledges packets
Ordered - data arrives in sequence
Error checking - retransmits lost packets
Flow control - prevents overwhelming receiver

Used by: HTTP, SSH, FTP, SMTP, databases

UDP (User Datagram Protocol)

Connectionless - no session setup
Unreliable - no delivery guarantee
Unordered - packets may arrive out of order
No retransmission - lost packets stay lost
Lower overhead - faster, less latency

Used by: DNS, DHCP, streaming, VoIP, gaming

Choosing Protocol: Need reliability? Use TCP. Need speed with acceptable loss? Use UDP. Most applications use TCP unless real-time performance is critical.

TCP and UDP are the two main transport layer protocols, each with different characteristics suited to different applications. TCP is connection-oriented, meaning two systems establish a connection before exchanging data (the "three-way handshake"). It guarantees that data arrives completely, in order, and without errors. If packets are lost, TCP retransmits them. If they arrive out of order, TCP reorders them. This reliability comes with overhead - headers are larger, and the protocol must track state. Most applications use TCP because reliability matters. Web browsing, email, file transfer, SSH - all use TCP. You want your files complete and your web pages rendered correctly. UDP skips all that overhead. It just sends packets with no connection setup, no acknowledgments, no retransmission. If a packet is lost, it's gone. If packets arrive out of order, the application must handle it. Why use UDP then? Speed and real-time performance. DNS queries are typically one packet - TCP's overhead isn't worth it. Streaming video can tolerate occasional lost frames. VoIP and gaming need low latency more than perfect reliability - a retransmitted packet arriving late is worse than losing it. Some applications use both: DNS typically uses UDP but falls back to TCP for large responses.

Ports and Services

A port is a 16-bit number (0-65535) that identifies a specific service or application on a host. Combined with an IP address, it forms a socket.

SSH - Secure Shell

HTTP - Web (unencrypted)

443

HTTPS - Web (encrypted)

DNS - Domain Name System

SMTP - Email sending

3306

MySQL - Database

# View well-known port assignments
[student@server ~]$ cat /etc/services | head -30
[student@server ~]$ grep "^ssh" /etc/services
ssh             22/tcp                          # SSH Remote Login Protocol

While IP addresses identify hosts, ports identify specific services on those hosts. A server might run dozens of services, each listening on different ports. Ports are 16-bit numbers ranging from 0 to 65535. They're divided into ranges: well-known ports (0-1023) are reserved for common services and require root to bind to. Registered ports (1024-49151) are assigned by IANA but can often be used by user processes. Dynamic/private ports (49152-65535) are used for temporary client connections. The common ports you should memorize: 22 for SSH (secure remote access), 80 for HTTP (web traffic), 443 for HTTPS (encrypted web), 53 for DNS (name resolution), 25 for SMTP (sending email). Database ports vary: 3306 for MySQL/MariaDB, 5432 for PostgreSQL. A socket is the combination of IP address and port - for example, 192.168.1.10:443 identifies the HTTPS service on that specific host. When you connect to a website, your browser connects to port 443 on the server, using a random high port on your side. The /etc/services file on Linux maps port numbers to service names. While not authoritative for what's actually running, it's a useful reference for standard port assignments.

IPv4 Addresses

An IPv4 address is a 32-bit number, written as four decimal octets separated by dots. Each octet ranges from 0-255.

192

168

100

■ Network portion ■ Host portion

Network Portion

Identifies which network the host belongs to. All hosts on the same network share this portion.

Host Portion

Identifies the specific host within that network. Must be unique on the network.

Special Addresses: The first address in a network is the network address (192.168.1.0). The last is the broadcast address (192.168.1.255). Neither can be assigned to hosts.

IPv4 addresses are how devices are identified on IP networks. The 32-bit address is typically written as four decimal numbers (octets) separated by dots - this is called dotted-decimal notation. Each octet is 8 bits, so values range from 0 (00000000) to 255 (11111111). This gives us about 4.3 billion possible addresses, which seemed like plenty in the 1980s but is now exhausted. Every IP address has two parts: the network portion and the host portion. The network portion is like a street name - it identifies which network the host belongs to. All devices on the same network share the same network portion. The host portion is like a house number - it identifies a specific device on that network. Each host on a network needs a unique host portion. Where the division occurs depends on the subnet mask, which we'll cover next. The first address in any network range is reserved as the network address - it identifies the network itself. The last address is the broadcast address - packets sent there reach all hosts on the network. Neither can be assigned to actual hosts. In our example, if 192.168.1.0/24 is the network, 192.168.1.0 is the network address and 192.168.1.255 is broadcast. Usable host addresses are 192.168.1.1 through 192.168.1.254.

Subnet Masks and CIDR

A subnet mask defines which bits of an IP address are the network portion (1s) and which are the host portion (0s).

CIDR	Subnet Mask	Network Bits	Host Bits	Hosts
/8	255.0.0.0	8	24	16,777,214
/16	255.255.0.0	16	16	65,534
/24	255.255.255.0	24	8	254
/25	255.255.255.128	25	7	126
/30	255.255.255.252	30	2	2

# CIDR notation: IP address/prefix length
192.168.1.100/24   # Common for LANs
10.0.0.50/8        # Large private network
172.16.5.20/16     # Medium private network

The subnet mask is crucial - it defines where the network portion ends and the host portion begins. It's a 32-bit number where contiguous 1s represent network bits and contiguous 0s represent host bits. CIDR (Classless Inter-Domain Routing) notation is the modern, compact way to write masks. Instead of 255.255.255.0, we write /24 meaning "24 network bits." It's cleaner and immediately tells you the network size. Let's understand the table: /24 is the most common for small networks. 24 bits for network means 8 bits for hosts. 2^8 = 256 addresses, minus network and broadcast gives 254 usable. /8 is huge - a "Class A" network with over 16 million hosts. The 10.0.0.0/8 private range uses this. /16 gives about 65,000 hosts. The 172.16.0.0/16 private range is an example. /30 is minimal - only 2 usable addresses. Perfect for point-to-point links between routers where you only need to address the two endpoints. /25 splits a /24 in half - 126 hosts per half. Subnetting larger networks into smaller ones is a common practice. The math: usable hosts = 2^(32-prefix) - 2. We subtract 2 for network and broadcast addresses. Understanding this helps you plan networks and recognize what addresses belong together.

Private vs Public Addresses

Private Address Ranges

Reserved for internal networks, not routed on the Internet:

10.0.0.0/8	16M addresses
172.16.0.0/12	1M addresses
192.168.0.0/16	65K addresses

Public Addresses

Globally unique, routable on the Internet:

Assigned by ISPs and registries
Must be paid for / allocated
Used for Internet-facing servers
Increasingly scarce (IPv4 exhaustion)

NAT (Network Address Translation): Allows private addresses to access the Internet by translating them to public addresses at the network boundary.

# Loopback address - always refers to this host
127.0.0.1        # IPv4 loopback
::1              # IPv6 loopback

Understanding the difference between private and public addresses is fundamental for network design and troubleshooting. Private addresses are reserved ranges that can be used freely within organizations. They're not routed on the public Internet - if you try to send a packet to 192.168.1.100 from the Internet, it won't arrive anywhere. Any organization can use the same private ranges internally without conflict. The three private ranges are: 10.0.0.0/8 - one huge network or subdivided as needed, commonly used in enterprises. 172.16.0.0/12 - actually 172.16.0.0 through 172.31.255.255, medium-sized. 192.168.0.0/16 - commonly used in home and small office networks, often as 192.168.0.0/24 or 192.168.1.0/24. Public addresses are globally unique and routable. When you visit a website, your computer ultimately communicates with a public IP. These are assigned through regional registries and ISPs. IPv4 public addresses are exhausted - no more free blocks exist. NAT bridges the gap between private networks and the Internet. Your home router likely has one public IP from your ISP but provides many private addresses internally. When internal hosts access the Internet, NAT translates their private addresses to the public one. The loopback address 127.0.0.1 (or "localhost") always refers to the local machine. It's useful for testing services locally without involving the network.

IPv6 Addresses

IPv6 uses 128-bit addresses, written as eight groups of four hexadecimal digits separated by colons.

# Full IPv6 address
2001:0db8:0000:0000:0000:0000:0000:0001

# Simplified (remove leading zeros, :: for consecutive zero groups)
2001:db8::1

# Link-local address (auto-configured, starts with fe80)
fe80::a00:27ff:fe4e:66a1

# Loopback
::1

IPv6 Benefits

Vastly larger address space
Built-in IPsec support
Auto-configuration (SLAAC)
No need for NAT

Common Prefixes

2000::/3 - Global unicast
fe80::/10 - Link-local
fc00::/7 - Unique local (private)
::1/128 - Loopback

IPv6 was designed to solve IPv4 address exhaustion and incorporates lessons learned from decades of IPv4 use. With 128 bits, IPv6 provides roughly 340 undecillion addresses - enough for every atom on Earth's surface to have billions of addresses. IPv6 addresses are written in hexadecimal, grouped into eight 16-bit sections separated by colons. This is verbose, so simplification rules exist: leading zeros in each group can be omitted (0db8 becomes db8), and one consecutive run of all-zero groups can be replaced with :: (but only once per address). So 2001:0db8:0000:0000:0000:0000:0000:0001 becomes 2001:db8::1. Link-local addresses starting with fe80 are automatically assigned to every interface. They're only valid on the local network segment - similar to IPv4's 169.254.x.x auto-configuration addresses. Link-local addresses enable neighbor discovery and are essential for IPv6 operation even if you have global addresses too. Global unicast addresses (starting with 2 or 3) are the equivalent of public IPv4 addresses - routable on the Internet. Unique local addresses (fc00::/7) are like private IPv4 ranges. IPv6 was designed with security in mind - IPsec is a required part of the standard. SLAAC (Stateless Address Autoconfiguration) lets hosts generate their own addresses without DHCP, though DHCPv6 exists too.

DNS - Domain Name System

DNS translates human-readable domain names (like www.example.com) into IP addresses that computers use to route traffic.

www.example.com

→ DNS Query →

93.184.216.34

# DNS configuration file
[student@server ~]$ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
search example.com

# Local hostname resolution
[student@server ~]$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain
::1         localhost localhost.localdomain
192.168.1.10 webserver.example.com webserver

# Resolution order
[student@server ~]$ grep hosts /etc/nsswitch.conf
hosts:      files dns myhostname

DNS is what makes the Internet usable. Without it, you'd need to remember IP addresses for every website you visit. DNS provides a hierarchical, distributed database that maps names to addresses. When you type a URL, your system queries DNS to find the IP address. The query typically goes: local cache → configured nameserver → recursive resolution through the DNS hierarchy → authoritative server for that domain. /etc/resolv.conf tells your system which DNS servers to query. The nameserver lines list DNS servers in order of preference. The search directive appends a domain to unqualified names - so "webserver" becomes "webserver.example.com". /etc/hosts provides local name resolution that bypasses DNS. Entries here are checked first (by default). This is useful for local names, overriding DNS, or when DNS isn't available. Every system has localhost mapped to 127.0.0.1. /etc/nsswitch.conf determines the order of name resolution methods. "files dns" means check /etc/hosts first, then DNS. Some systems add myhostname to ensure the local hostname always resolves. Understanding this order is important for troubleshooting - if a name resolves wrong, check /etc/hosts first, then DNS, then check which takes precedence.

Network Interfaces

A network interface represents a network connection - physical (Ethernet, Wi-Fi) or virtual (loopback, bridge, VLAN). Each has a unique name.

Name Pattern	Type	Example
lo	Loopback (localhost)	lo
eno*	Onboard Ethernet	eno1, eno2
ens*	PCI Express hotplug slot	ens33, ens192
enps	PCI bus location	enp0s3, enp3s0
eth*	Legacy naming (older systems)	eth0, eth1
wl*	Wireless LAN	wlan0, wlp2s0

Predictable Names: RHEL uses "predictable network interface names" based on hardware location. This prevents names from changing when hardware is added/removed.

Network interfaces are how your system connects to networks. Understanding interface naming helps you identify what you're working with. The loopback interface "lo" is always present. It's the internal interface for localhost (127.0.0.1). Traffic to lo never leaves the machine - it's used for local inter-process communication. Modern RHEL uses predictable network interface names based on hardware characteristics, replacing the old eth0, eth1 scheme where names could change between boots. This predictability is crucial for reliable configuration. "eno" followed by a number indicates onboard (built into motherboard) Ethernet - eno1 is the first onboard port. "ens" indicates a PCI Express hotplug slot - common in virtual machines, like ens33 in VMware. "enp" followed by bus and slot numbers indicates a PCI device location - enp0s3 is PCI bus 0, slot 3. This is very specific to hardware position. Wireless interfaces follow similar patterns with "wl" prefix instead of "en". Legacy names like eth0 still appear on older systems or when predictable naming is disabled. In containers, you might see "veth" pairs connecting container to host. Understanding these patterns helps you identify what type of connection you're looking at and predict how names might change (or not) with hardware changes.

The ip Command

# Show all interfaces and addresses
[student@server ~]$ ip addr show
[student@server ~]$ ip a                    # Short form

# Show specific interface
[student@server ~]$ ip addr show ens33

# Show only IPv4 addresses
[student@server ~]$ ip -4 addr

# Show only IPv6 addresses
[student@server ~]$ ip -6 addr

# Show link layer information (MAC addresses, state)
[student@server ~]$ ip link show
[student@server ~]$ ip l                    # Short form

# Brief output format
[student@server ~]$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128 
ens33            UP             192.168.1.100/24 fe80::a00:27ff:fe4e:66a1/64

Note: The ifconfig command is deprecated. Always use ip on modern systems.

The ip command is your primary tool for viewing and managing network interfaces. It replaces the older ifconfig command which is now deprecated on RHEL. "ip addr show" (or just "ip a") displays all interfaces with their IP addresses. You'll see the interface name, state (UP/DOWN), MAC address, and configured IP addresses for both IPv4 and IPv6. "ip addr show ens33" shows only a specific interface - useful when you have many interfaces. Filter to IPv4 with "ip -4 addr" or IPv6 with "ip -6 addr" when you only care about one protocol. "ip link show" focuses on the link layer - MAC addresses, MTU, interface state, and flags. It doesn't show IP addresses. The state is important: UP means the interface is enabled, LOWER_UP means there's a physical link (cable connected, carrier signal present). The "-br" flag gives brief output - one line per interface with key information. Much easier to scan when you just need a quick overview. This command displays current configuration but doesn't change anything. We'll cover configuration later. For now, understand that ip is how you investigate what's configured on your system.

Understanding ip addr Output

2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:0c:29:4e:66:a1 brd ff:ff:ff:ff:ff:ff altname enp2s1 inet 192.168.1.100/24 brd 192.168.1.255 scope global dynamic noprefixroute ens33 valid_lft 86400sec preferred_lft 86400sec inet6 fe80::a00:27ff:fe4e:66a1/64 scope link noprefixroute valid_lft forever preferred_lft forever

Interface name: ens33

Flags: UP (enabled), LOWER_UP (link detected)

MTU: 1500 bytes (standard Ethernet)

MAC address: 00:0c:29:4e:66:a1

IPv4: 192.168.1.100/24

Broadcast: 192.168.1.255

IPv6 link-local: fe80::...

Scope: global (routable) or link (local only)

dynamic: Address was assigned by DHCP. noprefixroute: Don't automatically add route for this prefix.

Let's decode the ip addr output in detail - this is important for understanding your network configuration. The first line shows the interface name (ens33), flags in angle brackets, and status. BROADCAST means the interface supports broadcast. MULTICAST means it supports multicast. UP means the interface is administratively enabled. LOWER_UP means physical link is present - a cable is connected and working. MTU (Maximum Transmission Unit) is the largest packet size - 1500 bytes is standard for Ethernet. The link/ether line shows the MAC address - the hardware address burned into the NIC. brd is the broadcast MAC address (all ff's). The inet line is the IPv4 configuration: address with CIDR prefix (192.168.1.100/24), broadcast address, and scope. "global" scope means this address is routable - it can communicate beyond the local link. "dynamic" indicates DHCP assigned this address. valid_lft shows the DHCP lease time remaining. The inet6 line shows IPv6. The fe80:: address is link-local - automatically generated for every interface, only valid on the local segment (scope link). If you had a global IPv6 address, it would show scope global. Understanding this output is essential for troubleshooting. If the interface isn't UP or lacks LOWER_UP, you have a configuration or physical problem before even looking at IP addresses.

Viewing Routes

The routing table determines where packets are sent based on their destination address. Each entry specifies a destination network and where to send matching packets.

# Show routing table
[student@server ~]$ ip route show
[student@server ~]$ ip r                    # Short form
default via 192.168.1.1 dev ens33 proto dhcp metric 100
192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.100 metric 100

# Show IPv6 routes
[student@server ~]$ ip -6 route

# Show route to specific destination
[student@server ~]$ ip route get 8.8.8.8
8.8.8.8 via 192.168.1.1 dev ens33 src 192.168.1.100 uid 1000

default via 192.168.1.1

Default gateway - where to send packets when no other route matches. Essential for Internet access.

192.168.1.0/24 dev ens33

Direct route - this network is directly connected, send packets directly via this interface.

The routing table is how your system decides where to send packets. When sending to an IP address, the system checks the routing table for the most specific matching route. "ip route show" displays the IPv4 routing table. Let's understand each entry. The default route (sometimes shown as 0.0.0.0/0) is the catch-all - when no other route matches, send packets here. "via 192.168.1.1" means send them to the gateway at that address. This is typically your router. Without a default route, you can't reach the Internet. The second line is a direct route for the local network. "192.168.1.0/24 dev ens33" means the 192.168.1.x network is directly reachable via ens33 - no gateway needed, just send packets directly. "proto kernel" means the kernel added this route automatically based on interface configuration. "src 192.168.1.100" indicates which source IP to use when sending. "metric" is the route's cost - lower numbers are preferred when multiple routes exist to the same destination. "ip route get" is powerful for troubleshooting. It shows exactly which route would be used for a specific destination, including the source address and interface. "ip route get 8.8.8.8" tells you how your system would reach Google's DNS server.

Viewing Connections: ss

# Show all connections
[student@server ~]$ ss

# Show listening sockets
[student@server ~]$ ss -l

# Show TCP connections
[student@server ~]$ ss -t
[student@server ~]$ ss -lt              # TCP listening

# Show UDP sockets
[student@server ~]$ ss -u
[student@server ~]$ ss -lu              # UDP listening

# Show with process information (requires root)
[root@server ~]# ss -tlnp
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      128    0.0.0.0:22           0.0.0.0:*         users:(("sshd",pid=1234,fd=3))

# Show numeric (don't resolve names)
[student@server ~]$ ss -n

# Show all with details
[student@server ~]$ ss -tulna

The ss command shows socket statistics - what network connections exist and what ports are in use. It replaced the older netstat command and is much faster on systems with many connections. Plain "ss" shows established connections. You'll see connection state, queues, local address:port, and peer address:port. The -l flag shows listening sockets - servers waiting for connections. "ss -lt" shows TCP services listening for connections, "ss -lu" shows UDP. This tells you what services your system is offering. The -t and -u flags filter to TCP or UDP. The -a flag shows all sockets including those not connected or not listening. Combine flags: -lt for listening TCP, -luna for all UDP sockets numerically. The -n flag prevents name resolution. Instead of showing "ssh" for port 22, it shows "22". Faster and sometimes clearer, especially for troubleshooting. The -p flag shows the process using each socket. This requires root access. It's invaluable for finding what's listening on a port or what process has a connection. "ss -tlnp" is a common combination: listening TCP sockets with numeric output and process information. It answers "what services are my server offering and what processes provide them?" When troubleshooting connectivity, ss helps verify services are actually listening where expected and shows established connections to identify what's communicating.

Testing Connectivity: ping

ping sends ICMP Echo Request packets to a host and waits for Echo Reply packets. It's the most basic connectivity test.

# Ping a host (runs until Ctrl+C)
[student@server ~]$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.543 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.412 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.412/0.477/0.543/0.065 ms

# Send specific number of pings
[student@server ~]$ ping -c 4 google.com

# Ping IPv6 address
[student@server ~]$ ping -6 ::1
[student@server ~]$ ping6 fe80::1%ens33    # Link-local needs interface

# Quick connectivity check
[student@server ~]$ ping -c 1 -W 2 192.168.1.1 && echo "Host is up"

ping is the first tool to reach for when troubleshooting connectivity. It uses ICMP (Internet Control Message Protocol) to test if a host is reachable and measure round-trip time. By default, ping on Linux continues until you press Ctrl+C. Each line shows a response: the size, source, sequence number, TTL (Time To Live - decrements at each hop), and round-trip time in milliseconds. The statistics at the end summarize packets sent, received, and lost, plus timing statistics. Packet loss above 0% indicates network problems. The -c flag specifies the count of pings to send. "ping -c 4 host" sends exactly 4 pings and exits - useful in scripts. The -W flag sets a timeout for each ping. If you're testing and don't want to wait long for unreachable hosts, "ping -c 1 -W 2" sends one ping with a 2-second timeout. For IPv6, use ping -6 or the ping6 command. Link-local IPv6 addresses require specifying the interface with %interface syntax because the same link-local address could exist on multiple interfaces. When ping fails, it might mean the host is down, a firewall is blocking ICMP, or there's a routing problem. When it succeeds, basic IP connectivity works - but that doesn't guarantee services are working. A host might respond to ping but have a broken web server.

Tracing Routes

# Trace route to destination
[student@server ~]$ traceroute google.com
traceroute to google.com (142.250.80.46), 30 hops max, 60 byte packets
 1  gateway (192.168.1.1)  0.543 ms  0.412 ms  0.389 ms
 2  10.0.0.1 (10.0.0.1)  5.234 ms  5.112 ms  5.089 ms
 3  isp-router.example.net (203.0.113.1)  12.456 ms  12.234 ms  12.198 ms
 4  * * *
 5  google-peer.example.net (198.51.100.1)  15.678 ms  15.456 ms  15.234 ms
 6  142.250.80.46 (142.250.80.46)  16.789 ms  16.567 ms  16.345 ms

# Use ICMP instead of UDP (may pass firewalls better)
[student@server ~]$ traceroute -I google.com

# Use TCP to specific port
[student@server ~]$ traceroute -T -p 443 google.com

# Alternative: mtr (combines ping and traceroute)
[student@server ~]$ mtr google.com

* * * means: That hop didn't respond - either the router doesn't send ICMP responses, or a firewall blocks them. It doesn't necessarily mean a problem.

traceroute shows the path packets take to reach a destination. It's essential for identifying where connectivity fails in a multi-hop network. It works by sending packets with increasing TTL values. Each router decrements TTL; when it reaches 0, the router sends back a "Time Exceeded" message revealing its address. By incrementing TTL from 1, traceroute discovers each hop. The output shows each hop with its address (and hostname if DNS resolves it) plus three timing measurements. Hop 1 is usually your default gateway, then your ISP's routers, then transit networks, finally reaching the destination. Lines showing "* * *" mean that hop didn't respond. This is common - many routers are configured to not respond to traceroute to reduce processing load. If you see stars in the middle but reach the destination, there's no problem - just silent routers. If it stops at stars and never completes, the path is blocked somewhere. By default, traceroute uses UDP. The -I flag uses ICMP Echo instead, which may work better through some firewalls. The -T flag uses TCP to a specific port - useful for testing if a particular service port is reachable through all hops. mtr (My TraceRoute) combines ping and traceroute, continuously updating with packet loss and latency for each hop. It's excellent for diagnosing intermittent problems.

DNS Diagnostic Tools

# Simple DNS lookup
[student@server ~]$ host google.com
google.com has address 142.250.80.46
google.com has IPv6 address 2607:f8b0:4004:800::200e
google.com mail is handled by 10 smtp.google.com.

# Detailed DNS query
[student@server ~]$ dig google.com
;; ANSWER SECTION:
google.com.             300     IN      A       142.250.80.46

# Query specific record type
[student@server ~]$ dig google.com MX          # Mail servers
[student@server ~]$ dig google.com NS          # Name servers
[student@server ~]$ dig google.com AAAA        # IPv6 address

# Query specific DNS server
[student@server ~]$ dig @8.8.8.8 google.com

# Reverse lookup (IP to name)
[student@server ~]$ dig -x 8.8.8.8
[student@server ~]$ host 8.8.8.8

# Short output
[student@server ~]$ dig +short google.com
142.250.80.46

DNS problems are common sources of connectivity issues. These tools help diagnose name resolution. The host command provides simple, readable DNS lookups. It shows A records (IPv4), AAAA records (IPv6), and MX records (mail) by default. Quick and easy for basic queries. dig (Domain Information Groper) is the power tool for DNS. Its output is more verbose but shows everything: query details, answer section, authority section, timing information. It's what DNS administrators use. You can query specific record types: A for IPv4 addresses, AAAA for IPv6, MX for mail servers, NS for nameservers, CNAME for aliases, TXT for text records. Understanding record types helps troubleshoot specific services. The @ symbol specifies which DNS server to query. "dig @8.8.8.8 google.com" queries Google's public DNS directly, bypassing your configured resolver. This helps determine if problems are with your DNS server or more widespread. Reverse lookups (dig -x) translate IP addresses back to names. This is useful for identifying unknown IPs in logs or understanding what you're connecting to. The +short option gives minimal output - just the answer. Useful in scripts or when you just need the IP address quickly. When DNS isn't working, check /etc/resolv.conf for configured servers, then test those servers directly with dig @server.

NetworkManager Overview

NetworkManager is the default network configuration daemon on RHEL. It manages network connections through profiles called "connections."

# Check NetworkManager status
[student@server ~]$ systemctl status NetworkManager

# List all connections
[student@server ~]$ nmcli connection show
NAME     UUID                                  TYPE      DEVICE
ens33    a1b2c3d4-e5f6-7890-abcd-ef1234567890  ethernet  ens33
virbr0   b2c3d4e5-f6a7-8901-bcde-f12345678901  bridge    virbr0

# Show device status
[student@server ~]$ nmcli device status
DEVICE  TYPE      STATE      CONNECTION
ens33   ethernet  connected  ens33
lo      loopback  unmanaged  --

# Show detailed connection info
[student@server ~]$ nmcli connection show ens33

# Show general network status
[student@server ~]$ nmcli general status

NetworkManager is RHEL's standard tool for network configuration. It runs as a daemon and manages network connections dynamically. While you can still configure networks with files, NetworkManager is the supported method. NetworkManager uses "connections" - configuration profiles that can be applied to network devices. A connection defines everything: IP addressing (static or DHCP), DNS, routes, and more. The same connection can potentially be applied to different physical devices. nmcli is the command-line interface to NetworkManager. "nmcli connection show" lists all defined connections with their UUID (unique identifier), type, and which device they're currently active on. "nmcli device status" shows network interfaces and their state. Interfaces can be "connected" (active connection applied), "disconnected" (no active connection), or "unmanaged" (not controlled by NetworkManager, like loopback). nmcli connection show <name> displays all settings for a specific connection - this is extensive, showing every configurable parameter. "nmcli general status" gives a quick overview of NetworkManager's state, whether networking is enabled, and the overall connectivity state. In the next module, we'll cover how to modify network configuration. For now, understand that nmcli is how you investigate what NetworkManager has configured.

Troubleshooting Workflow

Check interface: ip addr - Is the interface UP? Does it have an IP?

Check gateway: ip route - Is default route configured? ping gateway

Check DNS: cat /etc/resolv.conf - Are nameservers configured? dig

Test remote: ping external IP (8.8.8.8), then hostname

Check service: ss -tln - Is service listening? Test with client.

# Quick diagnostic sequence
ip -br addr                 # Interface status
ip route                    # Routing table
ping -c 1 192.168.1.1       # Gateway reachable?
ping -c 1 8.8.8.8           # Internet reachable?
dig google.com              # DNS working?
ss -tlnp                    # Services listening?

When network connectivity fails, follow this systematic troubleshooting workflow. Starting from the bottom of the network stack and working up helps isolate where the problem lies. Step 1: Check the interface itself. "ip addr" shows if interfaces are UP, if they have IP addresses, and basic configuration. If the interface is DOWN or has no IP, there's your problem - check cables, drivers, DHCP, or static configuration. Step 2: Check routing. "ip route" shows if you have a default gateway. If you can ping your gateway, your local network is working. If you can't, the problem is between you and the gateway - check cables, switches, or the gateway itself. Step 3: Check DNS. Look at /etc/resolv.conf for nameservers. Test with dig against the configured server. Many "network problems" are actually DNS problems - IP connectivity works but names don't resolve. Step 4: Test Internet connectivity. Ping an IP address (8.8.8.8) to test routing works. Then ping or dig a hostname to verify DNS. If IP works but names don't, it's DNS. If neither works, it's routing or your ISP. Step 5: If trying to reach a specific service, verify it's listening with ss. The service might be down, listening on the wrong interface, or a firewall might block it. This methodical approach quickly identifies which layer has the problem, so you don't waste time on the wrong thing.

Key Takeaways

TCP/IP Model: Four layers (Application, Transport, Internet, Link); TCP for reliability, UDP for speed

IP Addressing: IPv4 (32-bit, dotted decimal), IPv6 (128-bit, hex); subnet masks define network/host portions

Investigation: ip addr for interfaces, ip route for routing, ss for connections

Testing: ping for connectivity, traceroute for path, dig for DNS

Let's summarize the essential networking concepts and skills covered in this module. The TCP/IP model organizes network communication into four layers. Understanding the layers helps you troubleshoot - physical problems at the Link layer, addressing at Internet, connection issues at Transport, application problems at Application. TCP provides reliable, ordered delivery; UDP is faster but unreliable. IP addressing identifies hosts on networks. IPv4 uses 32-bit addresses in dotted-decimal format. IPv6 uses 128-bit addresses in hexadecimal. Subnet masks divide addresses into network and host portions - CIDR notation (/24) is the modern way to express this. Private addresses work within organizations; public addresses are globally routable. For investigation, the ip command is essential: ip addr shows interfaces and addresses, ip route shows how traffic is directed. The ss command shows active connections and listening services. These replace older tools like ifconfig and netstat. For testing, ping verifies basic connectivity using ICMP. traceroute shows the path packets take, helping identify where problems occur. DNS tools like dig and host troubleshoot name resolution.

Graded Lab

Use ip addr to view all network interfaces and their addresses
Examine the routing table and identify the default gateway
Use ss to find all TCP services listening on your system
Ping your gateway, then ping 8.8.8.8 to test Internet connectivity
Use dig to query DNS for various record types (A, MX, NS)
Run traceroute to an external host and interpret the results

Next: Managing Network Configuration