RH342 - ch07s07

Bookmark this page

Lab: Troubleshooting Network Issues

Identify and correct the misconfigured network settings of a server.

Outcomes

You should be able to diagnose and repair network configuration issues that cause a network service to be unavailable.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

[student@workstation ~]$ lab start network-review

This command creates the necessary files to perform this lab.

Instructions

A web server on serverb publishes content at the URL: http://serverb.lab.example.com.

The original network specifications for the serverb web server are not available. The network team properly configured the DNS entry for serverb on their name servers. Diagnose and fix the network configuration on serverb to ensure that the web content is available at the given URL. Verify that the network fixes are persistent.

Important

Because this exercise introduces network problems, you might lose ssh connectivity to the virtual machine that you are fixing. Therefore, this lab instructs you to log in directly to the system console for the serverb system when creating and resolving this problem. All Red Hat Training delivery modes provide direct access to classroom virtual machine consoles.

As the root user on the serverb system console, run the net-trouble-issue command to create the problem to troubleshoot.
Using the correct method for your classroom environment, access the serverb system's text console. Log in on the serverb console as the root user with redhat as the password.
serverb login: root password: redhat ...output omitted... [root@serverb ~]#
As the root user on the serverb system console, run the net-trouble-issue command.
[root@serverb ~]# net-trouble-issue
In a new terminal window on the workstation machine, verify that you cannot access the serverb.lab.example.com URL by using the curl command.
```
[student@workstation ~]$ curl serverb.lab.example.com
curl: (7) Failed to connect to serverb.lab.example.com port 80: No route to host
```

As the student user on the servera system, discover which public IP network settings are expected for the serverb system.

[student@workstation ~]$ ssh student@servera
[student@servera ~]$

Discover the expected public IPv4 address of the serverb machine.

[student@servera ~]$ host serverb.lab.example.com
serverb.lab.example.com has address 172.25.250.11

Identify the expected IPv4 netmask, knowing that workstation, servera, and serverb are on the same subnet.

[student@servera ~]$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:00:fa:0a brd ff:ff:ff:ff:ff:ff
    inet 172.25.250.10/24 brd 172.25.250.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2c1:1c11:1485:3f4c/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

The netmask is /24.

Identify the gateway, knowing that workstation, servera, and serverb must use the same gateway.

[student@servera ~]$ ip route
default via 172.25.250.254 dev eth0 proto static metric 100
172.25.250.0/24 dev eth0 proto kernel scope link src 172.25.250.10 metric 100

The default gateway is 172.25.250.254.

Determine the DNS name server that the serverb machine can use, knowing that workstation, servera, and serverb use the same name server.

[student@servera ~]$ cat /etc/resolv.conf
# Generated by NetworkManager
search lab.example.com example.com
nameserver 172.25.250.254

Diagnose and fix the network issue on the serverb machine.

You should already be logged in to the serverb system console as the root user. Display the current network settings to identify the number of network interfaces and their configuration.

The eth0 interface has an incorrect IP address.

[root@serverb ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:00:fa:0b brd ff:ff:ff:ff:ff:ff
    inet 172.25.251.11/24 brd 172.25.251.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8e80:72dc:3b82:55e7/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8942 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:01:fa:0b brd ff:ff:ff:ff:ff:ff

Determine the NetworkManager connection names for the two physical network interfaces.

[root@serverb ~]# nmcli conn
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  df120ee2-aded-3ef7-9ff9-9f33c48c9043  ethernet  eth0
Wired connection 2  433d347a-dceb-3549-a86e-981b863bd5d2  ethernet  --

Depending on your system configuration, the output might display both eth0 and eth1 device names.

Display the IPv4 NetworkManager settings for Wired connection 1.

The DNS server settings look correct, but the network interface is configured for the wrong subnet. It must be configured for the network information that you discovered previously.

[root@serverb ~]# nmcli conn show 'Wired connection 1' | grep ipv4
ipv4.method:                            manual
ipv4.dns:                               172.25.250.254
ipv4.dns-search:                        lab.example.com,example.com
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         172.25.251.11/24
ipv4.gateway:                           172.25.251.254
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   yes
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-reject-servers:               --

Copy the interface configuration files into the root home directory as a backup before making changes.
```
[root@serverb ~]# cp /etc/sysconfig/network-scripts/ifcfg-* .
[root@serverb ~]#
```

Modify the network connection for the eth0 device.

[root@serverb ~]# nmcli conn mod 'Wired connection 1' ipv4.addresses '172.25.250.11/24' ipv4.gateway 172.25.250.254
[root@serverb ~]#

Verify the new settings.

[root@serverb ~]# nmcli conn show 'Wired connection 1' | grep ipv4
ipv4.method:                            manual
ipv4.dns:                               172.25.250.254
ipv4.dns-search:                        lab.example.com,example.com
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         172.25.250.11/24
ipv4.gateway:                           172.25.250.254
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   yes
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.dhcp-reject-servers:               --

To implement the new configuration, deactivate the 'Wired connection 1' profile, and then reactivate it. The active configuration number will change.

[root@serverb ~]# nmcli conn down 'Wired connection 1'
Connection 'Wired connection 1' successfully deactivated (D-Bus active path:
 /org/freedesktop/NetworkManager/ActiveConnection/645)
[root@serverb ~]# nmcli conn up 'Wired connection 1'
Connection successfully activated (D-Bus active path:
 /org/freedesktop/NetworkManager/ActiveConnection/676)

Verify that the network configuration settings are correct.

[root@serverb ~]# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:00:fa:0b brd ff:ff:ff:ff:ff:ff
    inet 172.25.250.11/24 brd 172.25.250.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::8e80:72dc:3b82:55e7/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Take any further needed steps to ensure access to the web service content, including to verify the firewall and the web server's systemd service.
Verify that the HTTP and HTTPS services are present in the firewall services list.
[root@serverb ~]# firewall-cmd --list-services cockpit dhcpv6-client http https ssh
As the student user on the servera machine, verify that web content is available from the serverb machine.
[student@servera ~]$ curl http://serverb.lab.example.com SERVERB is providing web content.
Return to the workstation machine as the student user.
[student@servera ~]$ exit [student@workstation ~]$

Evaluation

On the workstation machine, use the lab command to grade your work. Correct any reported failures and rerun the script until you receive a passing grade.

[student@workstation ~]$ lab grade network-review

Important

After successful grading, you must run the net-restore-exercise command on the serverb machine to ensure that the finish script runs successfully. Use the direct serverb console, not ssh, to access the serverb system.

As the root user on the serverb system console, run the net-restore-exercise command, before running the lab finish command on the workstation system.

[root@serverb ~]# net-restore-exercise

Finish

On the workstation machine, use the lab command to complete this exercise. This is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish network-review

Discuss Red Hat Enterprise Linux Diagnostics and Troubleshooting

Go to community

Welcome to the Red Hat Enterprise Linux Diagnostics and Troubleshooting (RH342) group!

cschunke

26 wrz 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat Enterprise Linux Diagnostics and Troubleshooting! To gain the most value from this group - click the "Join Group" button in the upper right hand corner of the group home page.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to RH342.Read more about Red Hat Enterprise Linux Diagnostics and Troubleshooting here.

445

Revision: rh342-8.4-6dd89bd

Click Create to build all of the virtual machines needed for the classroom lab environment. This may take several minutes to complete. Once created the environment can then be stopped and restarted to pause your experience.
When a lab is created, click Start to run all of the virtual machines in the classroom.
Click Stop to stop all the virtual machines from running. This will not delete your lab.
If you Delete your lab, you will remove all of the virtual machines in your classroom and lose all of your progress.

Virtual machine actions

Click Start to power on the virtual machine.
Click Shutdown to gracefully shut down the virtual machine, preserving disk contents.
Click Power off to forcefully shut down the virtual machine, while still preserving disk contents.
Click Open console to connect to the system console of the virtual machine in a new browser.

Auto-stop timer

The Red Hat Learning Subscription entitles you to set allotment of lab time.
To help conserving your allotted time, the lab environment uses automatic timers to stop or destroy your lab environment when the timer expires.

Click the Auto-stop button [+] to extend the time you would like to spend with the labs.
Click the Auto-destroy button [+] to add day(s) to the auto-destroy timer.

Auto-stop has a maximum of 11 hours, and auto-destroy has a maximum of 14 days.
Be careful to keep the timers set while you are working, so that your environment doesn't shut down unexpectedly.
We also suggest not to set the auto-timers unnecessarily high, which could waste your lab time allotment