Configuring EIGRP
The basic configuratio
n of EIGRP is so similar to the basic configuration of IGRP that instructors occasionally will instruct beginners to "configure IGRP, but add an E." As mentioned in the previous section, the
metric weights command is used the same way with EIGRP and IGRP. The traffic-share and variance commands are also used identically. For a review of these commands, please refer to Chapter 6.
The case studies in this section demonstrate a basic EIGRP configuration and then examine
summarization techniques and interoperability with IGRP.
Case Study: A Basic EIGRP Configuration
Like IGRP, EIGRP requires only two steps to begin the routing process:
Enable EIGRP with the command
router eigrp
process-id. Specify each major network on which to run EIGRP with the network command.
The process ID may be any number between 1 and 65535 (0 is not allowed), and it may be arbitrarily chosen by the network administrator, as long as it is the same for all EIGRP processes in all routers that must share information. Alternatively, the number may be an InterNIC-assigned autonomous system number. Figure 8.36 shows a simple internetwork; the configurations for the three routers are as follows:
Earhart:
router eigrp 15
network 172.20.0.0
Cochran:
router eigrp 15
network 172.20.0.0
network 192.168.17.0
Lindbergh:
router eigrp 15
network 172.20.0.0
network 192.168.16.0
Earhart's route table is shown in Figure 8.37. The table shows that the default EIGRP administrative distance is 90 and that network 172.20.0.0 is variably
subnetted.
The internetwork of
Figure 8.36 uses default metrics, unlike the earlier examples in this chapter, so a review of the EIGRP metric calculation in a more realistic scenario may be useful.
Tracing the route from Earhart to network 192.168.16.0, the path traverses a serial interface and an Ethernet interface, each with default metric values. The metric calculation is the same as for IGRP, as discussed in Chapter 6, except that EIGRP will multiply the final result by 256. The minimum
bandwidth of the route will be that of the serial interface, and the delay will be the
sum of the two interface delays. Referring back to Table 6.1:
BWEIGRP(min) = 256 * 6476 = 1657856 DLYEIGRP(sum) = 256 * (2000 + 100) = 537600
Therefore,
Metric = 1657856 + 537600 = 2195456
Case Study: Redistribution with IGRP
Redistribution between
routing protocols is covered in Chapter 11, but it is worth noting here that if an IGRP process and an EIGRP process have the same process IDs, they will redistribute automatically. In Figure 8.38, router Curtiss has the following configuration:
router igrp 15
network 172.25.0.0
network 172.20.0.0
Earhart is configured as follows:
router eigrp 15
passive-interface Ethernet0
network 172.20.0.0
!
router igrp 15
passive-interface Serial0
passive-interface Serial1
network 172.20.0.0
The IGRP process speaks to
Curtiss, and the EIGRP process speaks to Lindbergh and Cochran. Note that because Earhart's interfaces are all in network 172.20.0.0, the
passive-interface command is used to restrict unnecessary routing protocol traffic. For EIGRP, this command is only needed to block unnecessary Hellos. If no neighbors are found on an interface, no other EIGRP traffic will be sent.
Figure 8.39 shows Curtiss's route table. Notice that not only are routes to 192.168.16.0 and 192.168.17.0 present, but the metrics have been adjusted by the redistribution process to remove the EIGRP multiplier. Conversely, the metrics of routes redistributed into EIGRP from IGRP will be multiplied by 256.
Figure 8.39 also shows that
information is missing. Earhart's classful IGRP process will not accept the variably subnetted routes to 172.20.15.0/30 and 172.20.15.4/30.
Using the
command ip summary-address eigrp, Earhart can be configured to send a summary advertisement to Curtiss:
interface Ethernet0
ip address 172.20.10.1 255.255.255.0
ip summary-address eigrp 15 172.20.15.0 255.255.255.0
!
router eigrp 15
passive-interface Ethernet0
network 172.20.0.0
!
router igrp 15
passive-interface Serial0
passive-interface Serial1
network 172.20.0.0
Curtiss's IGRP process will read the EIGRP summary, resulting in the route table shown in Figure 8.40.
Figure 8.41 shows Cochran's route table with the redistributed IGRP route. As this table shows, EIGRP
explicitly tags externally learned routes. This information can be an aid
when reading a route table because routes learned by redistribution are easily recognized.
Also of interest in Figure 8.41 is the last entry, a summary route pointing to the Null interface. This route helps to prevent potential black holes when default and summary routes are used. The technique is discussed in Chapters 11
and 12.
Case Study: Disabling Automatic Summarization
By default, EIGRP summarizes
at network boundaries as do the protocols covered in previous chapters. Unlike those protocols, however, EIGRP's automatic summarization can be disabled. Figure 8.42 shows a situation in which disabling summarization is useful.
New Ethernet links have been added to routers Cochran and Lindbergh, and their addresses create a discontiguous subnet. The default behavior of both routers is to see themselves as border routers between major networks 172.20.0.0 and 192.168.18.0. As a result, Earhart will receive summary advertisements to 192.168.18.0 on both of its serial interfaces. The result is an ambiguous
routing situation in which Earhart records two equal-cost paths
to 192.168.18.0; a packet destined for one of the subnets may or may not be routed to the correct link.
Automatic summarization is turned off with the
command no
auto-summary. For example, Lindbergh's configuration will be:
router eigrp 15
network 172.20.0.0
network 192.168.16.0
network 192.168.18.0
no auto-summary
By turning off summarization at Lindbergh and Cochran, the individual subnets 192.168.18.24/29 and 192.168.18.128/25 will be advertised into network 172.20.0.0,
eliminating the ambiguities at Earhart.
Case Study: Address Aggregation
A new router is added to the
internetwork in Figure 8.43. The five network addresses that Earhart must advertise to Yeager can be summarized with two aggregate addresses. Earhart's configuration will be:
interface Ethernet1
ip address 10.15.15.254 255.255.255.252
ip summary-address eigrp 15 172.0.0.0 255.0.0.0
ip summary-address eigrp 15 192.168.16.0 255.255.240.0
The ip
summary-address eigrp command will automatically suppress the advertisement of the more
specific networks to Yeager. Figure 8.44 shows the route table of Yeager before and after the aggregate addresses are configured. Even in this small internetwork, the number of EIGRP-learned entries has been reduced by half; in a large internetwork, the impact on route tables and the memory required to store them can be
significant.
Authentication
Authentication of
EIGRP packets is supported in IOS versions 11.3 and later.
MD5 cryptographic checksums are the only authentication supported, which on first consideration may seem less flexible than RIPv2 and OSPF, which support both MD5 and clear-text passwords. However, clear-text password authentication should be used only when a neighboring device does not support the more secure MD5. Because EIGRP will be spoken only between two Cisco devices, this situation will never arise.
Note
Authentication method of EIGRP compared to OSPF and RIPv2
The steps for configuring
EIGRP authentication are:
Define a key chain with
a name. Define the key or keys on the key chain. Enable authentication on an interface and specify the key chain to be used. Optionally configure key management.
Key chain configuration and management are described in Chapter 7. EIGRP authentication is enabled and linked to a key chain on an interface with the
commands ip authentication key-chain eigrp and
ip authentication mode eigrp md5.
Referring to Figure 8.43, the following configuration enables EIGRP authentication on Cochran's interface to Earhart:
Cochran
key chain Edwards
key 1
key-string PanchoBarnes
!
interface Serial0
ip address 172.20.15.6 255.255.255.252
ip authentication key-chain eigrp 15 Edwards
ip authentication mode eigrp 15 md5
A similar configuration would be necessary on Earhart. The commands
accept-lifetime and send-lifetime are
used for key chain management as described in Chapter 7.
| 
