Excessive Static Routes with EIGRP

Author
Carole Warner Reece
Architect

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.

Summary
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.

— cwr

________________________________________________________________________________________

Related Blogs
Other NetCraftsmen blogs on EIGRP design include:

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.