RH342 - ch07s04

Bookmark this page

Guided Exercise: Resolving Connectivity Issues

Diagnose and resolve network connectivity issues.

Outcomes

You should be able to diagnose and resolve network connectivity issues on a Red Hat Enterprise Linux 8 host.

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

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

This command configures network interfaces and modifies DNS servers.

Instructions

A second network interface, eth1, was added to the servera and serverb systems. The interfaces are connected to a private network and have the following IP addresses:

servera: 172.24.250.10/24
serverb: 172.24.250.11/24

Users report that the server cannot communicate with each other using the new interfaces. Additionally, DNS is not working on the servera system. The network settings must persist when the machine is rebooted.

Diagnose and resolve the issues you find so that the servera system can ping the eth1 interface on the serverb system, and also resolve the access.redhat.com website by using the 172.25.250.17 DNS server.

[student@workstation ~]$ ssh student@servera
...output omitted...
[student@servera ~]$ sudo -i
[sudo] password for student: student
[root@servera ~]#

Verify the network connectivity issues.

Run the ping command against the IP address of the eth1 interface on serverb. No reply is expected.

[root@servera ~]# ping -c 2 172.24.250.11
PING 172.24.250.11 (172.24.250.11) 56(84) bytes of data.

--- 172.24.250.11 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1059ms

Run the ping command with the access.redhat.com domain name. A "Name or service not known" error is expected.
```
[root@servera ~]# ping -c 2 access.redhat.com
ping: access.redhat.com: Name or service not known
```

Gather network information.

Display the current IP addresses.

[root@servera ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    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 pfifo_fast state UP 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 eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe00:fa0a/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:01:fa:0a brd ff:ff:ff:ff:ff:ff

The eth0 interface is up with an assigned IPv4 address and a link-local IPv6 address. The eth1 interface is also up but does not have any IP addresses assigned to it.

Display the routing information.

[root@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 172.24.250.0/24 network does not have a route, because the eth1 interface does not have an IP address in that subnet.

Display the connection and device information.

[root@servera ~]# nmcli con
NAME                UUID                                  TYPE            DEVICE
Wired connection 1  8c6fd7b1-ab62-a383-5b96-46e083e04bb1  802-3-ethernet  eth0
Wired connection 2  5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  802-3-ethernet  ---
[root@servera ~]# nmcli dev
DEVICE  TYPE      STATE         CONNECTION
eth0    ethernet  connected     Wired connection 1
eth1    ethernet  disconnected  --
lo      loopback  unmanaged     --

NetworkManager has two connections: "Wired connection 1" and "Wired connection 2". The former is assigned to eth0, while no devices are assigned to the latter.

Run the dig command to look for any information regarding the DNS issue.

[root@servera ~]# dig access.redhat.com
; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> access.redhat.com
;; global options: +cmd
;; connection timed out; no servers could be reached

The output indicates that an incorrect DNS server might be configured.

View the configuration of the /etc/resolv.conf file.

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

The IP address of the DNS server is incorrect.

Inspect the connection profiles. Filter the output to the parameters that are expected to be relevant.

[root@servera ~]# nmcli con show "Wired connection 1" | grep dns
connection.mdns:                        -1 (default)
ipv4.dns:                               172.25.250.117
ipv4.dns-search:                        lab.example.com,example.com
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.ignore-auto-dns:                   yes
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.ignore-auto-dns:                   yes
[root@servera ~]# nmcli con show "Wired connection 2" | grep interface
connection.interface-name:              ens1

The "Wired connection 1" profile is configured with an incorrect IP address for its DNS server. The "Wired connection 2" profile is configured with the ens1 interface, which does not exist. Modifying the ipv4.dns parameter of the "Wired connection 1" profile and changing the ifname parameter of "Wired connection 2" should resolve the network connectivity issues.

Repair the eth1 interface issue, and then verify that the systems can communicate.

Modify the ifname parameter of the "Wired connection 2" profile to reflect the correct eth1 interface.
```
[root@servera ~]# nmcli con mod "Wired connection 2" ifname eth1
```

Run the nmcli con up command to activate the connection.

[root@servera ~]# nmcli con up "Wired connection 2"
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)

Verify that the connection is now active with the correct interface.

[root@servera ~]# nmcli con show
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  06d487b0-4ef5-3dcb-8baa-260c6f435574  ethernet  eth0
Wired connection 2  97d45f09-316b-3678-b77d-9a3ef019d835  ethernet  eth1

Confirm that the eth1 interface now has an IP address.

[root@servera ~]# ip addr show eth1
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:0a brd ff:ff:ff:ff:ff:ff
    inet 172.24.250.10/24 brd 172.24.250.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::243:e4c0:38fb:f19e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Verify that the ping command now works.

[root@servera ~]# ping -c 2 172.24.250.11
PING 172.24.250.11 (172.24.250.11) 56(84) bytes of data.
64 bytes from 172.24.250.11: icmp_seq=1 ttl=64 time=1.48 ms
64 bytes from 172.24.250.11: icmp_seq=2 ttl=64 time=0.311 ms

--- 172.24.250.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.311/0.897/1.483/0.586 ms

Repair the DNS issue and verify that you can resolve domain names.

Modify the ipv4.dns parameter of the "Wired connection 1" profile to reflect the correct IP address of the DNS server.
```
[root@servera ~]# nmcli con mod "Wired connection 1" ipv4.dns 172.25.250.17
```
Attempt to ping the access.redhat.com website.
```
[root@servera ~]# ping -c 2 access.redhat.com
ping: access.redhat.com: Name or service not known
```
The error persists because the /etc/resolv.conf file does not change until the interface is restarted.
Restart the NetworkManager service to apply the changes.
```
[root@servera ~]# systemctl restart NetworkManager
```
Note
Normally, an interface is restarted to apply changes. However, in this case the SSH session drops if the interface goes down. Whenever possible, the NetworkManager service keeps connections active as it restarts and applies changes.

Verify that the /etc/resolv.conf file now shows the correct server.

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

Observe the output of a successful dig command. The NOERROR value in the header is expected.

[root@servera ~]# dig access.redhat.com
; <<>> DiG 9.11.26-RedHat-9.11.26-4.el8_4 <<>> access.redhat.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64384
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;access.redhat.com.			IN	A

;; ANSWER SECTION:
access.redhat.com.		2397	IN	A	209.132.183.105

;; Query time: 1 msec
;; SERVER: 172.25.250.17#53(172.25.250.17)
;; WHEN: Tue Oct 26 19:17:40 EDT 2021
;; MSG SIZE  rcvd: 55

Verify that a ping to access.redhat.com resolves the domain name.

Note

A ping to external sites to the classroom might not work. For this exercise, ensure that the domain resolves correctly even if it does not respond to a ping.

[root@servera ~]# ping -c 2 access.redhat.com
PING e259367.dsca.akamaiedge.net (104.93.21.154) 56(84) bytes of data.
64 bytes from a104-93-21-154.deploy.static.akamaitechnologies.com (104.93.21.154): icmp_seq=1 ttl=54 time=6.60 ms
64 bytes from a104-93-21-154.deploy.static.akamaitechnologies.com (104.93.21.154): icmp_seq=2 ttl=54 time=2.59 ms

--- e259367.dsca.akamaiedge.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 2.590/4.593/6.596/2.003 ms

Return to workstation as the student user.

[root@servera ~]# exit
[student@servera ~]$ exit
[student@workstation ~]$

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-resolving

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