Learn › Linux networking › Hosts, routes and packets
Configure routes on client and server, enable IPv4 forwarding, and verify both directions on three real Linux VMs.
This chapter covers the following topics
What you already know You can enter shell commands, read their output, and recognize when a change needs administrator rights. No cloud networking knowledge is assumed.
Objectives
1. Identify which host and interface a command affects. 2. Explain a connected route and choose a reachable next hop. 3. Configure routes on both endpoints and forwarding on a Linux router. 4. Verify connectivity in both directions using the exercise interfaces. 5. Distinguish observed packet evidence from an inference about a failure.
The practice lab starts three separate Debian 12 VMs on Linode for 75 minutes. Management access uses eth0. The exercises use two isolated private networks on eth1 and eth2. Keep the management default route intact. All three machines expire together. A restart clears runtime routes and shell processes; ending the lab removes its files. The optional loading game can be skipped.
The terminal examples were captured on the actual three-VM lab on 7 September 2026. Generated IPv6 addresses, ping timings, process identities and packet timestamps vary. Exercises require the named live machine; reading a recorded example does not complete an exercise.
A shell prompt is useful context, but it can be customized.
>>> Section 1.1 uses hostname to check which VM receives the command.
The client is 10.71.10.10/24. Its connected subnet is 10.71.10.0/24.
>>> Section 1.1 explains that /24 fixes the first 24 bits. The router address 10.71.10.1 shares those bits.
A route can name a gateway to reach another subnet.
>>> Section 1.3 selects the router address on the source host's own exercise subnet.
Linux can route packets between interfaces.
>>> Section 1.4 enables forwarding. Routes and firewall policy remain separate requirements.
An ICMP echo request travels from client to server.
>>> Sections 1.5 and 1.6 verify the reverse path as well as the outbound path.
A host is a system with its own network stack. This lab has three separate kernels, route tables and shells. Changes made in one shell do not configure the other two VMs.
Open the client shell in the workspace. Run hostname before making a change. The client, router and server tabs select the terminal that receives your commands. Clicking a machine in Topology only inspects it; use its Open terminal button to select that shell.
machine: client prompt: admin@client:~$ answer: hostname output: client hint: Section 1.1. Print the hostname on client.
The output names client. It identifies the host executing the command. It does not report the next hop, the provider label, or another machine selected for inspection.
Open the router terminal tab, then run hostname. The router has one interface on each exercise network. Its third interface, eth0, is reserved for management.
machine: router prompt: admin@router:~$ answer: hostname output: router hint: Section 1.1. Print the hostname on router.
The output names router. The client shell remains available in its own tab. Switching back preserves its process state and scrollback during this session.
Open server and run hostname. Server and client are symmetric endpoints for this exercise. Either one can originate a ping; the names describe their roles in the lesson.
machine: server prompt: admin@server:~$ answer: hostname output: server hint: Section 1.1. Print the hostname on server.
The output names server. You reach this VM through the browser terminal, which needs no login and no password. Topology lists its exercise addresses. These addresses carry the traffic this chapter studies.
Open client. ip -br address show dev eth1 asks iproute2 for a brief address listing of one interface. -br chooses compact output, address show reads addresses, and dev eth1 selects the device.
An IPv4 address with /24 contains 24 network bits and 8 host bits. Here, 10.71.10.10/24 belongs to 10.71.10.0/24. The diagram states the assigned layout; this command checks the guest's actual configuration.
machine: client prompt: admin@client:~$ answer: ip -br address show dev eth1 output: eth1 UP 10.71.10.10/24 fe80::92de:1ff:fe70:627b/64 hint: Section 1.1. Use the brief address view for dev eth1.
The first field is eth1 and the second reports UP. The IPv4 address is 10.71.10.10/24. The fe80:: address is IPv6 link-local and is generated per interface, so its exact bytes will differ. UP alone does not prove the remote application is reachable.
Open router. Read eth2 with ip -br address show dev eth2. Router eth1 belongs to the client network; router eth2 belongs to the server network. Two interfaces do not by themselves enable packet forwarding.
machine: router prompt: admin@router:~$ answer: ip -br address show dev eth2 output: eth2 UP 10.71.20.1/24 fe80::92de:2ff:fefe:5c9d/64 hint: Section 1.1. Use the brief address view for dev eth2.
The recorded eth2 address is 10.71.20.1/24. The server will use that address as its next hop. Its prefix differs from the client subnet. The generated IPv6 link-local address may differ in your VM.
Open client and run ip -4 route show dev eth1. -4 limits output to IPv4. Linux normally installs a connected route when an address and prefix are added to an interface.
The route covers 10.71.10.0/24. A destination inside that subnet can be reached directly on eth1. Ethernet delivery to the local peer uses neighbor resolution, normally ARP for IPv4.
machine: client prompt: admin@client:~$ answer: ip -4 route show dev eth1 output: 10.71.10.0/24 proto kernel scope link src 10.71.10.10 hint: Section 1.1. Read the IPv4 route table for dev eth1.
The destination prefix is 10.71.10.0/24. proto kernel identifies the kernel-created route. scope link means this route reaches destinations on the attached link. src 10.71.10.10 is the preferred source address. There is no via gateway in this connected route.
Open router and run /usr/sbin/sysctl net.ipv4.ip_forward. This reads the IPv4 forwarding setting without changing it. The full path works in noninteractive SSH as well as the browser shell on this Debian image.
The starting value is zero. The router can receive traffic addressed to itself, but this setting does not permit it to forward IPv4 packets between interfaces. Section 1.4 returns to this setting after both endpoint routes are installed.
machine: router prompt: admin@router:~$ answer: /usr/sbin/sysctl net.ipv4.ip_forward output: net.ipv4.ip_forward = 0 hint: Section 1.1. Read net.ipv4.ip_forward with /usr/sbin/sysctl.
The value 0 means IPv4 forwarding is disabled. A successful ping to one router interface would test the router as a destination, not its ability to carry transit traffic.
Open client and run ping -n -I eth1 -c 3 -W 1 10.71.10.1. -n keeps addresses numeric, -I eth1 selects the exercise interface, -c 3 sends three echo requests, and -W 1 bounds the wait for a reply.
The target is on the connected subnet. This test does not need a route to the server subnet or forwarding on the router. The displayed timings are one measured run, not a latency guarantee.
machine: client prompt: admin@client:~$ answer: ping -n -I eth1 -c 3 -W 1 10.71.10.1 output: PING 10.71.10.1 (10.71.10.1) from 10.71.10.10 eth1: 56(84) bytes of data. 64 bytes from 10.71.10.1: icmp_seq=1 ttl=64 time=1.10 ms 64 bytes from 10.71.10.1: icmp_seq=2 ttl=64 time=0.578 ms 64 bytes from 10.71.10.1: icmp_seq=3 ttl=64 time=0.549 ms
--- 10.71.10.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2019ms rtt min/avg/max/mdev = 0.549/0.742/1.101/0.253 ms hint: Section 1.2. Send three numeric pings through eth1 to 10.71.10.1.
Three replies were received in the captured run. icmp_seq associates each reply with a request. ttl is the remaining IPv4 time-to-live value in the reply. The final summary reports transmitted requests, received replies and loss. Success establishes this ICMP exchange only, not DNS or application health.
Stay on client and run ping -n -I eth1 -c 3 -W 1 10.71.20.20. This binds the test to the exercise interface instead of allowing the management default route to become the lesson's path.
The server is on another subnet. The required endpoint routes are absent and forwarding is off. This is an expected failed test. Its recorded text and wait duration can vary with neighbor state and timing.
machine: client prompt: admin@client:~$ answer: ping -n -I eth1 -c 3 -W 1 10.71.20.20 output: PING 10.71.20.20 (10.71.20.20) from 10.71.10.10 eth1: 56(84) bytes of data.
--- 10.71.20.20 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2040ms hint: Section 1.2. Send three numeric pings through eth1 to 10.71.20.20.
The recorded run received no replies. That is an observation, not a diagnosis of one particular device. Several conditions are missing in this starting configuration. The next sections add each requirement explicitly.
On client, run labnet ip route replace 10.71.20.0/24 via 10.71.10.1 dev eth1. The destination prefix names the server subnet. The next hop is the router's address on the client subnet.
Changing a route needs administrator rights. This lab gives you no root account and no sudo. labnet sends the command to a small service on each machine that runs the real ip or sysctl command as root, but only in the forms this course teaches and only on the exercise interfaces. labnet help lists those forms. On a server you administer, you would type sudo where this lab types labnet.
replace adds the route when absent or updates the matching route. This explicit /24 is more specific than the management default route. Keep that default route so management SSH continues to work. This change is runtime configuration; it is lost on reboot.
machine: client prompt: admin@client:~$ answer: labnet ip route replace 10.71.20.0/24 via 10.71.10.1 dev eth1 output:
hint: Section 1.3. Set the route for 10.71.20.0/24 via 10.71.10.1 on eth1.
A successful route change normally prints nothing. Silence is not the verification step. Read the route selected for the server address next. The server still needs a return route, and the router still needs forwarding.
Stay on client and run ip -4 route get 10.71.20.20. Unlike a table listing, route get asks the kernel to resolve the route for a particular destination. It does not send a packet to that destination.
For this single-table exercise, the more specific matching prefix selects the exercise route. Policy routing can add other lookup rules, which a later chapter will examine.
machine: client prompt: admin@client:~$ answer: ip -4 route get 10.71.20.20 output: 10.71.20.20 via 10.71.10.1 dev eth1 src 10.71.10.10 uid 1000 cache hint: Section 1.3. Ask the IPv4 route lookup for destination 10.71.20.20.
The result names next hop 10.71.10.1, device eth1 and source 10.71.10.10. The uid records the requesting user identity and may differ on other images. The cache line is part of the lookup result; it is not proof of a received response.
Open server. Run labnet ip route replace 10.71.10.0/24 via 10.71.20.1 dev eth1. The destination is now the client subnet. The next hop is the router address that server can reach locally.
A route on client cannot configure server. Return traffic requires its own lookup. NAT is unnecessary between these private subnets because both sides have explicit routes through the same Linux router.
machine: server prompt: admin@server:~$ answer: labnet ip route replace 10.71.10.0/24 via 10.71.20.1 dev eth1 output:
hint: Section 1.3. Set the route for 10.71.10.0/24 via 10.71.20.1 on eth1.
No output is expected for the successful change. The server now has a specific route back to the client subnet. The next action changes the forwarding policy on the separate router VM.
Open router. Run labnet sysctl -w net.ipv4.ip_forward=1. -w writes the setting. This permits IPv4 forwarding between interfaces, subject to route selection and firewall rules.
The lab already allows forwarding between the two exercise interfaces and blocks forwarding through management eth0. Enabling forwarding does not add NAT, configure the endpoints, or replace a firewall policy. This runtime setting returns to the lab's disabled default on reboot.
machine: router prompt: admin@router:~$ answer: labnet sysctl -w net.ipv4.ip_forward=1 output: net.ipv4.ip_forward = 1 hint: Section 1.4. Write net.ipv4.ip_forward=1 on router.
The reported value is now 1. The kernel documentation notes that changing ip_forward resets certain IPv4 configuration parameters to host or router defaults. In a production system, audit the complete network configuration and make intended settings persistent through its configuration manager.
Open client and repeat ping -n -I eth1 -c 3 -W 1 10.71.20.20. Both endpoint routes and router forwarding are now configured. This is the same target and interface used in the earlier failed test.
Use the actual output to compare before and after. Timings vary. A command-entry check only establishes that the expected command was entered on the named host; the final assessment separately tests the resulting state.
machine: client prompt: admin@client:~$ answer: ping -n -I eth1 -c 3 -W 1 10.71.20.20 output: PING 10.71.20.20 (10.71.20.20) from 10.71.10.10 eth1: 56(84) bytes of data. 64 bytes from 10.71.20.20: icmp_seq=1 ttl=63 time=1.41 ms 64 bytes from 10.71.20.20: icmp_seq=2 ttl=63 time=0.952 ms 64 bytes from 10.71.20.20: icmp_seq=3 ttl=63 time=0.917 ms
--- 10.71.20.20 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.917/1.091/1.406/0.222 ms hint: Section 1.5. Send three numeric pings through eth1 to 10.71.20.20.
This capture received all three replies. Their ttl is 63, consistent with a reply starting at 64 and passing one router. A TTL value alone cannot prove the whole path unless the initial TTL is known. The route configuration and endpoint test provide additional evidence.
Open server and run ping -n -I eth1 -c 3 -W 1 10.71.10.10. Starting a fresh exchange from the opposite endpoint checks its source selection and outbound route. A successful client-initiated exchange already required replies, but testing both origins is useful when diagnosing asymmetric policies.
machine: server prompt: admin@server:~$ answer: ping -n -I eth1 -c 3 -W 1 10.71.10.10 output: PING 10.71.10.10 (10.71.10.10) from 10.71.20.20 eth1: 56(84) bytes of data. 64 bytes from 10.71.10.10: icmp_seq=1 ttl=63 time=0.982 ms 64 bytes from 10.71.10.10: icmp_seq=2 ttl=63 time=0.772 ms 64 bytes from 10.71.10.10: icmp_seq=3 ttl=63 time=0.905 ms
--- 10.71.10.10 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2026ms rtt min/avg/max/mdev = 0.772/0.886/0.982/0.086 ms hint: Section 1.5. Send three numeric pings through eth1 to 10.71.10.10.
The captured run received three replies from client. These results describe ICMP on the exercise interfaces. They do not demonstrate transport-port reachability or throughput. Later exercises will use application probes and iperf3 for those questions.
Select the client terminal, then open Topology. Before recording, predict the interfaces where you expect to see the request and reply. Choose Ping & record. It starts capture on client eth1, both router exercise interfaces and server eth1, then sends two pings from the selected endpoint. The From label confirms client or server. Inspecting a different node does not change that source.
Read the ICMP echo request and echo reply lines together. A request visible on client eth1 proves that capture point saw the request. It does not prove that server received it. A corresponding reply is stronger endpoint evidence. Missing packets can also reflect the selected interface, filter, capture window or capture loss.
Open Packets and select an observation to read its capture point, source, destination, TTL, identifier, sequence and original bytes. The recorder includes IPv4 ICMP between the assigned client and server, not ARP or management traffic. Each of the four interfaces stops after ten seconds or 50 packets. A packet seen at several interfaces produces several observations, up to 200 total. The newest eight recordings remain available for up to 24 hours; they are temporary evidence, not permanent course notes. Record next ping opens the same bounded capture window for a ping you type yourself. Stop recording ends that window early.
Topology shows the assigned layout. Its playback highlights actual captured observations in reading order. Step through a request and its reply; compare the addresses and the TTL before and after router. Animation speed is a reading aid, not measured travel time. Guest clocks are not assumed synchronized. A missing observation does not by itself prove a drop. Use Check chapter after capture has finished to verify both endpoint routes, forwarding
Practice Chapter 1. Hosts, routes and packets in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.