Fundamental EIGRP Concepts

This chapter is from the book 

Foundation Topics

EIGRP Fundamentals

All the CCNP exams consider CCNA materials as prerequisites. So this book also assumes that the reader is already familiar with CCNA topics. However, the CCNP exams do test on features that overlap with CCNA. Additionally, most people forget some details along the way. Therefore, this section reviews the CCNA-level topics as a brief refresher.

To that end, this section begins with a review of EIGRP configuration using only the router eigrp and network commands. Following that, the next section details the key fields used to verify that EIGRP is working. Finally, the last part of this introduction summarizes the basic EIGRP internals behind this initial simple example.

Configuration Review

Cisco IOS uses the router eigrp asn command (where asn is an autonomous system number [ASN]), plus one or more network net-id wildcard-mask subcommands, to enable EIGRP on the router and on router interfaces. The rules for these commands are as follows:

1. Neighboring routers’ router eigrp asn commands must be configured with the same ASN parameter to become neighbors.

2. Cisco IOS enables only EIGRP on interfaces matched by an EIGRP network command. When enabled, the router does the following:

   1. Attempts to discover EIGRP neighbors on that interface by sending multicast EIGRP Hello messages
   2. Advertises to other neighbors about the subnet connected to the interface
3. If no wildcard mask is configured on the EIGRP network command, the command’s single parameter should be a classful network number (in other words, a class A, B, or C network number).
4. If no wildcard mask is configured on the EIGRP network command, the command enables EIGRP on all of that router’s interfaces directly connected to the configured classful network.
5. If the network command includes a wildcard mask, the router performs access control list (ACL) logic when comparing the net-id configured in the network command with each interface’s IP address, using the configured wildcard mask as an ACL wildcard mask.

Example 4-1 shows a sample configuration for each router in Figure 4-1, with several variations in the network commands to make the details in the preceding list more obvious.

Example 4-1 EIGRP Configuration on Routers R1, R2, and R3

! On Router R1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router eigrp 1

 network 10.0.0.0

 network 192.168.9.0

! On Router R2: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router eigrp 1

 network 10.1.0.0 0.0.31.255

 network 10.1.2.2 0.0.0.0

! On Router R3: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router eigrp 1

 network 10.1.0.0 0.0.255.255

First, note that all three routers use the router eigrp 1 command, so all three routers’ ASN values match.

Next, consider the two network commands on R1. The network 10.0.0.0 command, without a wildcard-mask parameter, means that R1 matches all interfaces in class A network 10.0.0.0—which in this case means R1’s Fa0/0, S0/0/0, and S0/0/1 interfaces. The network 192.168.9.0 command, again without a wildcard mask, matches interface Fa0/1.

On R2, the network 10.1.0.0 0.0.31.255 command requires a little more thought. The router uses the 0.0.31.255 value—the wildcard (WC) mask—just like an ACL WC mask. Cisco IOS compares the 10.1.0.0 value with each interface IP address, but only for the bit positions for which the WC mask lists a binary 0. For example, 0.0.31.255 represents 19 binary 0s, followed by 13 binary 1s. So, R2 would compare the first 19 bits of 10.1.0.0 with the first 19 bits of each interface’s IP address.

Two features of the mechanics of the network command require a little extra attention. First, Cisco IOS might convert the address portion of the network address wc-mask command before putting the command into the running config. Just as Cisco IOS does for the address/WC mask combinations for the access-list command, Cisco IOS inverts the WC mask and then performs a Boolean AND of the address and mask. For example, if you type the network 10.1.1.1 0.0.255.255 command, Cisco IOS inverts the WC mask (to 255.255.0.0) and ANDs this value with 10.1.1.1, resulting in 10.1.0.0. As a result, Cisco IOS stores the command network 10.1.0.0 0.0.255.255.

The second feature is that when you know for sure the values in the network command, you can easily find the range of interface addresses that match the address/WC mask combination in the network command. The low end of the range is the address as listed in the network command. To find the high end of the range, just add the address and WC mask together. For example, the network 10.1.0.0 0.0.31.255 command has a range of 10.1.0.0 through 10.1.31.255.

Finally, on R3, the network 10.1.0.0 0.0.255.255 command tells R3 to enable EIGRP on all interfaces whose IP addresses begin with 10.1, which includes all three interfaces on R3, as shown in Figure 4-1.

Taking a step back from the details, this config has enabled EIGRP, with ASN 1, on all three routers, and on all interfaces shown in Figure 4-1—except one interface. R2’s Fa0/1 interface is not matched by any network commands on R2. So, EIGRP is not enabled on that interface. The next section reviews the commands that can be used to confirm that EIGRP is enabled, the interfaces on which it is enabled, the neighbor relationships that have been formed, and which EIGRP routes have been advertised and learned.

Verification Review

Even before starting to configure the routers, an engineer first considers all requirements. Those requirements lead to a design, which in turn leads to a chosen set of configuration commands. Then, the verification process that follows must consider the design requirements. The goal of verification is to determine that the internetwork works as designed, not just that some EIGRP routes have been learned.

For the purposes of this section, assume that the only design goal for the internetwork shown in Figure 4-1 is that EIGRP be used so that all routers have routes to reach all subnets shown in the figure.

To verify such a simple design, an engineer should start by confirming on which interfaces EIGRP has been enabled on each router. The next step should be to determine whether the EIGRP neighbor relationships that should occur are indeed up and working. Then, the EIGRP topology table should be examined to confirm that there is at least one entry for each subnet or network in the design. Finally, the IP routes on each router should be examined, confirming that all routes are known. To that end, Table 4-2 summarizes five key show commands that provide the information to answer these questions.

Table 4-2 Key EIGRP Verification Commands

Command	Key Information
show ip eigrp interfaces	Lists the working interfaces on which EIGRP is enabled (based on the network commands); it omits passive interfaces.
show ip protocols	Lists the contents of the network configuration commands for each routing process, and a list of neighbor IP addresses.
show ip eigrp neighbors	Lists known neighbors; does not list neighbors for which some mismatched parameter is preventing a valid EIGRP neighbor relationship.
show ip eigrp topology	Lists all successor and feasible successor routes known to this router. It does not list all known topology details. (See Chapter 5, “Advanced EIGRP Concepts,” for more detail on successors and feasible successors.)
show ip route	Lists the contents of the IP routing table, listing EIGRP-learned routes with a code of D on the left side of the output.

Example 4-2 shows samples of each command listed in Table 4-2. Note that the output highlights various samples of items that should be verified: the interfaces on which EIGRP is enabled, the known neighbors, the subnets in the topology table, and the EIGRP routes.

Example 4-2 EIGRP Verification on Routers R1, R2, and R3

! On Router R1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R1# show ip eigrp interfaces

IP-EIGRP interfaces for process 1


                     Xmit Queue       Mean     Pacing Time  Multicast        Pending

Interface    Peers   Un/Reliable      SRTT     Un/Reliable  Flow Timer       Routes

Fa0/0          0        0/0            0       0/1             0               0

Se0/0/0        1        0/0           25       0/15          123               0

Se0/0/1        1        0/0           23       0/15          111               0

Fa0/1   0        0/0      0        0/1     0       0

! On Router R2: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R2# show ip protocols

Routing Protocol is "eigrp 1"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Default networks flagged in outgoing updates

  Default networks accepted from incoming updates

  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

  EIGRP maximum hopcount 100

  EIGRP maximum metric variance 1

  Redistributing: eigrp 1

  EIGRP NSF-aware route hold timer is 240s

  Automatic network summarization is in effect

  Maximum path: 4

  Routing for Networks:

    10.1.2.2/32

    10.1.0.0/19

  Routing Information Sources:

    Gateway         Distance      Last Update

    10.1.12.1             90      00:19:36

    10.1.23.1             90      00:19:36

  Distance: internal 90 external 170

! On Router R3: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R3# show ip eigrp neighbors

IP-EIGRP neighbors for process 1

H   Address                 Interface      Hold Uptime  SRTT  RTO  Q    Seq

                                           (sec)        (ms)      Cnt   Num

1   10.1.23.2               Se0/0/1        11 00:19:53   31   200   0    6

0   10.1.13.1               Se0/0/0        10 00:19:53   32   200   0    6

! On Router R2: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R2# show ip eigrp topology

IP-EIGRP Topology Table for AS(1)/ID(10.1.222.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

      r - reply Status, s - sia Status

P 10.1.13.0/30, 2 successors, FD is 2681856

        via 10.1.23.1 (2681856/2169856), Serial0/0/0

        via 10.1.12.1 (2681856/2169856), Serial0/0/1

P 10.1.12.0/30, 1 successors, FD is 2169856

        via Connected, Serial0/0/1

P 10.1.3.0/26, 1 successors, FD is 2172416

        via 10.1.23.1 (2172416/28160), Serial0/0/0

P 10.1.2.0/25, 1 successors, FD is 28160

        via Connected, FastEthernet0/0

P 10.1.1.0/24, 1 successors, FD is 2172416

        via 10.1.12.1 (2172416/28160), Serial0/0/1

! On Router R3: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R3# show ip route

Codes: C - connected, S - static, 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

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

D    192.168.9.0/24 [90/2172416] via 10.1.13.1, 00:19:55, Serial0/0/0

     10.0.0.0/8 is variably subnetted, 6 subnets, 4 masks

C       10.1.13.0/30 is directly connected, Serial0/0/0

D       10.1.12.0/30 [90/2681856] via 10.1.23.2, 00:19:55, Serial0/0/1

                     [90/2681856] via 10.1.13.1, 00:19:55, Serial0/0/0

C       10.1.3.0/26 is directly connected, FastEthernet0/0

D       10.1.2.0/25 [90/2172416] via 10.1.23.2, 00:19:55, Serial0/0/1

D       10.1.1.0/24 [90/2172416] via 10.1.13.1, 00:19:55, Serial0/0/0

C       10.1.23.0/30 is directly connected, Serial0/0/1

To verify the interfaces on which EIGRP is enabled, both the show ip eigrp interfaces command (shown on R1) and the show ip protocols command (shown on R2) list the information. For this example, look at the list of interfaces in R2’s show ip protocols command output: S0/0/0, S0/0/1, and FA0/0 are listed, but Fa0/1—unmatched by any of R2’s network commands—is not.

In this design, each router should form a neighbor relationship with the other two routers, in each case over a point-to-point serial link. The show ip eigrp neighbors command (on R3) confirms R3’s neighbors.

Finally, one design goal was for all routers to have routes for all subnets/networks. You could move on to the show ip route command or first look for all prefixes in the show ip eigrp topology command. With relatively general requirements, just looking at the IP routing table is fine. The example highlights R3’s topology data and IP route for subnet 10.1.1.0/24. Of more interest might be the fact that the show ip route command output on R3 lists all subnet/network numbers except one: subnet 10.1.222.0/27. This subnet exists off R2’s Fa0/1 interface (as seen in Figure 4-1), which is the interface on which EIGRP has not yet been enabled.

Internals Review

To complete the review of prerequisite CCNA-level EIGRP knowledge, this section looks at a few of the internals of EIGRP. Some of the facts listed here simply need to be memorized, whereas other topics will be discussed in more detail later.

EIGRP follows three general steps to add routes to the IP routing table, as follows:

• Step 1. Neighbor discovery: EIGRP routers send Hello messages to discover potential neighboring EIGRP routers and perform basic parameter checks to determine which routers should become neighbors.
• Step 2. Topology exchange: Neighbors exchange full topology updates when the neighbor relationship comes up, and then only partial updates as needed based on changes to the network topology.
• Step 3. Choosing routes: Each router analyzes its respective EIGRP topology table, choosing the lowest-metric route to reach each subnet.

Because the majority of the rest of this chapter examines EIGRP neighborships, this review section skips any discussion of EIGRP neighbors, instead focusing on topology exchange and route selection.

Exchanging Topology Information

First, the EIGRP neighbor table lists the neighboring routers. Second, the EIGRP topology table holds all the topology information learned from EIGRP neighbors. Finally, EIGRP chooses the best IP routes, and those routes become candidates to be injected into the IP routing table. (Table 4-2, earlier in this chapter, lists the show commands that can be used to examine these tables.) EIGRP routers follow the process shown in Figure 4-2 to build the necessary information in these tables, with the end goal of populating the IP routing table.

EIGRP uses Update messages to send topology information to neighbors. These Update messages can be sent to multicast IP address 224.0.0.10 if the sending router needs to update multiple routers on the same subnet. Unlike OSPF, there is no concept of a designated router (DR) or backup designated router (BDR), but the use of multicast packets on LANs allows EIGRP to exchange routing information with all neighbors on the LAN efficiently.

The update messages are sent using the Reliable Transport Protocol (RTP). The significance of RTP is that, like OSPF, EIGRP resends routing updates that are lost in transit. By using RTP to guarantee delivery of the EIGRP messages, EIGRP can better avoid loops.

Neighbors use both full routing updates and partial updates, as depicted in Figure 4-2. A full update means that a router sends information about all known routes, whereas a partial update includes only information about recently changed routes. Full updates occur when neighbors first come up. After that, the neighbors send only partial updates in reaction to changes to a route.

Calculating the Best Routes for the Routing Table

EIGRP topology information includes the subnet number and mask, along with the components of the EIGRP composite metric. Each router then calculates an integer metric for each route, using the individual values of the EIGRP metric components listed in the EIGRP topology database. By default, EIGRP only uses the bandwidth and delay settings when calculating the metric. Optionally, the calculation can also include interface load and interface reliability, although Cisco recommends against using either.

EIGRP calculates the metric for each possible route by inserting the values of the composite metric into a formula. If the choice is made to just use the default parameters of bandwidth and delay, the formula is as follows:

In this formula, the term least-bandwidth represents the lowest-bandwidth link in the route, using a unit of kilobits per second. For example, if the slowest link in a route is a 10-Mbps Ethernet link, the first part of the formula is 10⁷ / 10⁴, because 10 Mbps equals 10,000 kbps, or 10⁴ kbps. The cumulative-delay value used by the formula is the sum of all the delay values for all links in the route, with a unit of “tens of microseconds.” So, if you add up all the delays (from the output of the show interfaces type number command) from all egress interfaces, you would take that number (which is in microseconds) and divide by 10 (to give you a unit of tens of microseconds) for use in the formula. You can set both bandwidth and delay for each link, using the bandwidth and delay interface subcommands.

Table 4-3 summarizes some of the key facts about EIGRP.

Table 4-3 EIGRP Feature Summary

Feature	Description
Transport	I P, protocol type 88 (does not use UDP or TCP).
Metric	Based on constrained bandwidth and cumulative delay by default, and optionally load and reliability.
Hello interval	Interval at which a router sends EIGRP Hello messages on an interface.
Hold Timer	Timer used to determine when a neighboring router has failed, based on a router not receiving any EIGRP messages, including Hellos, in this timer period.
Update destination address	Normally sent to 224.0.0.10, with retransmissions being sent to each neighbor’s unicast IP address. Can also be sent to the neighbor’s unicast IP address.
Full or partial updates	Full updates are used when new neighbors are discovered; otherwise, partial updates are used.
Authentication	Supports MD5 authentication only.
VLSM/classless	EIGRP includes the mask with each route, also allowing it to support discontiguous networks and VLSM.
Route tags	Allows EIGRP to tag routes as they are redistributed into EIGRP.
Next-hop field	Supports the advertisement of routes with a different next-hop router than the advertising router.
Manual route summarization	Allows route summarization at any point in the EIGRP network.
Automatic summarization	EIGRP supports, and defaults to use, automatic route summarization at classful network boundaries.
Multiprotocol	Supports the advertisement of IPX, AppleTalk, IP version 4, and IP version 6 routes.

This completes the CCNA-level EIGRP review. The rest of this chapter now examines EIGRP neighbor relationships.

EIGRP Neighborships

Like OSPF, EIGRP uses three major steps to achieve its goal of learning the best available loop-free routes:

• Step 1. Establish EIGRP neighbor relationships—neighborships—with other routers that share a common subnet.
• Step 2. Exchange EIGRP topology data with those neighbors.
• Step 3. Calculate the currently best IP route for each subnet, based on the known EIGRP topology data, and add those best routes to the IP routing table.

This three-step process hinges on the first step—the successful creation of neighbor relationships between EIGRP routers. The basic EIGRP configuration described earlier in this chapter, particularly the network command, most directly tells EIGRP on which interfaces to dynamically discover neighbors. After EIGRP neighborships have been formed with neighboring routers that are reachable through those interfaces, the final two steps occur without any additional direct configuration.

EIGRP dynamically discovers neighbors by sending EIGRP Hello messages on each EIGRP-enabled interface. When two routers hear EIGRP Hello messages from each other, they check the EIGRP parameters listed in those messages and decide whether the two routers should or should not become neighbors.

The rest of this section focuses on topics related to EIGRP neighborship, specifically:

• Manipulating EIGRP Hello and Hold Timers
• Controlling whether routers become neighbors by using either passive interfaces or statically defined neighbors
• Examining configuration settings that can prevent EIGRP neighborships

Manipulating EIGRP Hello and Hold Timers

The word convergence defines the overall process by which routers notice internetwork topology changes, communicate about those changes, and change their routing tables to contain only the best currently working routes. EIGRP converges very quickly, even with all default settings.

One of the slower components of the EIGRP convergence process relates to the timers that EIGRP neighbors use to recognize that a neighborship has failed. If the interface over which the neighbor is reachable fails, and Cisco IOS changes the interface state to anything other than “up/up,” a router immediately knows that the neighborship should fail. However, in some cases, an interface state might stay “up/up” during times when the link is not usable. In such cases, EIGRP convergence relies on the Hold Timer to expire, which by default, on LANs, means a 15-second wait. (The default EIGRP Hold time on interfaces/subinterfaces with a bandwidth of T1 or lower, with an encapsulation type of Frame Relay, is 180 seconds.)

The basic operation of these two timers is relatively simple. EIGRP uses the Hello messages in part as a confirmation that the link between the neighbors still works. If a router does not receive a Hello from a neighbor for one entire Hold time, that router considers the neighbor to be unavailable. For example, with a default LAN setting of Hello = 5 and Hold = 15, the local router sends Hellos every 5 seconds. The neighbor resets its downward-counting Hold Timer to 15 upon receiving a Hello from that neighbor. Under normal operation on a LAN, with defaults, the Hold Timer for a neighbor would vary from 15, down to 10, and then be reset to 15. However, if the Hellos were no longer received for 15 seconds, the neighborship would fail, driving convergence.

To optimize convergence, an engineer could simply reduce the Hello and Hold Timers, accepting insignificant additional overhead, in return for shorter convergence times. These settings can be made per interface/subinterface, and per EIGRP process.

Configuring the Hello/Hold Timers

Most design engineers would normally choose Hello/Hold Timers that match on all router interfaces on a subnet. However, these settings do not have to match. Interestingly, by setting the Hello and Hold Timers to nondefault values, you can see some oddities with how EIGRP neighbors use these values.

For example, consider four WAN distribution routers, as shown in Figure 4-3. These routers might each have a number of Frame Relay PVCs to remote branches, or multiple MPLS VPN connections to branches. However, to communicate with each other and with data centers at the home office, these four routers connect through a core VLAN/subnet. Note that the design shows routers, rather than Layer 3 switches, but the concept is the same in either case.

A design that hoped to speed EIGRP convergence might call for setting the Hello and Hold Timers to 2 and 6, respectively. (The Hold Timer does not have to be three times the Hello Timer, but the 3:1 ratio is a reasonable guideline.) However, to make an important point about operation of the configuration commands, Example 4-3 sets only R1’s Fa0/1 timers to the new values. Note that in this case, EIGRP has already been configured on all four routers, using ASN 9.

Example 4-3 EIGRP Hello and Hold Timer Configuration—R1

interface Fastethernet0/1

 ip hello-interval eigrp 9 2

 ip hold-time eigrp 9 6

A couple of interesting points can be made about the operation of these seemingly simple commands. First, these two settings can be made per interface/subinterface, but not per neighbor. In Figure 4-3, the Example 4-3 configuration then applies on R1 for all three neighbors reachable on interface Fa0/1.

The second interesting point about these commands is that one parameter (the Hello Interval) tells R1 what to do, whereas the other (the Hold Timer) actually tells the neighboring routers what to do. As shown in Figure 4-4, the ip hello-interval eigrp 9 2 interface subcommand tells R1 to send Hellos every 2 seconds. However, the ip hold-time eigrp 9 6 interface subcommand tells R1, again for the EIGRP process with ASN 9, to tell its neighbors to use a Hold Timer of 6 for their respective neighbor relationships with R1. In short, the EIGRP Hello message sent by R1 announces the Hold Timer that other routers should use in the neighbor relationship with R1. Figure 4-4 shows this idea in graphical form.

Verifying the Hello/Hold Timers

To find the Hello interface and Hold time configured on a router’s interface, you could of course look at a router’s configuration, but the show running-config command might not be available to you on some question types on the ROUTE exam. However, if you have access to only user mode, you can issue the show ip eigrp interfaces detail type number command. It’s important to note, however, that if you use that command on some older versions of Cisco IOS, the Hold time might not displayed.

Example 4-4 shows some sample command output from R1, R2, and R3. Note that the Hello and Hold Timer settings on R1 are all in the range of 10–15 seconds, because the timers on R2, R3, and R4 all still default to 5 and 15 seconds, respectively. R2’s neighborship with R1 lists a Hold Timer of 4, which is within the expected range of 4–6 seconds remaining.

Example 4-4 Demonstration that R2 and R3 Use R1’s Configured Hold Timer

! On Router R1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R1# show ip eigrp interfaces detail fa0/1

EIGRP-IPv4 Interfaces for AS(9)

                 Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending

Interface Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes

Fa0/1       3        0/0       0/0         535       0/1            50          0

  Hello-interval is 2, Hold-time is 6
  Split-horizon is enabled
  Next xmit serial <none>
  Packetized sent/expedited: 0/0
  Hello's sent/expedited: 102/1
  Un/reliable mcasts: 0/1  Un/reliable ucasts: 4/9
  Mcast exceptions: 1  CR packets: 1  ACKs suppressed: 1
  Retransmissions sent: 2  Out-of-sequence rcvd: 0
  Topology-ids on interface - 0
  Authentication mode is not set


R1# show ip eigrp neighbors

IP-EIGRP neighbors for process 9

H   Address             Interface  Hold Uptime          SRTT    RTO    Q    Seq

                                    (sec)               (ms)          Cnt   Num

2   172.16.1.4            Fa0/1        11 00:03:17      1596    5000   0    7

1   172.16.1.3            Fa0/1        11 00:05:21         1    200    0    5

0   172.16.1.2            Fa0/1        13 00:09:04         4    200    0    2

! On Router R2: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R2# show ip eigrp neighbors

IP-EIGRP neighbors for process 9

H   Address             Interface  Hold Uptime          SRTT    RTO    Q    Seq

                                    (sec)               (ms)          Cnt   Num

2   172.16.1.4           Fa0/1       11 00:03:36          4     200    0    6

1   172.16.1.3           Fa0/1       11 00:05:40         12     200    0    4

0   172.16.1.1           Fa0/1        4 00:09:22          1     200    0    2


! On Router R3: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

R3# show ip eigrp neighbors

IP-EIGRP neighbors for process 9

H   Address             Interface  Hold Uptime          SRTT    RTO     Q    Seq

                                    (sec)               (ms)           Cnt   Num

2   172.16.1.4           Fa0/1         11 00:03:40        4      200    0    5

1   172.16.1.1           Fa0/1         5 00:05:44      1278     5000    0    4

0   172.16.1.2           Fa0/1         13 00:05:44     1277     5000    0    4

Preventing Unwanted Neighbors Using Passive Interfaces

When an EIGRP network configuration subcommand matches an interface, EIGRP on that router does two things:

• Step 1. Attempts to find potential EIGRP neighbors by sending Hellos to the 224.0.0.10 multicast address
• Step 2. Advertises the subnet connected to that interface

In some cases, however, no legitimate EIGRP neighbors might exist off an interface. For example, consider the small internetwork shown in Figure 4-5, with three routers, and with only one router connected to each LAN interface. Each router needs to advertise the subnets connected to their various FastEthernet interfaces, but at the same time, there is no benefit to multicast EIGRP Hellos on those interfaces, because only one router connects to each LAN.

The network designer can reasonably choose to limit EIGRP on those interfaces that have no legitimate EIGRP neighbors. However, the subnets connected to those same interfaces also typically need to be advertised by EIGRP. For example, subnet 10.1.1.0/24, off R1’s Fa0/0 interface, still needs to be advertised by EIGRP, even though R1 should never find an EIGRP neighbor on that interface.

Given such a requirement—to advertise the subnet while disallowing EIGRP neighborships on the interface—an engineer has two main configuration options to choose from:

• Enable EIGRP on the interface using the EIGRP network command, but tell the router to not send any EIGRP messages on the interface by making the interface passive (using the passive-interface command).
• Do not enable EIGRP on the interface, and advertise the connected route using route redistribution (and the redistribute connected configuration command).

The first option relies on the passive interface feature—a feature specifically created with this design requirement in mind. When an interface is passive, EIGRP does not send any EIGRP messages on the interface—multicasts or EIGRP unicasts—and the router ignores any EIGRP messages received on the interface. However, EIGRP still advertises the connected subnets if matched with an EIGRP network command. As a result, the first option in the preceding list directly meets all the design requirements. It has the added advantage of being very secure in that no EIGRP neighborships are possible on the interface.

The second option—redistributing connected subnets—also works, but frankly it is the less preferred option in this case. Specifically, the passive interface option clearly meets the design requirements, while the redistribution option causes the connected route to be advertised as an external EIGRP route. This could cause problems in some cases with multiple redistribution points between routing domains (as discussed in Chapter 10, “Route Redistribution”).

The configuration of the passive interface itself is fairly straightforward. To configure the passive interface option, these three routers could be configured as shown in Example 4-5.

Example 4-5 Configuration of passive-interface Commands on R1, R2, and R3

! On Router R1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router eigrp 1

 passive-interface fastethernet0/0

 passive-interface fastethernet0/1

 network 10.0.0.0

 network 192.168.9.0

! On Router R2: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router eigrp 1

 passive-interface default

 no passive-interface serial0/0/0

 no passive-interface serial0/0/1

 network 10.0.0.0

! On Router R3: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

router eigrp 1

 passive-interface fastethernet0/0

 network 10.0.0.0

R1’s configuration lists two passive-interface commands, one per LAN interface. As a result, R1 no longer sends EIGRP messages on these two interfaces, including the multicast EIGRP Hellos used to discover neighbors.

R2’s configuration uses a slightly different option: the passive-interface default command. This command essentially changes the default for an interface from not being passive to instead being passive. Then, to make an interface not passive, you have to use a no version of the passive-interface command for those interfaces.

Two commands help to verify that the passive interface design is working properly. First, the show ip eigrp interfaces command omits passive interfaces, listing the nonpassive interfaces matched by a network command. Alternatively, the show ip protocols command explicitly lists all passive interfaces. Example 4-6 shows samples of both commands on R2.

Example 4-6 Verifying the Results of passive-interface on R2

R2# show ip eigrp interfaces

IP-EIGRP interfaces for process 1


                        Xmit Queue    Mean      Pacing Time      Multicast   Pending

Interface      Peers    Un/Reliable   SRTT      Un/Reliable      Flow Timer  Routes

Se0/0/0          1         0/0         32          0/15              159      0

Se0/0/1          1         0/0       1290          0/15             6443      0

R2# show ip protocols

Routing Protocol is "eigrp 1"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Default networks flagged in outgoing updates

  Default networks accepted from incoming updates

  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

  EIGRP maximum hopcount 100

  EIGRP maximum metric variance 1

  Redistributing: eigrp 1

  EIGRP NSF-aware route hold timer is 240s

  Automatic network summarization is in effect

  Maximum path: 4

  Routing for Networks:

    10.0.0.0

  Passive Interface(s):

    FastEthernet0/0

    FastEthernet0/1

  Routing Information Sources:

    Gateway         Distance      Last Update

    10.1.12.1             90      00:00:39

    10.1.23.1             90      00:00:39

  Distance: internal 90 external 170

Controlling Neighborships with Static Configuration

EIGRP supports the ability to statically define neighbors instead of dynamically discovering neighbors.

Although seldom used, you can use this feature to reduce the overhead associated with EIGRP multicast messages. Frame Relay WANs in particular might benefit from the static neighbor definitions, because to support multicasts and broadcasts over Frame Relay, a router must replicate a frame and send a copy over every PVC associated with the interface or subinterface. For example, if a multipoint subinterface has ten PVCs associated with it, but only two of the remote routers used EIGRP, without static neighbors, all ten routers would be sent a copy of the EIGRP multicast Hello packets. With static neighbor definitions for the two routers, EIGRP messages would be sent as unicasts to each of the two neighbors, with no EIGRP messages sent to the eight non-EIGRP routers, reducing overhead.

The configuration seems simple, but it has a few subtle caveats. This section examines the straightforward configuration first and then examines the caveats.

Configuring Static EIGRP Neighbors

To define a neighbor, both routers must configure the neighbor ip-address outgoing-interface EIGRP router subcommand. The IP address is the interface IP address of the neighboring router. Also, the configured IP address must be from the subnet connected to the interface listed in the neighbor command; otherwise, the command is rejected. Also, note that the EIGRP configuration still needs a network command that matches the interface referenced by the neighbor command.

For example, consider Figure 4-6, which adds a new router (R5) to the internetwork of Figure 4-3. R1 and R5 have a PVC connecting them, with IP addresses and subinterface numbers shown.

Example 4-7 shows the configuration on both R1 and R5 to use static neighbor definitions. Of note, R1’s neighbor command refers to R5’s IP address on their common subnet (10.10.15.5), with R1’s local interface (S0/0/0.5). R5 lists the reverse, with R1’s 10.10.15.1 IP address and R5’s local S0/0.1 interface. Also note that both routers have a network command that references network 10.0.0.0, and both routers do advertise subnet 10.10.15.0/29.

The show ip eigrp neighbors command does not identify a neighbor as static, but the show ip eigrp neighbors detail command does. Example 4-7 shows the more detailed output near the end, with the designation of 10.10.15.5 (R5) as a static neighbor.

Example 4-7 Static EIGRP Neighborship Between R1 and R5

! New configuration on router R1

R1# show running-config

! lines omitted

router eigrp 9

 network 172.16.0.0

 network 10.0.0.0

 no auto-summary

 neighbor 10.10.15.5 Serial0/0/0.5

! Back to R1

R1# show ip eigrp neighbors detail

IP-EIGRP neighbors for process 9

H   Address                 Interface    Hold Uptime  SRTT  RTO      Q       Seq

                                            (sec)     (ms)          Cnt      Num

3   10.10.15.5              Se0/0/0.5   10 00:00:51     15  200      0        2

   Static neighbor

   Version 12.4/1.2, Retrans: 0, Retries: 0

2   172.16.1.2              Fa0/1       11 00:02:57     3  200       0       25

   Version 12.4/1.2, Retrans: 1, Retries: 0

1   172.16.1.3              Fa0/1        10 00:03:45    5  200       0       21

   Version 12.4/1.2, Retrans: 0, Retries: 0

0   172.16.1.4              Fa0/1        13 00:03:45    5  200       0       18

! R5's new config added to support the neighbor

R5# show running-config

! lines omitted

router eigrp 9

 network 10.0.0.0

 no auto-summary

 neighbor 10.10.15.1 Serial0/0.1

Caveat When Using EIGRP Static Neighbors

Cisco IOS changes how it processes EIGRP packets on any interface referenced by an EIGRP neighbor command. Keeping in mind the design goal for this feature—to reduce multicasts—Cisco IOS disables all EIGRP multicast packet processing on an interface when an EIGRP neighbor command has been configured. For example, in Example 4-7, R1’s S0/0/0.5 subinterface will not process EIGRP multicast packets any more as a result of R1’s neighbor 10.10.15.5 Serial0/0/0.5 EIGRP subcommand.

Because of the operation of the EIGRP neighbor command, if at least one EIGRP static neighbor is defined on an interface, no dynamic neighbors can be either discovered or continue to work if already discovered. For example, again in Figure 4-6 and Example 4-7, if R1 added a neighbor 172.16.1.5 FastEthernet0/1 EIGRP subcommand, R1 would lose its current neighborships with Routers R2, R3, and R4.

Configuration Settings That Could Prevent Neighbor Relationships

Some of the configuration settings already mentioned in this chapter, when configured incorrectly, might prevent EIGRP neighborships. This section summarizes those settings, and introduces a few other configuration settings that can prevent neighbor relationships. The list of items that must match—and that do not have to match—can be a useful place to start troubleshooting neighbor initialization problems in real life, and to troubleshoot neighborship problems for simulation questions on the CCNP ROUTE exam.

Table 4-4 lists the neighbor requirements for both EIGRP and Open Shortest Path First (OSPF). (OSPF is included here just as a frame of reference for those more familiar with OSPF; this information will be repeated in Chapter 7, “Fundamental OSPF Concepts,” which discusses OSPF neighborship requirements.) Following the table, the next few pages examine some of these settings for EIGRP.

Table 4-4 Neighbor Requirements for EIGRP and OSPF

Requirement	EIGRP	OSPF
The routers must be able to send/receive IP packets to one another.	Yes	Yes
Interfaces’ primary IP addresses must be in same subnet.	Yes	Yes
Must not be passive on the connected interface.	Yes	Yes
Must use the same ASN (EIGRP) or process-ID (OSPF) in the router configuration command.	Yes	No
Hello interval/timer, plus either the Hold (EIGRP) or Dead (OSPF) timer, must match.	No	Yes
Must pass neighbor authentication (if configured).	Yes	Yes
Must be in same area.	N/A	Yes
IP MTU must match.	No	Yes
K-values (used in metric calculation) must match.	Yes	—
Router IDs must be unique.	No 1	Yes

Going through Table 4-4 sequentially, the first two items relate to IP connectivity. Two routers must be able to send and receive IP packets with each other. Additionally, the primary IP address on the interfaces—in other words, the IP address configured without the secondary keyword on the ip address command—must be in the same subnet.

The next three items in Table 4-4—passive interfaces, matching the EIGRP ASN number, and allowing mismatching Hello/Hold Timers—have already been covered in this chapter.

The next item, authentication, is discussed in detail in Chapter 17, “Routing Protocol Authentication.”

The next two items in the table—matching the IP MTU and matching OSPF areas—do not prevent EIGRP neighborships. These topics, are requirements for OSPF neighborship and will be discussed in Chapter 7.

Finally, the last two items in the table (K-values and router IDs) each require more than a cursory discussion for EIGRP and will be explained in the upcoming pages.

Configuring EIGRP Metric Components (K-values)

EIGRP calculates its integer metric, by default, using a formula that uses constraining bandwidth and cumulative delay. You can change the formula to use link reliability and link load, and even disable the use of bandwidth and/or delay. To change the formula, an engineer can configure five weighting constants, called K-values, which are represented in the metric calculation formula as constants K1, K2, K3, K4, and K5.

From a design perspective, Cisco strongly recommends against using link load and link reliability in the EIGRP metric calculation. Most shops that use EIGRP never touch the K-values at all. However, in labs, it can be useful to disable the use of bandwidth from the metric calculation, because that simplifies the metric math and makes it easier to learn the concepts behind EIGRP.

The metric weights command sets five variables (K1 through K5), each of which weights the metric calculation formula more or less heavily for various parts of the formula. Mismatched K-value settings prevent two routers from becoming neighbors. Thankfully, determining whether such a mismatch exists is easy. When a router receives an EIGRP Hello with mismatched K-values (as compared to itself), the router issues a log message stating that a K-value mismatch exists. You can also examine the values either by looking at the running configurations or by looking for the K-values listed in the output of the show ip protocols command, as shown in Example 4-8.

Example 4-8 Mismatched K-values

R2(config)# router eigrp 1

R2(config-router)# metric weights 0 1 0 1 1 0

R2(config-router)# end

Feb 23 18:48:21.599: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0/1) is down: metric changed

R2#

Feb 23 18:48:24.907: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.12.1 (Serial0/0/1) is down: K-value mismatch

R2# show ip protocols

Routing Protocol is "eigrp 1"

  Outgoing update filter list for all interfaces is not set

  Incoming update filter list for all interfaces is not set

  Default networks flagged in outgoing updates

  Default networks accepted from incoming updates

  EIGRP metric weight K1=1, K2=0, K3=1, K4=1, K5=0

! lines omitted for brevity

EIGRP Router ID

EIGRP uses a concept of a representing each router with a router ID (RID). The EIGRP RID is a 32-bit number, represented in dotted decimal. Each router determines its RID when the EIGRP process starts, using the same general rules as does OSPF for determining the OSPF RID, as follows:

• Step 1. Use the configured value (using the eigrp router-id a.b.c.d EIGRP subcommand).
• Step 2. Use the highest IPv4 address on an up/up loopback interface.
• Step 3. Use the highest IPv4 address on an up/up nonloopback interface.

Although EIGRP does require each router to have an RID, the actual value is of little practical importance. The EIGRP show commands seldom list the RID value, and unlike OSPF RIDs, engineers do not need to know each router’s EIGRP RID to interpret the EIGRP topology database. Additionally, although it is best to make EIGRP RIDs unique, duplicate RIDs do not prevent routers from becoming neighbors.

The only time the value of EIGRP RIDs matters is when injecting external routes into EIGRP. In that case, the routers injecting the external routes must have unique RIDs to avoid confusion.

Neighborship over WANs

EIGRP configuration and neighborship rules do not differ when comparing typical LAN and typical WAN technologies. However, some design and operational differences exist, particularly regarding which routers become neighbors with which other routers. This short section closes the EIGRP neighbor discussion with a brief look at Frame Relay, MPLS VPNs, and Metro Ethernet as implemented with Virtual Private LAN Service (VPLS).

Neighborship on Frame Relay

Frame Relay provides a Layer 2 WAN service. Each router connects to the service using a physical serial link, called a Frame Relay access link. The provider then creates logical connections, called permanent virtual circuits (PVC), which are logical paths between pairs of routers connected to a Frame Relay service. Any pair of routers that connect to the ends of a Frame Relay PVC can send Frame Relay frames to each other. Therefore, they can send IP packets and become EIGRP neighbors. Figure 4-7 shows a typical case, with R1 as a central-site router, and R2, R3, and R4 acting as branch routers.

Figure 4-7 shows EIGRP neighborships, but note that all routers can learn all routes in the internetwork, even though not all routers become neighbors. The neighborships can only form when a PVC exists between the two routers.

Neighborship on MPLS VPN

Multiprotocol Label Switching (MPLS) Virtual Private Networks (VPN) create a WAN service that has some similarities but many differences when compared to Frame Relay. The customer routers connect to the service, often with serial links but at other times with Frame Relay PVCs or with Ethernet. The service itself is a Layer 3 service, forwarding IP packets through a cloud. As a result, no predefined PVCs need to exist between the customer routers. Additionally, the service uses routers at the edge of the service provider cloud—generically called provider edge (PE) routers—and these routers are Layer 3 aware.

That Layer 3 awareness means that the customer edge (CE) routers form an EIGRP neighborship with the PE router on the other end of their local access link, as shown in Figure 4-8. The PE routers exchange their routes, typically using Multiprotocol BGP (MP-BGP), a topic outside the scope of this book. However, all the CE routers then learn routes from each other, although each CE router has only one EIGRP neighborship for each of its connections into the MPLS VPN cloud.

Neighborship on Metro Ethernet

The term Metropolitan Ethernet (MetroE) represents a range of Layer 2 WAN services in which the CE device connects to the WAN service using some form of Ethernet. Because MetroE provides a Layer 2 Ethernet service, the service delivers an Ethernet frame sent by one customer router to another customer router (for unicast frames), or to many other routers (for multicast or broadcast frames).

MetroE encompasses several underlying technologies to create the service. Of note for the purposes of this book are the Virtual Private Wire Service (VPWS) and the Virtual Private LAN Service (VPLS). Both technical specifications allow for connections using Ethernet links, with the service forwarding Ethernet frames. VPWS focuses on point-to-point topologies, whereas VPLS supports multipoint, approximating the concept of the entire WAN service acting like one large Ethernet switch. Because it is a Layer 2 service, MetroE does not have any Layer 3 awareness, and customer routers (typically referenced with the more general service provider term customer premises equipment, or CPE) see the MetroE service as a VLAN. Because the customer routers connect to the service as a VLAN, all the routers connected to the service can become EIGRP neighbors, as shown in Figure 4-9.