Huawei HCIA Network Troubleshooting Explained

Click the blue text above to follow us

Resource Sharing

Huawei Certification Beginner to Advanced Practical Course

↓ Scan the QR code for practical video lessons ↓

Huawei HCIA Network Troubleshooting Explained

1. Essential Conditions for Network Troubleshooting

Why do we need to discuss essential conditions first? Because the network troubleshooting discussed here is not just about using a small command, but rather a systematic approach. Without these conditions, I cannot guarantee that you will understand what follows or apply it in practice. So let’s first look at these foundational conditions.

1. Familiarity with the OSI Seven-Layer Model and TCP/IP Protocol Stack

This is the most basic knowledge required for network troubleshooting.

Whether it is the OSI seven-layer model or the DoD model, both are used to describe the process of network communication, allowing us to have a general understanding of the sending and receiving of network data. The OSI seven-layer model corresponds to the protocols of the OSI model, while the DoD model corresponds to the protocols of the DoD model, which is the TCP/IP protocol stack.

The protocols within the TCP/IP protocol stack are crucial, such as DNS, TCP, UDP, IP, ICMP, ARP. These basic protocols should be known. We do not need to go into the detail as described in “TCP/IP Protocol Stack,” but at least we must know the basic functions of these protocols, which cannot be explained in just a few sentences; you should look them up yourself.

2. Understanding Basic Network Devices and Their Corresponding OSI Layers

Basic network devices like switches, layer 3 switches, routers, and firewalls should be somewhat understood, especially their corresponding OSI layers and functions. For example, a regular layer 2 switch corresponds to the data link layer in the OSI model. It can isolate collision domains while using VLAN technology to isolate broadcast domains. A layer 2 switch forwards data frames using layer 2 addresses, namely MAC addresses; on the other hand, routers correspond to the network layer and can provide routing and addressing functionalities, etc.

3. Understanding the Basic Architecture of Small and Medium-Sized Enterprise Networks

The basic architecture of a typical small and medium-sized enterprise network is as follows: Access Layer — Aggregation Layer — Core Layer — Network Exit.

Here’s a diagram:

If the network environment is relatively large, there will be aggregation and core layers. In this case, there is no aggregation layer, but the concept remains the same. The troubleshooting discussed below is primarily aimed at user PCs, but in fact, network troubleshooting in data centers is quite similar. Regardless of how complex the network environment is, it can usually be simplified to this structure.

4. Knowing Common Network Troubleshooting Commands

If the user is using a Windows operating system, the following commands are very important::

If using a Linux operating system, there are also corresponding commands. Ultimately, it’s about being familiar with the device you are using. Of course, during actual network troubleshooting, if you just want to test whether network communication is normal, you can switch to a device you are familiar with.

5. Clearly Understanding an Important Principle of Network Troubleshooting

Network troubleshooting is about determining where the network has failed, so you must know the direction of data flow.

Thus, an important principle is:Focus on the direction of data flow.

The network troubleshooting approach discussed below essentially narrows down network fault points by tracking the direction of data flow, so it is crucial to always keep this in mind! This is also why you need to understand the basic architecture of small and medium-sized enterprise networks.

II. Basic Ideas of Network Troubleshooting

The basic ideas are as follows, which should be similar to what most people write online.

(1) Check if there are issues with the physical link;

(2) Check if there are issues with the local IP address, routing, and DNS settings;

(3) Test the connectivity of the gateway or router. Test the gateway first, then the router, testing step by step;

(4) Test the connectivity of pinging a public IP address (remember to note a few external IPs);

(5) Test the connectivity of DNS; you can directly ping the website address;

III. Detailed Steps for Network Troubleshooting

To better explain the process and ideas of network troubleshooting, let’s assume we have the following network environment:

(Note: Although this is an assumption, this network environment is actually set up through GNS3 linking virtual machines and real networks, so it can be referenced realistically)

Now, we will use this network environment as an example to detail our network troubleshooting approach, explaining what to do at each step, why to do it, and what information we can gain from it.

1. Check if there are issues with the physical link

This step is, in my opinion, the first step that must be taken in network troubleshooting! I often hear friends say that their boss’s computer cannot connect to the internet, and after troubleshooting for a long time, they find out that the network cable wasn’t even plugged into the computer. That’s truly a tragedy, wasting a lot of time and indicating that the troubleshooting approach was fundamentally flawed.

Since not everyone can go to the server room to check the switch wiring, the following points need to be checked:

1. Confirm if the computer’s network card has issues

2. Confirm if the connected network cable has issues

3. Check the switch the computer is connected to (if you can go to the server room)

If the above checks do not reveal any issues, then it is likely a problem with other devices in the network environment. This range of checks is relatively straightforward as it only involves physical link connections.

For such testing, you can consider using a cable tester, but personally, I suggest using a correctly configured laptop for testing as well.

2. Check if there are issues with the local IP address, routing, and DNS settings

If the first step, checking the physical link, reveals no issues, it means the computer has responded after connecting the network cable, but the network is still down. At this point, attention should shift to the computer’s settings.

In this step, our focus is on::

1. IP Address Settings

If DHCP is used for automatic IP acquisition, then you only need to check if your local settings have enabled automatic IP acquisition and if the related services are running;

If a static IP is used, you must ensure that the IP address is entered correctly (generally provided by the network administrator) and that the subnet mask is correct (this is very important; many people make mistakes here, so it’s advisable to learn about IP addresses and VLSM).

Common commands to check:

2. Routing Settings

For servers and PCs, this generally refers to the default gateway settings; for routers or layer 3 switches, it pertains to static or dynamic routing settings.

3. DNS Settings

It’s crucial to ensure that the DNS server address you set is providing domain name resolution services or if there are any faults. As for how to determine this, methods will be provided later. Here, the focus is on ensuring that you have a correct DNS server address or that it can automatically acquire one. On Windows, you can check using the command below:

3. Test the connectivity of the gateway or router. Test the gateway first, then the router, testing step by step.

In the above network environment, under normal conditions, we can use the command tracert -d on the computer, and we will get the following results:

From this test result, we can clearly see the data flow when the computer accesses the internet:

Based on this data flow, we can derive an important idea, which is to detect the network’s connectivity based on the data flow! Therefore, we can take two steps:

1. First, test the connectivity from the computer to the gateway 192.168.2.254.

We can ping the gateway address from our computer to see if there is a response.

This method of judgment is generally quick, but sometimes you may not get any response regardless of how you ping; in that case, there could be several situations:

a. The gateway device has ping restrictions set.

b. The gateway interface or device has a fault.

For a, it is generally rare to set ping restrictions on these devices, as there is usually no significant need to do so, except in cases where network security requirements are very strict. After successfully pinging the gateway at 192.168.2.254, we should also ping 172.16.13.1 to confirm that there are no issues between the computer and the entire gateway device.

For when ping fails, I personally recommend executing the following operation on the computer:

This means checking whether the computer has obtained the MAC address of the gateway. Clearly, if there is no MAC address for the gateway, it will be impossible to ping the gateway. After ruling out the previous computer settings, you can suspect that the gateway device has issues, and at this point, you can contact the network engineer to test the gateway device.

2. Test the connectivity to other routers.

If the previous step shows no issues, meaning the communication from the computer to the gateway is normal, we can then test the connectivity from the gateway to the exit router:

Here, we can use the command tracert -d:

Of course, if it turns out to be unreachable, then the following situations may occur:

a. There are physical link issues between the gateway device and the router.

b. There are configuration issues between the gateway device and the router, such as routing protocols, interface configurations, etc.

If any of the above situations arise, it becomes a problem for the network engineer. Of course, if you are the network engineer, you should immediately check the device status to see if there are any issues.

Once the above steps are completed, assuming your exit router settings are correct, such as NAT and default routing settings, we can generally conclude that internal network communication is functioning properly (at least your computer and the exit router can communicate without issues), and we need to check if the computer can access the internet.

4. Test the connectivity of pinging a public IP address

At this point, it indicates that the previous three steps have no issues, meaning that local area network communication is normal. What we need to do now is determine if there are any issues with communication between the local area network and the external network (public network):

Here, we directly ping a public address to eliminate the influence of DNS (in case your DNS settings have issues). As for which public address to ping, I personally suggest pinging some public DNS server addresses that do not restrict pings, such as 114.114.114.114 and 8.8.8.8:

After this, you can generally determine that the network is functioning properly. Of course, this does not take into account the presence of a firewall at the exit; in practice, the approach remains the same, but you need to consider whether your access data has been filtered out by the firewall, whether it was filtered when the data was sent out or when it was returned. Since this also involves firewall settings, I won’t elaborate further, but just keep this in mind.

5. Test the connectivity of DNS; you can directly ping the website address

As the title suggests, you can directly ping the website address to see if the IP address returns a response. Whether it is reachable is another matter; as long as you can get a response from the IP address, then the DNS is functioning properly. However, I still want to mention the nslookup command, which is a very useful command that I frequently use during network troubleshooting:

You can also use it in the following way:

Using the nslookup command serves two purposes:

1. To help you test if the DNS server you set has issues.

2. Under the assumption that the DNS server is not intelligent, you can roughly judge the quality of the DNS server based on the speed of the returned IP address.

Therefore, make full use of the nslookup command.

Source: Network, infringement deletion

Course inquiries add: HCIE666CCIE

↑ Or scan the QR code above ↑

If you have any technical points or content you want to see,

please leave a message below to let us know!

Related posts

Leave a Comment Cancel reply