An organization named Able once acquired a small organization called Baker. While reviewing Baker’s network, I found pervasive and overlapping configuration issues. I thought I’d briefly describe the issues here.
Baker has about 8 remote sites that connect across T1 circuits to multiple routers at the main Baker site. (Baker also has a connection to Acme.) I was told that Baker was running EIGRP and static routes.
I found that although most of the Baker routers have an EIGRP routing process running, the Baker network is not actually using EIGRP because of the numerous misconfigurations. The two underlying issues are misconfigured IP addresses on serial interfaces and erroneous EIGRP network statements. Because of these issues, an excessive amount of static routes (over 85!) were configured to provide network connectivity.
Misconfigured IP Addressing on Serial Links
Except for the link to Acme, all of the serial interfaces in the Baker network had misconfigured IP addressing. I was told that the serial links to remote Baker sites were implemented using /30 addresses from 192.168.x.x address block. However, when I reviewed the configuration files for the Baker devices, I found that all serial interfaces actually use /24 subnets, except for one /16 subnet. I also found that none of the pairs of devices on a serial link were in the same subnet. In addition, several of the serial interfaces on individual devices at the main site use IP addresses with overlapping subnets when connecting to different remote sites.
I recommended that the serial links be re-addressed so that both ends are in same subnet and none of the subnets overlap.
Misconfigured EIGRP Network Statements
There are EIGRP neighbors across the LAN at the main site. However, since none of the serial links of the remote routers are in the same subnet as serial links from the main site routers, there are no WAN EIGRP neighbors. I determined that fixing the mis-addressed serial links is not sufficient resolve the WAN EIGRP neighbor problem.
I found that the EIGRP network statements are misconfigured. The Baker routers use the following EIGRP configuration statements:
router eigrp 100 [redistribute static] network 172.16.0.0 network 192.168.0.0 auto-summary
Note: The LANs use a /24 address out of 172.16.0.0/16.
Since the WAN links use 192.168.x.y/24 routes, and the listed network commands are classful, only the 192.168.0.y interfaces could be included in the EIGRP process. As it turns out, none of the remote sites have their serial interface included in an EIGRP routing process.
I recommended that the network statements should be updated to support classless networks (no auto-summary) supporting the re-addressed serial links and the LAN links.
Excessive Static Routes Used
None of the remote routers’ LAN subnets were being dynamically advertised to the main Baker site routers. As a result, over 85 static and default routes are configured to provide connectivity between the Baker sites.
I noted that to reach the remote sites WAN interfaces which were in different subnets than the main site WAN interfaces, the static routes use the physical interface as the next-hop address. One issue with this practice is that if the WAN interface is up, but the remote networks are not reachable, traffic is still forwarded through the WAN interface.
I recommended that the previous IP addressing issues and the network configuration statements should be corrected first. After this clean up, all of the static routes pointing to the LAN subnets can be removed. In addition, each of the remote WAN sites will not need a configured default route. Finally, the redistribution of the static routes on the main Baker site routers would not be needed and can be removed as well.
Numerous to excessive static routes in an environment where a dynamic routing protocol is supposedly running is often a clue that there are serious network configuration issues.
Other NetCraftsmen blogs on EIGRP design include: