Configuring EIGRP on small to medium-sized networks can be simple and straightforward.This often leads to the incorrect conclusion that EIGRP is a simple protocol—as you have seen, this is not true. EIGRP processes are complex and must be kept in mind as your network is designed and ultimately imple-mented. In the next two sections, we discuss and design a increasingly complex network and see what design principals we should follow to allow an EIGRP network to adhere successfully to some basic tenants of routing:
■ No routing protocol can overcome a poorly designed IP addressing scheme.
■ Redundancy is key to your peace of mind (and peaceful nights and weekends).
■ Know that your network will grow.
EIGRP was designed with several key features to allow for these and several other principles to greatly improve network reliability and efficiency.While a com-prehensive design guide full of case studies would occupy the complete volume of this text, we will attempt to demonstrate the most common implementations that are encountered in today’s networks.The end result will hopefully allow you to use these examples in your successful design and implementation.
Enabling EIGRP is as straightforward as IGRP and RIP.The process is started with the routercommand, and participating networks are added with the net-workcommand. Figure 2.18 shows a three-router network that will function under the same EIGRP process.
This simple network can be found as a piece of many networks. Router A could be functioning as a collapsed backbone or as a distribution node. Routers B and C may be access nodes servicing end-user segments. In our circumstances, let’s assume that this is an accounting department, the server farm contains our mainframes, and Routers B and C provide access to end users. Enabling EIGRP here is very simple.We will start with Router A.
router eigrp 100 network 172.16.0.0
Enabling EIGRP begins with the command router eigrp process-id.The process id is any number between 1 and 65535.This number can be selected at random, but it must be the same for all routers that are to participate in this EIGRP process.The network command is used to specify which networks will participate in the routing process, and specifies the major network address. It is typically believed that you are specifying the interfaces that will participate in the routing process.While it is absolutely true that only interfaces belonging to the major networks specified would participate, it is possible and sometimes necessary to specify a network that is not configured on the router at all.This implies that you are enabling the network, not the interface.This is a function of address sum-marization and is demonstrated in Advanced Configuration. In this scenario, inter-faces E0, E1, and E2 will all participate.
Routers B and C require an additional network statement to enable their subnets in the private address space of network 192.168.0.0.
Router B
Figure 2.18A Working Example of an EIGRP Network
Router A
Router C
router eigrp 100 network 172.16.0.0 network 192.168.10.0 no auto-summary
The no auto-summary command is explained later in this chapter. Our net-work is now up and running. After a few seconds of convergence, we can look at the route table for Router A and see that it has routes for all networks.
Router A#show ip route Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2,
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
D 192.168.20.0/24 [90/307200] via 172.16.10.2, 00:01:27, Ethernet0 D 192.168.10.0/24 [90/307200] via 172.16.20.2, 00:01:27, Ethernet1
172.16.0.0/24 is subnetted, 3 subnets
C 172.16.10.0 is directly connected, Ethernet0 C 172.16.20.0 is directly connected, Ethernet1 C 172.16.30.0 is directly connected, Ethernet2
At first glance, all appears well. Router A has established paths to all networks with their associated costs. However, to get a feel for EIGRP and to find any caveats in your design, you must examine the topology table.
Router A# show ip eigrp topology
IP-EIGRP Topology Table for process 100
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status
P 172.16.10.0 255.255.255.0, 1 successors, FD is 281600 via Connected, Ethernet0
P 192.168.20.0/24 255.255.255.0, 1 successors, FD is 307200 via 172.16.10.2(307200/281600), Ethernet0
P 172.16.20.0 255.255.255.0, 1 successors, FD is 281600 via Connected, Ethernet1
P 172.16.30.0 255.255.255.0, 1 successors, FD is 281600 via Connected, Ethernet2
P 192.168.10.0/24 255.255.255.0, 1 successors, FD is 307200 via 172.16.20.2(307200/281600), Ethernet1
The first thing that should jump out at you is the lack of feasible successors to networks 192.168.10.0 and 192.168.20.0. A link failure between Routers A and B or Routers A and C will segment users from the server farm.This was obvious when looking at the network diagram.The easiest solution to this problem is to add a new segment between Routers B and C.While it is not always as easy as pulling a little Cat 5 to create redundancy as it is in our case, it should be a goal of a strong network design to eliminate single-link failures that can segment the network. Figure 2.19 illustrates the new segment.
After adding this segment, the route table for Router A now changes to reflect the new segment. Notice that two routes for destination 172.16.40.0 exist in the route table. EIGRP, as with IGRP and RIP, will automatically load balance over equal-cost paths.
www.syngress.com
Figure 2.19Physical Redundancy Eliminated Single Points of Failure
Router A
Router A#show ip route Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2,
* - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
D 192.168.20.0/24 [90/307200] via 172.16.10.2, 00:02:17, Ethernet0
D 192.168.10.0/24 [90/307200] via 172.16.20.2, 00:02:17, Ethernet1
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.40.0/24 [90/307200] via 172.16.10.2, 00:00:21, Ethernet0
[90/307200] via 172.16.20.2, 00:00:21, Ethernet1 C 172.16.10.0 is directly connected, Ethernet0
C 172.16.20.0 is directly connected, Ethernet1 C 172.16.30.0 is directly connected, Ethernet2
Now lets take a look at the new topology table:
Router A# show ip eigrp topology
IP-EIGRP Topology Table for process 100
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status
P 172.16.10.0 255.255.255.0, 1 successors, FD is 281600 via Connected, Ethernet0
P 172.16.40.0/24 255.255.255.0, 2 successors, FD is 307200 via 172.16.10.2(307200/281600), Ethernet0
via 172.16.20.2(307200/281600), Ethernet1
P 192.168.20.0/24 255.255.255.0, 2 successors, FD is 307200 via 172.16.10.2(307200/281600), Ethernet0
via 172.16.20.2(332800/307200), Ethernet1 P 172.16.20.0 255.255.255.0, 1 successors, FD is 281600
via Connected, Ethernet1
P 172.16.30.0 255.255.255.0, 1 successors, FD is 281600 via Connected, Ethernet2
P 192.168.10.0/24 255.255.255.0, 2 successors, FD is 307200 via 172.16.20.2(307200/281600), Ethernet1
via 172.16.10.2(332800/307200), Ethernet0
As you can see, we now have redundancy to our end-user segments.This leaves us with one more serious flaw in our design that must be addressed before moving on to more advanced topics.While we have removed single-link failure to our end users, we have left the server farm hanging out there off Router A.
Regardless of the amount of redundancy we create between end users and the core, if the destination of the vast majority of network activity remains vulner-able, we have disarmed our network. Since this is an accounting department, count on Ethernet 2 on Router A failing the next time payroll is processed.
Creating redundancy to the server farm is not as easy as it might look.
Following Cisco’s design recommendation of implementing tiered, hierarchical networks, adding a link between Router C and the server farm would not be fundamentally sound.The theory is something like: Every router has a place, and every router in its place. Cisco’s recommendation is to create three layers of routing responsibility: Core, Distribution, and Access.The Access layer is intended to provide end users with connectivity to the network and shared access to often-used network devices such as printers and storage servers.The Distribution layer is intended to perform such responsibilities as address summarization and policy routing, and to provide redundant access to the core.The Core layer should focus simply on high-speed data transport. Policy decisions should not be made here.Wasting processing cycles on ACLs, for example, is detrimental to the efficiency of core routers and should be left to the Distribution and Access layers.
Our network is currently a little less complex and does not require three tiers at this time. However, connecting Router C to the server farm would essentially place it in both the Access and Distribution layers, and the likelihood of it being overrun is high. Our network needs another distribution router. In Figure 2.20,
www.syngress.com
we have added that router, Router D. It will now share the responsibility of feeding traffic into and out of the server farm with Router A.
Adding this router is a fairly simple process.The EIGRP configurations on Router A, B, and C do not change. Although Router A lost interface Ethernet 2, it is still only running the process for network 172.16.0.0.This means that we can simply add Router D to the network with the following configuration:
router eigrp 100 network 172.16.0.0
After our network has converged, we can see what Router D’s route table looks like.
Router D#show ip route Codes:
C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2, * - candidate default U - per-user static route, o - ODR
Gateway of last resort is not set
D 192.168.20.0/24 [90/332800] via 172.16.30.1, 00:00:39,
Figure 2.20Sharing the Load of Getting Traffic to the Server Farm
Router A
Ethernet1
[90/332800] via 172.16.20.2, 00:00:39, Ethernet0 D 192.168.10.0/24 [90/307200] via 172.16.20.2, 00:00:39,
Ethernet0
172.16.0.0/24 is subnetted, 4 subnets
D 172.16.40.0/24 [90/307200] via 172.16.20.2, 00:00:41, Ethernet0
D 172.16.10.0/24 [90/307200] via 172.16.30.1, 00:00:41, Ethernet1
C 172.16.20.0 is directly connected, Ethernet0 C 172.16.30.0 is directly connected, Ethernet1
As you can see, Router D has fully converged and has routes to all networks.
It is load balancing between Routers A and C to access 192.168.20.0.While this sounds like a good thing, it actually is not.We do not want user traffic that is not destined for the server farm passing through that segment.We can remedy this situation using one of several methods.
One potential solution is to add a single configuration command, passive-interface passive-interface,to Routers A and D.Their EIGRP configurations become:
Router A
router eigrp 100 network 172.16.0.0
passive-interface ethernet1
Router D
router eigrp 100 network 172.16.0.0
passive-interface ethernet1
This command blocks EIGRP traffic on the specified interfaces.The result is that Router D will not learn routes from Router A, and vice versa. If you were to look at Router D’s route table, you would see that the redundant route is gone, and find that the route to 172.16.10.0 now has a vector of Router C.
There is a major drawback to this configuration: we have lost a layer of redundancy. If the link between Routers D and C were to fail, and Router D received traffic, it would simply drop the traffic because it would no longer know of any routes—Router C was its only neighbor. One potential solution to this
www.syngress.com
problem is to add a default route pointing to Router A. Default routes are special static routes labeled as the “Gateway of last resort” in the routing table.They are added using the command ip route 0.0.0.0 0.0.0.0 <next hop router address>.
This command tells the router that if it can find no other route to any destina-tion in its routing table to forward the traffic to the router specified. In our case, this would be Router A.
The highs and lows of this solution can be debated. I follow a simple policy: If you are forced to use a static route within your meshed dynamic routing environ-ment, you have done something wrong.This is not to say that static routes do not have their place—they do.They can be very useful in a hub-and-spoke network over slow links. However, that is not our situation—we need to dig a little deeper.
Recall from our earlier discussion that one of the greatest advantages of EIGRP is its efficient use of bandwidth. Our concern here is not that EIGRP traffic will clog our server farm segment, but that user traffic will. I believe that the better policy here would be to convince EIGRP not to use the segment unless absolutely necessary.This way, we leave the dynamic process in place and maintain our level of redundancy.
A method for resolving this entire situation that meets all of our needs without seriously affecting our network down the line is to adjust either the bandwidth or delay values on the link between Routers A and D to increase the metric. Once the paths are no longer equal, load balancing will not automatically occur, and the higher-cost route between the two routers will only be used if the other route fails. Adjusting the bandwidth can introduce serious problems, since EIGRP uses the bandwidth statement to determine how much bandwidth it can consume for EIGRP traffic (50 percent, by default). Adjusting the bandwidth statement up or down can also cause issues with Quality of Service (QoS) mech-anisms, network management, and other problems. As such, it is preferable to adjust delay.
We will adjust the delay value on both Routers A and D with the following commands:
Router A
interface Ethernet1 delay 1100
Router D
interface Ethernet1 delay 1100
Looking at the topology table on Router D, we can observe the effect of this change.
Router D# show ip eigrp topology
IP-EIGRP Topology Table for process 100
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - Reply status
P 172.16.10.0 255.255.255.0, 2 successors, FD is 309760 via 172.16.30.1(309760/281600), Ethernet1 via 172.16.20.2(332800/307200), Ethernet0 P 172.16.40.0/24 255.255.255.0, 2 successors, FD is 307200
via 172.16.20.2(307200/281600), Ethernet0 via 172.16.30.1(335360/307200), Ethernet1
P 192.168.20.0/24 255.255.255.0, 2 successors, FD is 332800 via 172.16.20.2(332800/281600), Ethernet0
via 172.16.30.1(335360/307200), Ethernet1 P 172.16.20.0 255.255.255.0, 1 successors, FD is 281600
via Connected, Ethernet0
P 172.16.30.0 255.255.255.0, 1 successors, FD is 281600 via Connected, Ethernet1
P 192.168.10.0/24 255.255.255.0, 1 successors, FD is 307200 via 172.16.20.2(307200/281600), Ethernet0
As you can see, the level of redundancy that we wanted to achieve has been successfully implemented, and the routes away from the server farm have been selected as the successors due to the adjustment that we made to our delay metric.
Our basic network is now up and running with a high degree of redundancy, and traffic is routed efficiently. Before we move on to more advanced configura-tions, let’s take a moment to look at some more detailed show commands that can be useful in verifying your configuration and troubleshooting any problems that may arise.