Given a scenario, troubleshoot common router and switch problems. This chapter covers different issues that might appear during router and switch configuration and operation processes, including switching loops, improper cables, port configuration, VLAN assignment, power failure, missing routing information, duplicate IP addresses, and wrong DNS servers. Learn more in our Cisco CCNA 200-301 video course.

Back to book index.

Troubleshooting Switching Loops

Most Layer 2 issues are related to some kind of loop within the domain and this has multiple problems associated with it, including network downtime. Often when you are working with switch configurations and you are plugging/unplugging a device, you should be careful that you don’t create a network traffic loop. To mitigate such problems, you should usually configure Spanning Tree Protocol on switches to avoid situations that might occur if you happen to accidentally create a loop somewhere in the network. Details about Spanning Tree Protocol functionality can be found in Chapter 4.

Every switch in a network communicates using MAC addresses. As packets come in, the MAC address is analyzed and the switch determines where that packet goes based on the destination MAC address in the Layer 2 header. Every device in the network has its own MAC address so all the packets have a specific destination. Unfortunately, things like Broadcasts and Multicasts go to every port on the switch. If a Broadcast frame arrives at a switch port, it copies that Broadcast to every other device that might be connected to that switch. This process can often be a problem when there are loops in the network.

You should also keep in mind that the MAC address packets have no mechanism inside of them to time out. With TCP/IP, the IP protocol has a function called Time To Live (TTL) in its header, which refers to the number of hops through a router, not to a specific unit of time. If IP packets happen to be in a loop and go through multiple routers, they will eventually time out and be removed from the network. On the other hand, switches do not offer that kind of mechanism. Layer 2 frames can theoretically loop forever, as there is no mechanism to time them out. In other words, if a loop is created, it will be there until it is manually removed from the network.

If you are simply plugging in one workstation to the network and a Broadcast reaches it, it will terminate at that point and will not be a problem for the network. On the other hand, if you misconfigure a port configuration on the switch side, or you plug both ends into a switch without enabling STP, this might lead to a Broadcast storm within the Layer 2 domain. When this happens, Broadcast packets are forwarded to all other ports so the Broadcast packet keeps exiting and entering the switch on the same cable, causing a Layer 2 loop. This can lead to high resource usage and even network downtime.

If you enable STP on such a misconfigured network, the switch will recognize that a loop has occurred and it will block certain ports to avoid Broadcast storms. Every other port on the switch continues to operate normally so the network is not affected. If STP is not configured, the only options would be to unplug the network cable that is causing the problem or administratively disable it if you can still operate the switch at that moment.

Troubleshooting Cabling Issues

Troubleshooting cabling issues (Layer 1 troubleshooting) can sometimes be a very easy process because you can directly see and inspect the cable. However, sometimes cabling problems are invisible, in which case you will have to engage in a systematic troubleshooting process to make sure that the problem is really localized at Layer 1.

Sometimes you simply plug in a cable but get no connection, so you may want to troubleshoot the cable itself. You might run into cases where you plug in the cable and have a connection but there is very low throughput on that connection. You might also encounter a situation where everything is working normally and then suddenly the connection goes away, and then the connection might come back and go away again. This flapping is most likely due to Layer 1 issues. All of these issues point toward some kind of problem with the actual cables, so you should begin a physical troubleshooting process by properly testing all cabling to confirm and fix these issues before engaging in a complex infrastructure implementation.

If you are not getting any kind of connectivity, including any link light, this might indicate a physical problem with the cable. It should be carefully examined and replaced if needed. Some of the recommended tests include the following:

• Verifying that the switch link light is on
• Verifying that the cable is punched correctly
• Verifying that the cable connectors are not faulty (you might need to use other connectors)
• Verifying that the wires are pinned in the correct order (if using copper cables)

To ensure that you are not dealing with a cabling issue, one of the simplest things to do is to replace the cable and run the same tests again.

If you plugged in a cable and the throughput over it is less than expected, check the devices link light; if it is off or is turning on and off intermittently, you may have a physical problem with the cable, such as a damaged cable or connectors. If this is the case, you should replace it and test the connection again.

If you have intermittent connectivity, where it seems to work fine but the signal gets lost from time to time, confirm that the NIC or switch link lights associated with that link are turning on and off repetitively. If that is the case, you might have signal degradation due to a very long cable that spans across two buildings or across two distant rooms. This might also happen if the cable is damaged, so you should consider replacing it.

To summarize, a common solution to all the problems above is to replace the cable suspected of being damaged. This is very easy to do and might help to fix the issue immediately without investing a lot of  time and resources in the troubleshooting process.

Note:     Sometimes even brand new cables can come with a defect, so do not assume that a new cable should function as expected 100% of the time.

Troubleshooting Port Configuration

Each networking device can be configured in different ways. Most types of misconfigurations generate problems within the network, including:

• Poor throughput
• Lack of connectivity

A device can be connected to the network, have a signal, and also be able to communicate to the Internet and to other devices but the performance might be low, in a consistent and easily reproducible way. This can manifest during normal operations, including file transfers or other types of communications with the rest of the network.

When experiencing major configuration issues, the issue might manifest as a complete lack of connectivity, including no link lights on the specific device ports. Sometimes the link lights are on but you still lack any kind of connectivity. This shows that signals are passing through the cable, which indicates that you don’t have a cabling issue but, rather, a port configuration issue on one port or the other. This problem requires an investigation of the device configuration.

There are a number of different settings to consider when configuring a port, such as:

• Speed
• Duplex
• Encapsulation/VLAN

Most of these parameters have to be synchronized on both sides of the link, either by manually configuring them or by enabling port auto-configuration. If detected, this method will send negotiation packets on the link to each device to detect the capabilities on the other end device and commonly agree on the best possible parameters supported by both devices to ensure an optimal transmission. The problem is that sometimes auto-configuration does not select the best parameters, so you should verify this and manually configure the ports according to each specific case.

If you are performing manual configuration on each port, one of the first parameters you have to take care of is the interface speed. This has to be identical on both sides of a link. If you configure it incorrectly on one side, the link might not be operational. Another related setting is port duplex, which can be configured to be either half-duplex or full-duplex. You can configure a link with half-duplex on one side and full-duplex on the other side and even though the link will come up, the throughput will be highly affected because each side is expecting to handle communication in a different way. This will result in collisions that will affect transmission on that particular link. Make sure that both sides use the same duplex settings so that traffic can be sent as efficiently as possible.

If you are operating in an enterprise-level environment, you might need to use different VLANs to segment the traffic. Each switch must be properly configured in this regard so that each switch port is assigned to the correct VLAN.

By examining all the port configuration options presented above and making sure that you have everything synchronized on both ends of a link, you can be sure that the connectivity and throughput of the configured devices will be optimized.

Troubleshooting VLAN Assignment

Networks in small environments are relatively easy to manage because only a limited number of features need to be implemented to achieve the business’s goals. However, in an enterprise environment you will not be using small workgroup switches and SOHO devices but, rather, high-end devices that are capable of optimizing traffic flow by offering a number of advanced functionalities.

One particular feature that might be configured in such an environment is logically separating different network areas using VLANs. Problems can appear when you have configuration issues related to a particular VLAN and this can become difficult to troubleshoot. One way of doing this is to analyze the entire configuration on the switch to identify the problem.

VLAN-related problems are usually detected by observing a lack of connectivity between network machines (e.g., a user cannot ping a server), even though Layer 1 seems to be operating without problems. One important characteristic of VLAN-related problems is they do not generate any performance degradation on the network. If you misconfigure a VLAN, the connection will simply not work, especially considering that VLANs usually separate IP subnets so that only devices within the same VLAN will be able to communicate with each other.

The first step in troubleshooting VLAN problems is to review the documentation and the logical diagrams developed in the design phase so you can identify the span area for each VLAN, including the associated devices and ports on each switch. The next step is to inspect each switch configuration to try to find the problem by comparing them with the documented solution.

You should also verify the IP addressing scheme. If you are statically assigning IP addresses to devices, we may want to go back and check the device to be sure that it has the proper IP and subnet mask combination. If there are any mistakes in the IP addressing scheme, such as configuring devices on the wrong network or with a wrong subnet mask/default gateway, then you will have connectivity problems, even though you have the correct VLAN configured on the switch.

You also want to confirm that the trunk configuration on the switches is correct. If there are multiple switches, they usually have uplinks between them and the VLANs are carried across those uplinks. These inter-switch links are often configured as trunks to allow communication across multiple VLANs. The VLAN has to be a member of the trunk group so that data can be sent from one switch to the other. You also have to make sure that the switch configuration on both sides is set up properly.

If you move a device to another VLAN, you will have to make the change on both the switch and the client itself because it will now have a different IP address in a different IP subnet. If you follow all of these VLAN troubleshooting methods, you can be sure that when you plug in devices for the first time or move them from VLAN to VLAN you will have exactly the connectivity desired.

Troubleshooting MTU Issues

A maximum transmission unit (MTU) represents the maximum size an IP packet can be to traverse the network from one end to the other without the need to fragment it as it passes through different network devices. Networks are very diverse and use different media types, ranging from wired to wireless technologies. Each one of the different topologies and network types can use different frame types. If you have a very large frame traversing through the network and it reaches an area that does not support the size of the frame, it will be split up into smaller pieces in a process called fragmentation.

The fragmentation process involves some overhead because the packet has to be processed, divided into small pieces, and sent to the other side. The receiving end must wait for all the pieces to be received and then re-assemble the packet, a process that also takes time and resources. Because it slows things down, you should try to avoid fragmentation when designing and configuring the network. The main disadvantages of packets being fragmented include the following:

• Requires extra overhead
• Losing a fragment leads to losing the entire packet

Some applications can set a flag inside the packet (in the Don’t Fragment – DF – bit) so the devices along the path will see this and avoid fragmenting that specific packet. If the device cannot pass the packet further without fragmenting it, it will discard the packet because of the flag.

There are many automated ways in which systems can determine the best possible size for an MTU, but these mechanisms do not always produce good results because they are based on analyzing the end-to-end path capacity using ICMP, which is often filtered on the network for security or management purposes. Because of this possibility, the troubleshooting process becomes more complex, as it is difficult to know the size of an MTU all the way through the path to the destination.

An Ethernet frame is built starting with the Data field, which is formatted based on the protocol used, for example, TCP. The maximum size of the data portion (payload) that can be used inside an Ethernet frame is 1500 bytes, but it generally should not exceed 1460 bytes because you also need to account for Layer 2 and Layer 3 headers. The next step in building the packet is adding a TCP and an IP header of 20 bytes each. To be able to send the data out, you need 1500 bytes of IP information. In addition, you should also count the Layer 2 header and trailer, which might make the packet larger than 1500 bytes. This may cause issues on networks that cannot handle frames larger than 1500 bytes, so the solution would be to fragment the packet. An example of this Ethernet frame is shown in Figure 12.1 below:

Figure 12.1 – Ethernet Frame Components 

A possible workaround to avoid packet fragmentation is configuring the systems so they do not send so much data in a single packet. Depending on the type of network connections and encapsulation methods used, you should perform a precise calculation of the size of the Layer 2, Layer 3, and Layer 4 headers to figure out the maximum size the data portion can be to keep the frame lower than 1500 bytes.

Note:     Another case in which the frame can become larger than 1500 bytes is when using tunneling techniques that add an additional IP header on top. You should also consider this when calculating the maximum size of the data portion.

The MTU size is generally configured on a router or some other network device and it does not change often. Once you configure a link and set up an MTU, chances are that this will be stable for a long time, so as soon as you figure out the optimal MTU value, you can forget about this topic.

Most of the MTU-related problems are caused by tunneled connections, as many modern networks use some kind of tunneling technology that adds additional headers and trailers to an existing packet.

In situations in which packets contain the DF bit, network devices will not be able to do any kind of fragmentation, so if the packet is too large it will send back an ICMP packet to the originating station. The ICMP packet informs the sender that the packet could not be fragmented and suggests that the application send a smaller packet. Unfortunately, this may not always happen, especially when the connection endpoints are far away because ICMP is often filtered in different areas of the network for security reasons. This will make the troubleshooting process even harder, so you have to keep in mind all the possible consequences of setting improper MTU values.

In order to troubleshoot networks on which ICMP is blocked, one way to find out possible MTU bottlenecks is to use an extended ping test, which lets you manually set up different options, like the length of the packet or an option that prevents it from being fragmented. This process allows you to figure out what area of the network is causing problems with that packet size. The extended ping command format on different operating systems is as follows:

• Windows: ping –f –l <packet length> <destination IP address>
• OS X: ping –D –s <packet length> <destination IP address>

Note:     The -f and -D keywords in the commands presented above set the Don’t Fragment bit in the packet so that network devices know how to process it.

The recommended solution for this problem is to start with a high packet size (e.g., 1472) and decrease it if the ping is not successful to figure out the maximum packet size that can reach the destination. Depending on the results of the extended ping tests to various points in the network, you can relate them to the packet size the application uses and perform a deep analysis to figure out what exactly is causing the problem.

By looking at the fragmentation process, understanding the path of the traffic, and using some of the basic troubleshooting techniques presented above, you can optimize exactly the path and the size of the packets you can send to ensure that the applications will be able to communicate as expected across the network.

Troubleshooting Power Failures

Power failures are relatively straightforward to identify because an entire group of network devices will not be accessible. This is very easy to troubleshoot in person because the device lights are off and the fans are not spinning. However, if direct access to the data center is not possible and you have to investigate the issue from a remote site, power failure issues can become more difficult to troubleshoot.

There are a number of different things you should keep in mind when dealing with power outages:

• The source of the power in the building
• The power circuit’s load
• The level of redundancy for the building’s power supply system (depending on how critical the data center/devices are)
• The power capacity correlated to the devices’ power consumption
• The device power supplies’ proper functionality
• The device power supplies’ backup

If the environment is too complex, you should perform an audit (possibly with a licensed electrician) to find out the exact power sources and all the other parameters mentioned above to simplify the troubleshooting process for power-related issues.

If you have a situation where the power supply is failing or the power source is not very reliable, you may have problems where the device is intermittently and randomly available over a long period of time. This makes the troubleshooting process even more difficult.

One common way to prevent power failure problems is to ensure that an uninterruptible power supply (UPS) system has been installed, which will sustain the devices’ power requirements for a limited time until the main power system is restored. UPS systems can be scaled based on the protection needed. They can back up a single device, an entire rack, or an entire building, and they can run on batteries or by complex power generators.

With many enterprise-level network devices, you also have the option to install additional power supplies into the same chassis, meaning you can plug in a different power source into each power supply, thus ensuring complete power redundancy. If one of the power sources fails, the second one will be activated and the device will continue functioning at full power. This type of redundancy can ensure that any type of power source problem will not affect network functionality.

In order to have a predictable and manageable environment, you should always monitor how much power network resources are using. This can be done using special tools that provide measurements and statistics on different network locations. They can also provide interesting outputs, including peak power statistics for each device and possible oversubscription, which will help adapt the power supply system to the needs of the network.

By taking advantage of all the techniques presented above, you can ensure that the power going into the network devices will provide the maximum uptime.

Troubleshooting Routing Issues

When configuring routing on network devices, you have to carefully configure static or dynamic routing based on the design. If you have a problem and are not able to send/receive traffic across the network, you probably have some kind of configuration issue.

When you initially set up a router, there will most likely be some type of configuration problem that you will have to troubleshoot. If the router has been running for a while and there is suddenly a complete failure of traffic (i.e., no communication), you should analyze the situation and figure out whether the routing protocol is functioning as expected.

Sometimes certain routes might intermittently disappear from and appear in the routing table, causing intermittent connectivity to specific destinations. This may be because a certain network area has some kind of communication problem and routers along the path propagate new routing information every time that area becomes accessible. This process is called route flapping and specific routes can be blocked using a feature called route dampening so that they do not affect the entire network.

Note:     When using static routing, the routing table never changes so you will never know about problems that occur in different network areas.

When troubleshooting routing issues, the standard approach is to follow the routing table for every route along the path. You might want to perform a traceroute to understand exactly where the packets are going and to see routers along the path. This should point to the devices that are causing the issues, so you can start investigating the routing tables on those specific routers.

A common mistake when performing this kind of troubleshooting process is investigating the issue in a single direction (e.g., source to destination). Instead, you should perform the troubleshooting process in both directions because you might come across situations in which packets are blocked in a single direction so there is no return traffic from the destination to the source. The routing tables on devices along the path between two points should correctly point in both directions to ensure an optimal traffic flow.

Often you will be using connections provided by third parties, so if you want to troubleshoot issues in that area, you should communicate with the service provider and synchronize the troubleshooting effort. This includes sharing routing table information.

Using dynamic routing protocols makes the troubleshooting process easier because you can inspect the routing updates as they are sent and received by the router. This can be done via packet captures or internal device mechanisms, which can point out how and when the routing table is populated. Having a topology map and other documentation that lists where every prefix is located in the network can further help your understanding of the routing updates and can shorten the troubleshooting process.

The general idea in such a troubleshooting process is deciding which path a specific packet should take, based on the network design, and investigating where exactly it is deviating from this path.

Different tools can be used to monitor network devices. A common network management protocol used by these tools is Simple Network Management Protocol (SNMP), which was designed to query network devices for different parameters from a management station. In addition to the standard “health” parameters checked (e.g., CPU, memory, disk space, etc.), SNMP can also query the router for things like:

• Interface packet counters
• Bandwidth used and throughput
• CRC or other types of errors on device interfaces
• Routing table information

Other types of tools that you can use are standard ping and traceroute utilities to verify end-to-end connectivity. They can also show relevant output that might help determine the point in the network where problems are occurring.

By properly configuring the routers in your network, documenting each step along the way, and constantly monitoring the path between different points in the network, you should have a solid understanding of exactly how the traffic should traverse all the devices in the network.

Troubleshooting Module Issues

Most routers and switches used in an enterprise network offer not only copper port connectivity but also dedicated ports that can be populated with different kinds of transceivers. These transceivers are usually used for fiber connectivity but there are also copper-compatible transceivers.

Fiber connections may run over very long distances and generally those particular ports are modular and require a compatible SFP (small form-factor pluggable transceiver), like the one presented in Figure 12.2 below:

Figure 12.2 – SFP Module 

Although they look similar, depending on the type of connectivity you use, the appropriate SFP model for use should be based on the following parameters:

• Type of media: optical fiber or copper
• Fiber type: single-mode or multi-mode
• Bandwidth
• Wavelength
• Core size
• Modal bandwidth
• Operating distance

Note:     When purchasing transceivers for your network, you should always check the compatibility between the device ports, type of module, and type of fiber used.

Transceivers can be plugged into and unplugged from a network device (e.g., switch, router, firewall, etc.) at any time without restarting the device (hot swapping). When there is no connection you will see no activity on the SFP modules, so this is one of the easiest issues to troubleshoot if you have access to the device.

On the other hand, you might plug in a fiber cable that will activate that port but the connectivity suffers from different issues (e.g., performance degradation or intermittent connectivity) or it simply does not exist. In this case there are several approaches that you could take:

• Verify that the correct cable types have been used (e.g., multi-mode vs. single-mode), depending on the type of transceiver
• Verify that the cable is not broken using dedicated fiber optic (FO) testing tools
• Verify that the correct type of transceiver has been used
• Verify that the transceiver does not have hardware issues (swap it and test the connection with another SFP)
• Verify that the device port is configured with the correct parameters based on the type of transceiver and cable used

To minimize connection downtime, you should monitor the ports populated with SFP modules in order to see possible errors that appear in the statistics. This can be done with standard monitoring tools, most often using SNMP.

Troubleshooting Subnet Mask and Gateway Issues

You may see a number of symptoms occurring when there are problems with IP addressing, the subnet mask, or the gateway, including the following:

• Network devices can communicate within their local subnet but are unable to communicate with devices outside the local network. This usually indicates that there is some type of issue with the gateway configuration or operation.
• Not having any type of IP communication (internal or remote). This usually points to a major type of issue that might involve a lack of functionality on certain devices.
• Being able to communicate with only some of the IP addresses available. This is usually the most difficult problem to troubleshoot because it has many possible causes.

One of the first things you should always do during the troubleshooting process for such situations is double-check the IP address, subnet mask, and default gateway configuration on your devices. You should also check the documentation to verify this information.

If you are installing network devices for the first time, very often you will manually type in the IP address information, along with the subnet mask and default gateway. The recommendation is to verify this information before submitting it because mistakes happen often.

If you need to gather information during the troubleshooting process, you might want to perform packet capturing to see exactly which packets are being sent between devices. If you see packets from hosts that are not on your network, you may have some kind of VLAN misconfiguration issue. If you suspect that your subnet mask is wrong, you should check the parameters on other devices on your network. If the other machines work properly, you should use the same subnet mask on the device that is not working as expected and start testing again.

When using dynamic IP addressing (DHCP) to allocate IP address information, including subnet mask and default gateway, to devices in your network, you should investigate the DHCP server configuration because that might be another point where problems occur. The DHCP server could be misconfigured or the DHCP service could be jammed, so you should include this step in your troubleshooting process.

Other useful troubleshooting tools are traceroute and ping, which can help you identify the point in the network where problems are occurring.

Troubleshooting Duplicate IP Addresses

When you have a duplicate IP address on the network, the stations involved will not receive the information they would expect to receive. Depending on the sender, they might receive partial traffic or they might not receive any traffic at all.

If you have statically addressed devices on the network, you have to be very careful not to duplicate any IP addresses that might already be in use on the network. The more static addresses you use, the more you need to be concerned about this, and the best way to deal with this is to manage the allocated IP addresses in a central database. This will ensure that you don’t accidentally create conflicts by assigning the same IP address to different devices.

Many networks use DHCP to automatically assign IP addresses to devices, but even in this case, you cannot avoid the possibility of a duplicate IP address. For example, if you have devices on the network that you must statically assign an IP address to, make sure that your DHCP server is not also giving out that particular IP address to other devices on the network. You also need to be careful that other machines on the network don’t accidentally run a DHCP service that will conflict with your legitimate DHCP server.

If you suddenly have two devices with the same IP address and there is no mechanism within those devices to recognize a duplicate IP address, the devices will conflict with each other. In this situation, both devices think they should receive traffic so they both answer ARP requests from the router, resulting in two MAC addresses associated to the same IP address.

A number of newer operating systems are capable of performing duplicate address detection (DAD) verifications to make sure that no other device on the network is using the same Layer 3 address. If such a situation is detected, the operating systems will not accept the use of that particular address in order to avoid conflicts on the network.

One of the more common places where you can make a mistake regarding DAD is in initial device configurations. If you are statically assigning IP addresses to a device, you should also double-check the addresses to make sure that no mistakes were made. If you don’t have a centralized IP address database, one way to verify that an IP address is not being used is pinging that respective address before you configure it on new devices. If you receive a reply that means the address is already in use on the network. However, you should still be careful even if you don’t receive a reply because the address might be used on a machine that is shut down or ICMP packets might be filtered on the network (in this case, the ARP table can be checked to see if a particular entry is present).

If you have duplicate IP addresses on the network, you can ping that IP address to get an ARP response from one device or the other. You can also look at the local ARP table to see the IP-to-MAC associations for that particular scenario. Then you can follow the MAC address back from the switch to identify which port is connected to that station so you can correct the duplicate IP address. You can repeat the same process to identify the other station that is sharing the same IP address.

If you think the duplicate IP address issue is related to a DHCP issue, you can perform a packet capture and analyze the DHCP traffic on the network. You can also look at the MAC addresses of the DHCP responders and eventually identify rogue DHCP servers that might not be authorized to allocate IP addresses.

By understanding more about how IP addresses are assigned and performing some of the troubleshooting processes mentioned above, you can maintain the uptime and availability of your network, even if duplicate IP address issues are occurring.

Troubleshooting DNS Issues

If you are having problems communicating with your DNS server, you might think that the Internet connection is down because you don’t get a response when you try to access sites by name. One way to confirm this issue is trying to ping a public IP address. If that works but you cannot ping any domain names, it means that you have a DNS issue (i.e., translating domain names into IP addresses) and not a general communication problem.

If your applications are not working but you have Layer 3 connectivity within the network, this might also mean that you have a DNS issue, as some applications are communicating using names and not IP addresses.

The first thing you should do when you suspect DNS issues is verify the DNS server configuration on your devices. You should make sure that you have the correct IP address of the DNS server on every device that might need a name-to-IP translation, as the DNS server could have been statically or automatically assigned (DHCP). A good way to check this basic functionality is to perform an “nslookup” test. This is a utility built into the operating system that allows you to perform a DNS query from the command line interface to see if the DNS server responds.

The screenshot in Figure 12.3 below shows an nslookup query performed on a Windows machine by simply typing the nslookup command followed by the domain you want to translate:

Figure 12.3 – Nslookup Test 

In the screenshot above, you can see the configured DNS server (8.8.8.8) and the DNS query result (in this case, an IPv6 address and multiple IPv4 addresses were returned). This example confirms that the DNS server is reachable and is working properly. If the DNS server could not find the domain you requested, the following message would have been returned: *** 8.8.8.8 can’t find <requested domain name>: Non-existing domain. On the other hand, if you don’t receive a response, this means the DNS server is not reachable, so you can start investigating standard network connectivity issues that would prevent you from reaching the configured DNS server.

If your preferred server does not respond, you can try using a different DNS server, even a public one, to validate the issue.

Summary

Most Layer 2 issues are related to some kind of loop within the domain and this has multiple problems associated with it, including network downtime. Often when you are working with switch configuration and you are plugging/unplugging a device, you should be careful that you don’t create a loop. To mitigate such problems, you should usually configure Spanning Tree Protocol on switches to avoid situations that might occur if you happen to accidently create a loop somewhere in the network.

Troubleshooting cabling issues (Layer 1 troubleshooting) can sometimes be a very easy process because you can directly see and inspect the cable. However, sometimes cabling problems are invisible, in which case you will have to engage in a systematic troubleshooting process to make sure that the problem is really localized at Layer 1.

One particular feature that might be configured in enterprise environments is logically separating different network areas using VLANs. Issues can appear when you have configuration issues related to a particular VLAN and this can become difficult to troubleshoot. One way of doing this is to analyze the entire configuration on the switch to identify the problem.

An MTU (maximum transmission unit) is the size an IP packet can be to traverse the network from one end to the other without the need to fragment it as it passes through different network devices. Networks are very diverse and use different media types, ranging from wired to wireless technologies. Each one of the different topologies and network types can use different frame types. If you have a very large frame passing through the network and it reaches an area that does not support the size of the frame, it will be split up into smaller pieces in a process called fragmentation.

Power failures are relatively straightforward to identify because an entire group of network devices will not be accessible. This is very easy to troubleshoot in person because the device lights will be off and the fans will not be spinning. However, if direct access to the data center is not possible and you have to investigate the issue from a remote site, power failure issues can become more difficult to troubleshoot.

When configuring routing on your network devices, you need to carefully configure static or dynamic routing based on the design. If you have a problem where you are not able to send/receive traffic across the network, you probably have some kind of configuration issue that must be carefully investigated.

Most routers and switches used in enterprise networks offer not only copper port connectivity but also dedicated ports that can be populated with different kinds of transceivers. These transceivers are usually used for fiber connectivity but there are also copper-compatible transceivers.

When you have a duplicate IP address on the network, the stations involved will not receive the information they would expect to receive. Depending on the sender, they might receive partial traffic or they might not receive any traffic at all.

Router troubleshooting guide.

Troubleshoot networks and routers in our 101 Labs – CompTIA Network+ book.