Welcome to the fourth article in this troubleshooting mini-series, where we are presented with various troubleshooting scenarios and asked to resolve the issues. The scenario in this lab will focus on sub-sections 7.10 and 7.12 of the CCNA R&S exam topics, which cover resolving WAN implementation issues and EIGRP problems.
We will be using the following setup for this troubleshooting scenario:
In the network diagram above, the routers are connected via frame-relay to form the 10.1.123.0/24 network. R1 and R3 also have a direct connection in the 10.1.13.0/24 network. Two things are required in this lab:
EIGRP should be used to enable connectivity amongst all the LAN networks i.e. 192.168.X.0/24 networks. R1 is configured to advertise a summary route (192.168.0.0/16) to both R2 and R3.
Also, ensure that R1 and R3 load balance across both links. Do not adjust any interface level setting to achieve this.
Review the configuration on the devices and fix any issues that may exist.
Two files are attached to this article:
trblsht_wan_eigrp_init.pkt: This Packet Tracer file contains the lab setup with various configuration issues.
trblsht_wan_eigrp_final.pkt: This Packet Tracer file contains the lab with the issues resolved.
Troubleshooting Scenario Resolution
The first place to start in this type of scenario is to confirm that there is underlying L1/L2 connectivity between the routers. Therefore, we need to make sure that the frame-relay device (cloud) is correctly configured:
Note: Go ahead and confirm the DLCIs are correct; e.g., R1R2 is 102 while R2R1 is 201.
Now let’s go check the IP connectivity from the routers themselves.
R1 can ping R2 over the frame-relay network but not R3. Since inverse ARP is turned on by default, we can use the show frame-relay map command to make sure DLCIs are correctly learned and associated:
It seems R1 does not have a DLCI associated with R3. So let’s go over to R3 to check what is happening on that router’s frame-relay interface:
As you can see from the output of the show interface command above, the serial interface is using the default encapsulation of HDLC. Looking at the configuration on that interface, we can see why:
For frame-relay to work, that interface must be configured with the encapsulation frame-relay command as follows:
interface Serial0/1/0 encapsulation frame-relay
Even without pinging, we see that the EIGRP neighbor adjacency has formed between R1 and R3:
Cool, so we have IP connectivity. Let’s now move on to EIGRP troubleshooting. We will start with R1 and view the EIGRP neighbors using the show ip eigrp neighbors command:
R1 has only two neighbors: 10.1.13.3 and 10.1.123.3. Both IP addresses actually belong to R3—one over the frame-relay network and the other is the direct link to R1. Why is R2 not listed as an EIGRP neighbor? Let’s go to R2 to find out. We can use the show ip protocols command to see the different routing protocols that have been configured on R2:
R2 seems to be advertising the correct networks—10.1.123.0/24 and 192.168.20.0/24. However, take a look at the EIGRP AS number: 23. If you refer to the show ip eigrp neighbors command output on R1 above, we see that the EIGRP AS on R1 is 123 not 23. Therefore, we need to reconfigure one of the devices to match the other. The easiest device to reconfigure is R2, because R1 is already peering correctly with R3; reconfiguring R1 means we will also reconfigure R3.
As such, the required change on R2 is as follows:
no router eigrp 23 router eigrp 123 network 10.1.123.0 0.0.0.255 network 192.168.20.0 no auto-summary
If we now check the EIGRP neighbors on R1, we should see R2 there:
At this point, there is IP connectivity among the entire 192.168.X.0/24 network. We can confirm this by pinging from PC2 to Server1 and PC3:
Side note 1: By default, split-horizon will not allow R1 advertise 192.168.20.0/24 to R3 and 192.168.30.0/24 to R2 (over the frame-relay network). Therefore, if a device on R2’s LAN tries to connect to a device on R3’s LAN, it will not go through because R2 won’t have a route for that network. In such a case, we will just disable split horizon on R1’s S0/1/0 using the no ip split-horizon eigrp command. However, this command is not supported on Packet Tracer, which is why I have configured R1 to advertise a summary address to both R2 and R3.
Side note 2: The problem discussed in Side Note 1 above will not have occurred in this network because of the direct link between R1 and R3. Since R1 will also learn about the 192.168.30.0/24 route over the direct link, it can advertise that route to R2 over its frame relay interface; i.e., split horizon will not apply here. However, if that direct link goes down, then split horizon will take effect and there will be loss of connectivity.
The second task requires that R1 and R3 load balance traffic across both links, i.e., the direct link and the frame-relay network. Let’s look at the routing table of one of the routers to determine which link is currently being used:
As shown above, R1 is using the direct link to send traffic to the 192.168.30.0/24. If you check R3, you will find that the same is the case for the 192.168.0.0/16 network. The reason this is happening is because s0/1/1 is configured with a higher bandwidth than s0/1/0:
Let’s take at the EIGRP topology table to see if the frame-relay IP address is listed as a feasible successor:
Since the task restricts us from changing any interface level settings, we can’t adjust the bandwidth to be the same on both interfaces. What we can do, however, is to use the variance command to enable unequal path load balancing. Therefore, we will configure the following on both R1 and R3:
router eigrp 123 variance 2
Remember to make this configuration on both devices, otherwise one device will use both links while the other will keep using just one link. If we check the 192.168.30.0/24 route on R1, we will now see that both links are being load balanced over:
This brings us to the end of this lab, where we have resolved a lab that had WAN implementation issues and EIGRP problems. I hope you have found this article insightful.