Lab 11.2 Why are both addresses added to the static route configuration?
I'm finding this lab particularly difficult because I'm unclear of which IP addresses to use at each step.
- The first point of confusion is whether this command is required?
Where X and Y are unique to the lab/classroom.
# ip addr add ADDRESS/24 dev eth0
The lab does not state why this is necessary so I've made an assumption that it's not required if we use the existing IP addr of the device.
Using the following known properties for devices on separate networks (and assuming VLAN has been configured for the interface)
Device X
Interface wlan0
IP addr 10.1.1.4/24
Gateway 10.1.1.1
External IP 111.112.113.114
Device Y
Interface eth0
IP addr 192.168.7.9/24
Gateway 192.168.7.9
External IP 221.222.223.224
- Configuration of the static route
The lab solution shows two entries. Are both entries required on each environment?
# /etc/network/interfaces # Device X - Debian up route add -net 192.168.7.9/24 gw 221.222.223.224 dev wlan0
# /etc/sysconfig/network-scripts/route-INTERFACE # Device Y - Fedora 10.1.1.4/24 via 111.112.113.114 dev eth0
- Restart networking services and test
Fedorasystemctl restart network
Debian - this is different to what's specified in the labsystemctl restart network-manager
I'm not in the position to be able to test this because of a lack of access to devices, some validation would be great ![]()
Best Answer
-
1/2 or one half of a pair, yes. We commonly use multiple VM's for testing however not everyone has a machine capable of running several VM's at once. Use of VM's is a suggestion.
5
Answers
-
Gro 108, Thank you for your input,
1/ (11.1) Additional addresses are used in this lab to demonstrate VLAN tagging and static routes while not disturbing the active network configuration. This avoids typing errors that make systems unreachable.
2/ (11.2) This exercise creates routes from two networks to another system, so yes there needs to be a route for each subnet.
Looking at your routes:up route add -net 192.168.7.9/24 gw 221.222.223.224 dev wlan0
Says: When packets for the subnet 192.168.7.0/24 arrive route them via the 221.222.223.224 system accessible via eth0.
10.1.1.4/24 via 111.112.113.114 dev eth0
Says: When packets arrive from network 10.1.1.0/24 route them to 111.112.113.114 system on eth0.
/3 The systemctl command will be corrected, thank you for noticing.Using two systems is a little easier than making sure it works with one system. Here is a two system example.

Lee
1 -
Thanks Lee, that's a lot clearer to me now.
I was so focused on outbound traffic that I had completely overlooked the need for the inbound routing (in fact the inbound direction doesn't get much of a mention in any documentation, it's common sense sure but when you're swimming in new information it's easy to miss
)Regarding my question about the route definitions
The lab solution shows two entries. Are both entries required on each environment?
By this I meant for does each config file require two entries - one for ingress and one for egress traffic?
Your answer and the diagram show only one but the Lab solution shows two.
Just so I am absolutely clear - when defining the route do we need to separate the ingress and egress traffic? Or does a single address work for both ways?Do I need to update my solution to be the following so it includes the egress route?
# /etc/network/interfaces # Device X - Debian up route add -net 192.168.7.9/24 gw 221.222.223.224 dev wlan0 # ingress traffic up route add -net 10.1.1.4/24 gw 221.222.223.224 dev wlan0 # egress traffic? - is this required?
# /etc/sysconfig/network-scripts/route-INTERFACE # Device Y - Fedora 10.1.1.4/24 via 111.112.113.114 dev eth0.7 # ingress traffic 192.168.7.9/24 via 111.112.113.114 dev eth0.7 # egress traffic? - is this required?
Thanks again
-1 -
One common trap is not being specific when setting up static routes, so making sure you define clear paths is important. What I see happening is we define 1/2 of the routing pair, ingress/egress as you mentioned. So, from home network to target network and target network to home network there must be a pair for each network. Now if there is only 1/2 of the pair then the default route will take over (if one is defined) and unexpected results will occur.
Note: This OPTIONAL challenge that goes way beyond the default setup for class and is presented here for the curious.
As a challenge, add another machine that is only connected to (my example) the 192.168.42.0/24 network, no other adapters. The "challenge system" should be accessible from "your system" and the "challenge system" should be able to browse the internet through the network provided by Hypervisor. My hypervisor is KVM using the 192.168.122.0/24 network.
0 -
Thanks @lee42x, the realisation that the route definitions handle inbound/outbound traffic was a big one for me. Thanks for guiding me there. It also makes me realise how great DHCP is

Am I right to interpret "1/2" as "1 of 2"?
Re: the challenge - is the use of a VM/hypervisor required or only mentioned to provide a possible implementation when only one system is available?
-1
Categories
- All Categories
- 177 LFX Mentorship
- 177 LFX Mentorship: Linux Kernel
- 754 Linux Foundation IT Professional Programs
- 374 Cloud Engineer IT Professional Program
- 170 Advanced Cloud Engineer IT Professional Program
- 74 DevOps IT Professional Program - Discontinued
- 5 DevOps & GitOps IT Professional Program
- 100 Cloud Native Developer IT Professional Program
- 7.6K Training Courses & Learning Paths
- 2 AI & ML Training
- 1 Blockchain & Decentralized Identity Training
- 5 Cloud & Containers Training
- 1 Cybersecurity Training
- 2 DevOps & Site-Reliability Training
- 1 Linux Kernel Development Training
- 1 Networking Training
- 2 Open Source Best Practice Training
- 2 System Administration Training
- 1 System Engineering Training
- 1 Web & Application Development Training
- 794 Hardware
- 202 Drivers
- 68 I/O Devices
- 37 Monitors
- 95 Multimedia
- 173 Networking
- 91 Printers & Scanners
- 89 Storage
- 769 Linux Distributions
- 81 Debian
- 68 Fedora
- 22 Linux Mint
- 13 Mageia
- 24 openSUSE
- 150 Red Hat Enterprise
- 31 Slackware
- 13 SUSE Enterprise
- 356 Ubuntu
- 465 Linux System Administration
- 31 Cloud Computing
- 73 Command Line/Scripting
- Github systems admin projects
- 98 Linux Security
- 78 Network Management
- 101 System Management
- 46 Web Management
- 111 Mobile Computing
- 19 Android
- 77 Development
- 1.2K New to Linux
- 1K Getting Started with Linux
- 393 Off Topic
- 121 Introductions
- 182 Small Talk
- 29 Study Material
- 976 Programming and Development
- 310 Kernel Development
- 648 Software Development
- 990 Software
- 382 Applications
- 182 Command Line
- 5 Compiling/Installing
- 68 Games
- 317 Installation
- Archived
- 2 LFD140 Class Forum
- 1.4K LFS258 Class Forum
Upcoming Training
-
August 20, 2018
Kubernetes Administration (LFS458)
-
August 20, 2018
Linux System Administration (LFS301)
-
August 27, 2018
Open Source Virtualization (LFS462)
-
August 27, 2018
Linux Kernel Debugging and Security (LFD440)
