EIGRP Neighborships ccsp course training in gurgaon

Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192

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
■ Authenticating EIGRP 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
EIGRP neighbors use to recognize that the neighborship has failed. If the interface over
which the neighbor is reachable fails, and IOS changes the interface state to anything other
than “up/up”, then a router immediately knows that the neighborship should fail. However,
in some cases, the interface state may stay “up/up” during times when the link may not be
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 with
interfaces/subinterfaces with a bandwidth of T1 or slower, with encapsulation of Frame
Relay, is 60 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 have failed. For example, with a default LAN setting of Hello of 5, and
Hold of 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.
Note: Although expected to be outside the scope of CCNP, EIGRP can also use the Bidirectional
Forwarding Detection (BFD) feature that provides a means for subsecond detection
of a failure in IP connectivity between two neighboring routers.
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. More interestingly,
by setting the Hello and Hold Timers to nondefault values, you can see some oddities
with the configuration of these values.
For example, consider four WAN distribution routers, as shown in Figure 2-3. These routers
may 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 via a core VLAN/subnet. Note that the design
shows routers, rather than Layer 3 switches, but the concept applies the same in either case.
Note: All IP addresses begin with 172.16.1
To Data Centers
R2
R1
R4
R3
Fa0/1
.2/24
.3/24
.1/24
.4/24
Fa0/1
Fa0/1
Fa0/1
To Branches
To Branches
Figure 2-3 Four WAN Distribution Routers on the Same VLAN/Subnet
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 2-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 2-3 EIGRP Hello and Hold Timer Configuration—R1
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 2-3, the Example 2-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 2-4, 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 2-4 shows the same idea in graphical form.
Note: IOS does not prevent you from making the unfortunate configuration choice of
setting the Hold timer to a value smaller than the Hello interval. In such a case, the neighborship
repeatedly fails and recovers, flapping routes in and out of the routing table.
Verifying the Hello/Hold Timers
Interestingly, finding the settings for the Hello interval and Hold time requires more effort
than simply using a show command. A router’s Hello timer can be seen with the show ip
eigrp interface type number detail command, but this command does not display a
router’s Hold Timer on the interface. You can of course look at a router’s configuration,
but the show running-config command may not be available to you on some question
types on the ROUTE exam. However, if you have access to only user mode, you can typically
make a good guess as to the settings by repeatedly using the show ip eigrp neighbors
command. This command shows the current value of the Hold Timer for each
neighbor. By repeating the command during times when everything is working, and observing
the range of values, you should be able to infer each router’s Hello and Hold Timer
settings.
Example 2-4 shows examples of the command output on R1, R2, and R3. Note that the
Hello and Hold Timer settings on R1 are all between 10—15 seconds, because the timers
Controlling Neighborships Using EIGRP Authentication
EIGRP authentication causes routers to authenticate every EIGRP message. To do so, the
routers should use the same preshared key (PSK), generating an MD5 digest for each
EIGRP message based on that shared PSK. If a router configured for EIGRP authentication
receives an EIGRP message, and the message’s MD5 digest does not pass the authentication
checking based on the local copy of the key, the router silently discards the
message. As a result, when authentication fails, two routers cannot become EIGRP neighbors,
because they ignore the EIGRP Hello messages.
From a design perspective, EIGRP authentication helps prevent denial of service (DoS) attacks,
but it does not provide any privacy. The EIGRP messages can be read by the device
www.CareerCert.info
40 CCNP ROUTE 642-902 Official Certification Guide
that physically receives the bits. Note that on LANs, the updates flow to the 224.0.0.10
multicast IP address, so any attacker could join the 224.0.0.10 multicast group and read the
packets. However, authentication prevents attackers from forming neighborships with legitimate
routers, preventing the advertisement of incorrect routing information.
Next, this section examines EIGRP authentication configuration generically, followed by a
deeper look at the time-based authentication configuration settings, and finally showing
an example of EIGRP authentication configuration.
EIGRP Authentication Configuration Checklist
The EIGRP authentication configuration process requires several commands, which are
summarized as follows:
Step 1. Create an (authentication) key chain:
Create the chain and give it a name with the key chain name global command
(also puts the user into key chain config mode). The name does not have to
match on the neighboring routers.
Create one or more key numbers using the key number command in key
chain configuration mode. The key numbers do not have to match on the
neighboring routers.
Define the authentication key’s value using the key-string value command in
key configuration mode. The key strings must match on the neighboring routers.
(Optional) Define the lifetime (time period) for both sending and accepting
each key string.
Step 2. Enable EIGRP MD5 authentication on an interface, for a particular EIGRP
ASN, using the ip authentication mode eigrp asn md5 interface subcommand.
Step 3. Refer to the correct key chain to be used on an interface using the ip authentication
key-chain eigrp asn name-of-chain interface subcommand.
The configuration at Step 1 is fairly detailed, but Steps 2 and 3 are relatively simple. Essentially,
IOS configures the key values separately (Step 1) and then requires an interface subcommand
to refer to the key values. To support the ability to have multiple keys, and even
multiple sets of keys, the configuration includes the concept of a key chain and multiple
keys on each key chain.
Key Chain Time-Based Logic
The key chain configuration concept, as outlined in Step 1, allows the engineer to migrate from
one key value to another over time. Just like a real key chain that has multiple keys, the IOS key
chain concept allows the configuration of multiple keys—each identified with a number. If no
lifetime has been configured for a key, it is considered to be valid during all time frames. However,
when a key has been defined with a lifetime, the key is valid only during the valid lifetime.
The existence of multiple keys in a key chain, and the existence of valid lifetimes for each
key, can cause some confusion about when the keys are used. The rules can be summarized
as follows:
■ Sending EIGRP messages: Use the lowest key number among all currently valid keys.
■ Receiving EIGRP message: Check the MD5 digest using ALL currently valid keys.
Key
Topic
www.CareerCert.info
Chapter 2: EIGRP Overview and Neighbor Relationships 41
For example, consider the case shown in Figure 2-6. The figure represents the logic in a
single router, Router R1, both when receiving and sending EIGRP messages on the right.
The figure shows a key chain with four keys. All the keys have lifetimes configured. Key
1’s lifetime has passed, making it invalid. Key 4’s lifetime has yet to begin, making it invalid.
However, keys 2 and 3 are both currently valid.
Figure 2-6 shows that the EIGRP message sent by Router R1 uses key 2, and key 2 only.
Keys 1 and 4 are ignored because they are currently invalid; R1 then simply chooses the
lowest-numbered key among the two valid keys. The figure also shows that R1 processes
the received EIGRP message using both key 2 and key 3, because both are currently valid.
Key
Topic
Note: Neighboring EIGRP routers that use authentication should be configured to use
NTP to synchronize their time-of-day clocks. For quick tests in a lab, you can just set the
time using the clock set exec command.
EIGRP Authentication Configuration and Verification Example
Example 2-7 shows a sample configuration, based on the network topology shown back in
Figure 2-3 (the figure with four routers connected to a single LAN subnet). Key chain
“carkeys” has two keys, each with different lifetimes, so that the router will use new keys
4 Invalid: Valid-time is in future.
2 Valid
3 Valid
1 Invalid: Valid-time has passed.
Fa0/0
MD5 EIGRP
MD5 EIGRP
Valid?
R1
Valid?
Key Chain
carkeys
Figure 2-6 EIGRP’s Usage of Authentication Keys
www.CareerCert.info
42 CCNP ROUTE 642-902 Official Certification Guide
automatically over time. The example shows the configuration on a single router, but similar
configuration would be required on the other routers as well.
Example 2-7 EIGRP Authentication Configuration on R1
! Chain “carkeys” will be used on R1’s Fa0/1 interface. R1 will use key “fred” for
! about a month, and then start using “wilma.”
key chain carkeys
key 1
key-string fred
accept-lifetime 08:00:00 Feb 11 2009 08:00:00 Mar 11 2009
send-lifetime 08:00:00 Feb 11 2009 08:00:00 Mar 11 2009
key 2
key-string wilma
accept-lifetime 08:00:00 Mar 11 2009 08:00:00 Apr 11 2009
send-lifetime 08:00:00 Mar 11 2009 08:00:00 Apr 11 2009
! Next, R1’s interface subcommands are shown. First, the key chain is referenced
! using the ip authentication key-chain command, and the ip authentication mode
eigrp
! command causes the router to use an MD5 digest of the key string.
interface FastEthernet0/1
ip address 172.16.1.1 255.255.255.0
ip authentication mode eigrp 9 md5
ip authentication key-chain eigrp 9 carkeys
The best method to confirm the authentication worked is to verify that the neighbors remain
up using the show ip eigrp neighbors command. However, if some neighbors do not
remain active, and a problem exists, two commands in particular can be helpful: show key
chain and debug eigrp packet. The first of these commands lists the key chain configuration
and also lists which keys are valid right now—a key consideration when troubleshooting
EIGRP authentication. The debug command lists a message regarding why
neighboring routers have failed the authentication process.
Example 2-8 shows a sample output from each of these two commands. Note that in this
case, again from Figure 2-3:
■ R1 and R2 have been configured to use MD5 authentication, but a typo exists in R2’s
key string.
■ R3 and R4 have not yet been configured for MD5 authentication.
Example 2-8 EIGRP Authentication Verification on R1
R1#show key chain
Key-chain carkeys:
key 1 — text “fred”
www.CareerCert.info
Chapter 2: EIGRP Overview and Neighbor Relationships 43
accept lifetime (08:00:00 UTC Feb 11 2009) - (08:00:00 UTC Mar 11 2009)
send lifetime (08:00:00 UTC Feb 11 2009) - (08:00:00 UTC Mar 11 2009)
key 2 — text “wilma”
accept lifetime (08:00:00 UTC Mar 11 2009) - (08:00:00 UTC Apr 11 2009)
[valid now]
send lifetime (08:00:00 UTC Mar 11 2009) - (08:00:00 UTC Apr 11 2009)
[valid now]
R1#debug eigrp packet
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
R1#
Apr 1 08:09:01.951: EIGRP: Sending HELLO on FastEthernet0/1
Apr 1 08:09:01.951: AS 9, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
Apr 1 08:09:01.967: EIGRP: pkt key id = 2, authentication mismatch
Apr 1 08:09:01.967: EIGRP: FastEthernet0/1: ignored packet from 172.16.1.2,
opcode = 5 (invalid authentication)
Apr 1 08:09:02.287: EIGRP: FastEthernet0/1: ignored packet from 172.16.1.4,
opcode = 5 (missing authentication)
Apr 1 08:09:03.187: EIGRP: FastEthernet0/1: ignored packet from 172.16.1.3, opcode
= 5 (missing authentication)
In particular, note that the different highlighted phrasing in the debug output implies different
problems. From 172.16.1.2 (R2), the message “invalid authentication” implies that
the MD5 digest existed in the message, but was invalid. With the message “missing authentication,”
the meaning is that the message did not include an MD5 digest.
Also, when troubleshooting EIGRP authentication, keep the following in mind:
■ Examine the configuration and the current time (show clock) on both routers.
■ The key chain name and key number used on the two routers do not have to match.
■ The key string on each of the two potential neighbors must match.
■ Check which keys are currently valid using the show key chain command.
■ Both the ip authentication mode eigrp asn md5 interface subcommand and the ip
authentication key-chain eigrp asn name-of-chain interface subcommand must be
configured on the interface; if one is omitted, authentication fails.
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 RelayWANs in particular may benefit from the static
neighbor definitions because to support multicasts and broadcasts over Frame Relay, a
router must replicate the frame and send a copy over every PVC associated with the interface
or subinterface. For example, if a multicast subinterface has 10 PVCs associated
The show ip eigrp neighbors command does not identify a neighbor as static, but the
show ip eigrp neighbors detail command does. Example 2-9 shows the more detailed output
near the end, with the designation of 10.10.15.5 (R5) as a static neighbor.
Caveat When Using EIGRP Static Neighbors
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—
IOS disables all EIGRP multicast packet processing on an interface when an EIGRP
neighbor command has been configured. For example, in Example 2-9, R1’s S0/0/0.5
subinterface will not process EIGRP multicast packets any more as a result of R1’s
neighbor 10.10.5.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 2-7 and Example 2-9,
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.
www.CareerCert.info
46 CCNP ROUTE 642-902 Official Certification Guide
Table 2-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) on 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 N/A
Router IDs must be unique. No1 Yes
1Duplicate EIGRP RIDs do not prevent routers from becoming neighbors, but it can cause problems
when adding external EIGRP routes to the routing table.
Key
Topic
Configuration Settings That Could Prevent Neighbor Relationships
Some of the configuration settings already mentioned in this chapter, when configured incorrectly,
may 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 Sim questions on the CCNP ROUTE exam.
Table 2-4 lists the neighbor requirements for both EIGRP and OSPF. (OSPF is included
here just as a frame of reference for those more familiar with OSPF; this information will
be repeated in Chapter 5, “OSPF Overview and Neighbor Relationships,” which discusses
OSPF neighborship requirements.) Following the table, the next few pages examine some
of these settings for EIGRP.
Going through Table 2-4 sequentially, the first two items (highlighted) 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.
www.CareerCert.info
Chapter 2: EIGRP Overview and Neighbor Relationships 47
Note: It should not matter for CCNP ROUTE, but possibly for CCIE: EIGRP’s rules
about neighbor IP addresses being in the same subnet are less exact than OSPF. OSPF
requires matching subnet numbers and masks. EIGRP just asks the question of whether the
neighbor’s IP address is in the range of addresses for the subnet as known to the local
router. For example, two routers with addresses of 10.1.1.1/24 (range 10.1.1.1–10.1.1.254)
and 10.1.1.2/30 (range 10.1.1.1–10.1.1.2) would actually allow EIGRP neighborship, because
each router believes the neighbor’s IP address to be in the same subnet as the local router.
The next four items in Table 2-4 (unhighlighted)—passive interfaces, matching the EIGRP
ASN number, allowing mismatching Hello/Hold Timers, and authentication—have already
been covered in this chapter, and do not require any further discussion.
The next two (highlighted) 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 5.
Finally, the last two items (unhighlighted) in the table (K-values and router-id) 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, 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 kvalues
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 mechanics of setting these values (with the metric weights EIGRP subcommand) is
covered in Chapter 3, in the “Metric Weights (K-values)” section. This command sets 5
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 if 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 running configuration,
or look for the k-values listed in the output of the show ip protocols command,
as shown in Example 2-10.
www.CareerCert.info
48 CCNP ROUTE 642-902 Official Certification Guide
Example 2-10 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 non-loopback 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 for
the OSPF RID, 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.