The Bryant Advantage CCNP ROUTE Study Guide

Chris Bryant, CCIE #12933 - www.thebryantadvantage.com

Back To Index

Intermediate And Advanced EIGRP Concepts And Configuration

Fundamentals Review Packet Types Neighbor Relationships Potential Adjacency Issues Hello Packets And Secondary Addresses Successors And Feasible Successors "Stuck In Active" - Or Not? The variance Command DUAL Queries Feasible And Advertised Distance Feasibility Condition The Three EIGRP Admin Distances Route Summarization - Manual And Automatic The Mystery Of The AD 5 Design Guidelines Stub Routers Passive Interfaces And EIGRP

Propagating Default Routes With EIGRP Authenticating Neighbors

EIGRP Fundamentals Let's take a few minutes to review EIGRP fundamentals and add to those mentioned in the Basic EIGRP section. EIGRP is a Cisco-proprietary protocol that improves greatly on the original version of this protocol, the Interior Gateway Routing Protocol (IGRP). (The "E" in EIGRP stands for enhanced.) The benefits of using EIGRP include: Support for Appletalk, IP, and IPX (Novell Netware) via protocoldependent modules (PDMs) Support for variable-length subnet masking (VLSM) Dynamic neighbor discovery via packets multicast to 224.0.0.10 Fast convergence after network topology changes - backup routes are actually calculated and placed into a table in advance of their actually being needed. (Note: This table is NOT the IP routing table.) Where RIP sends routing updates every 30 seconds, even if nothing has changed, EIGRP will send routing updates only when a network topology change actually occurs. EIGRP updates do not contain the entire routing table, but reflect only the routes that have been changed. The scope of these updates is limited to the routers that actually need them - they're not flooded. Those last two points might not sound like much, but remember that everything we do on a Cisco router has a cost in CPU and in time. If your routing table has 105 routes and only 1 has changed, why take the time to create an update for every single route when an update reflecting only the change will serve our purpose? EIGRP's routing algorithm is the Diffusing Update Algorithm (DUAL). DUAL not only calculates routes that ensure a loop-free network, but also calculates backup routes before they're needed.

These backup routes, the feasible successors, are kept in the EIGRP topology table. The primary routes, the successors, are kept in both the EIGRP topology and route tables. EIGRP's third table is the neighbor table, which contains just what you would think it does - information about EIGRP neighbors. EIGRP is a classless routing protocol, which means it supports Variable Length Subnet Masking (VLSM). EIGRP routing update packets contain a prefix length for each individual network, making VLSM support possible. EIGRP uses metric weights to determine how important certain values are in route calculation. By default, bandwidth and delay are the only metric values used in route calculation. The other metric weights, or "kweights", are load, reliability, and MTU. You can change the bandwidth and delay values to alter EIGRP path selection. If you're changing any EIGRP values to fine-tune your routing table, I'd go with bandwidth as it's simply easier to get the desired results. The bandwidth command is entered in kbps and should be set to the minimum bandwidth of the path. The delay command is configured in tens of microseconds. Like I said, the bandwidth command is easier to use for fine-tuning routes.
R1(config)#int s0 R1(config-if)#bandwidth ? <1-10000000> Bandwidth in kilobits R1(config-if)#bandwidth 64 R1(config-if)#delay ? <1-16777215> Throughput delay (tens of microseconds)

Since DUAL actually calculates backup routes before they're even needed, EIGRP responds to topology changes faster than RIP (which isn't saying much) and OSPF (which is saying a lot). With EIGRP, routing loops have literally no time to form. EIGRP will perform equal-cost load-sharing over four paths by default, with a maximum of 16 paths. That value is configurable with the maximum-paths command.
R1(config)#router eigrp 100 R1(config-router)#maximum-paths ? <1-16> Number of paths

We can also perform unequal-cost load balancing with EIGRP, and we'll practice that skill later in this section. Almost all EIGRP packets are multicast to 224.0.0.10, and use IP protocol number 88. Let's take a look at the different EIGRP packet types... and see if we can spot that exception to the multicast rule.

EIGRP Packet Types And RTP EIGRP uses the Reliable Transport Protocol (RTP) to handle the guaranteed and reliable delivery of EIGRP packets to neighbors. "Guaranteed and reliable" sounds a lot like TCP, but the two are quite different in how they operate. Not all EIGRP packets are going to be sent reliably. Hello packets are used for neighbor discovery and to keep existing neighbor relationships alive; these are multicast to 224.0.0.10. Acknowledgement packets themselves are simply hello packets that contain no data. Neither Acks nor Hellos use RTP, and are therefore considered unreliable. Update packets are sent to new neighbors to allow the neighbor to build an accurate routing and topology table, and are also sent when a change in the network occurs. Update packets are generally multicast packets, but there's one important exception that you'll read about later in this section. Query packets are sent when a router loses a successor route and has no feasible successor. Reply packets are sent in response to query packets, and a reply packet indicates that a new route to the destination has been found. Update, query, and reply packets all use RTP and are considered reliable. To see how many of these packets have passed through a router, run show ip eigrp traffic.
R1#show ip eigrp traffic IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 2/2 Updates sent/received: 13/4 Queries sent/received: 0/0 Replies sent/received: 0/0 Acks sent/received: 0/2 Input queue high water mark 1, 0 drops SIA-Queries sent/received: 0/0 SIA-Replies sent/received: 0/0

To review: Hello and ACK packets are unreliable. Reply, Query, and Update packets are reliable. That's a handy troubleshooting command, too. If the Query, Reply, and Update values remain the same over a period of time, your network is stable. If they're constantly incrementing, there's a problem. The Query and Reply values will increment only if a successor route is lost. If you see

those incrementing regularly, you have yourself a flapping link (believe me, I've been there). If the SIA values are incrementing along with them, that's not good - more on that later in this part of the course.

How EIGRP Routers Become Neighbors EIGRP routers form neighbor relationships, and after the initial exchange of routing updates between neighbors, EIGRP routers will then only send routing updates when there is a change in the network topology. These neighbor relationships, or adjacencies, begin when a router first has EIGRP enabled on some or all of its interfaces with the router eigrp command. In the following example, R1 is running EIGRP on a Serial interface. R1 will multicast an EIGRP Hello packet to 224.0.0.10 out that interface in an attempt to find potential neighbors.

A downstream router, R2, receives this Hello. If certain values are agreed upon between the two, R2 will respond with an EIGRP Update packet, which contains all the EIGRP-derived routes that R2 knows.

Did you notice that the EIGRP Update packet going back to R1 was a unicast? Generally, EIGRP Update packets are multicast to 224.0.0.10, just as EIGRP Hello packets are. There's almost always an exception in networking, and that's true here as well. Update packets are unicast in this particular situation, but otherwise they're multicast.

R1 will send an EIGRP Acknowledgement packet, or ack, to let R2 know the routes in the Update packet were received. R1 will also send an Update packet of its own, unicast to R2, containing all EIGRP routes R1 has. R2 will respond with an ack of its own.

Other EIGRP Adjacency Issues (And Non-Issues) Unlike OSPF, EIGRP does not require neighbors to agree on hello and dead times. The EIGRP hold time has the same function as OSPF dead time - they're both the duration of time in which a hello must be received in order to retain the neighbor relationship. The default EIGRP hold time is three times the hello time. In the following example, an adjacency has been formed between R2 and R3 using the default values for hello and hold times as well as the metric weights. The router eigrp command indicates that both routers are in EIGRP Autonomous System (AS) 100. The AS is a logical group of EIGRP-speaking routers, and this value must match between potential neighbors. Routers must agree on the EIGRP AS number in order to become neighbors, and the interfaces through which the adjacency is to form must be on the same IP subnet. In the following example, both routers will be placed into EIGRP 100 via the following interfaces: R2: Ethernet0, 172.12.23.2 /24 R3: Ethernet0, 172.12.23.3 /24
R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 172.12.23.0 0.0.0.255 R3(config)#router eigrp 100 R3(config-router)#no auto-summary R3(config-router)#network 172.12.23.0 0.0.0.255

show ip eigrp neighbor verifies that R3 is a neighbor of R2.

R2#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface 0 172.12.23.3 Et0

Hold Uptime SRTT (sec) (ms) 14 00:28:34 0

Q Seq Cnt Num 3000 0 77

RTO

Let's change the hello timers on R2's Ethernet 0 interface and see what happens to the adjacency. I've disabled EIGRP event logging for the following example.
R2(config-if)#ip hello eigrp 100 ? <1-65535> Seconds between hello transmissions R2(config-if)#ip hello eigrp 100 30 R2#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface 0 172.12.23.3 Et0

Hold Uptime SRTT (sec) (ms) 11 00:00:12 1256

Q Seq Cnt Num 5000 0 3

RTO

Note the uptime of 12 seconds. That indicates that the EIGRP adjacency did drop, but it came right back up. The mismatched Hello timers didn't prevent the adjacency from forming again, but what about the metric weights?
R2(config)#router eigrp 100 R2(config-router)#metric weights ? <0-8> Type Of Service (Only TOS 0 supported) R2(config-router)#metric weights 0 1 1 1 1 1 R2#show ip eigrp neighbor IP-EIGRP neighbors for process 100 R2#

show ip eigrp neighbor shows us nothing because there's no neighbor to show! We can wait a long, long time for that adjacency to come back, but it's not going to. Potential EIGRP neighbors must agree on the AS number and all metric weight settings in order to become neighbors. A great command to begin troubleshooting adjacencies with is debug eigrp packets, and if there's a metric weights mismatch, you'll see the following:
R2#debug eigrp packets EIGRP Packets debugging is on (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY) R2# 01:10:00: EIGRP: Received HELLO on Ethernet0 nbr 172.23.23.3 01:10:00: AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 01:10:00: K-value mismatch

The K-value mismatch message indicates a problem with the metric weight setting.

In short, EIGRP neighbors must.... ... reside in the same EIGRP AS ... be on the same subnet ... have matching metric weights A quick note on that ip hello eigrp command - unlike OSPF, changing the EIGRP hello time does not dynamically change the hold time (dead time). EIGRP Hello Packets Hello packets find potential neighbors and also keep neighbor relationships alive. On a high-speed link, EIGRP Hello packets are sent every 5 seconds; on slower links, Hellos are sent every 60 seconds. High-speed links include broadcast technologies such as Ethernet, FDDI, and our old friend Token Ring; high bandwidth (over T1 speed) multipoint circuits, including ISDN Primary Rate Interface and Frame Relay; both Frame Relay and ATM point-to-point subinterfaces; and finally, point-to-point serial links, such as PPP and HDLC circuits. After that list, you might think there aren't any interface types left, but there are! Low-speed links include multipoint circuits running at less than T1 speed, such as ATM switched virtual circuits and multipoint interfaces, Frame Relay multipoint interfaces, and ISDN Basic Rate Interface. An EIGRP neighbor relationship is declared dead when three hello packets are missed, meaning the EIGRP dead time on an ethernet segment is 15 seconds and 180 seconds on an NBMA interface such as a Serial interface. If you change the hello transmission time, Cisco recommends you change the hold time as well to keep it to three times the hello value. To verify EIGRP neighbor relationships, run show ip eigrp neighbors.
R2#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface 0 172.12.23.3 Et0

Hold Uptime SRTT (sec) (ms) 11 00:00:12 1256

Q Seq Cnt Num 5000 0 3

RTO

From left to right, let's examine the meaning of these categories: IP-EIGRP neighbors for process 100 - The AS these neighbors are contained in.

H - The order in which the neighbors were discovered. Address - The IP address of the neighbor. Interface - The interface upon which the router is receiving hellos. Hold - Short for holdtime, the number of seconds the router will wait until it declares this particular adjacency dead. Uptime - The amount of time since this neighbor was first heard from. SRTT - Smooth Round-Trip Time. This is the number of milliseconds it takes for an EIGRP packet to be sent to that neighbor and the amount of time it takes to get an ACK from that neighbor. RTO - Retransmission TimeOut. The amount of time the software will wait until it retransmits a packet to a neighbor. Q Cnt - Queue Count. The number of EIGRP packets waiting to be sent. Seq Num - Sequence Number. This is the sequence number of the last update, reply, or query packet that was received from this particular neighbor. To debug EIGRP adjacencies, you've got two options. You can run debug eigrp neighbors, or debug ip eigrp neighbor <AS> <IP ADDRESS>. Personally, I use debug eigrp neighbors first, and if I don't get the information I need, I'll use debug ip eigrp neighbor. The output of debug eigrp neighbors looks like this during an adjacency:
6d00h: EIGRP: Neighbor(172.12.123.3) not yet found 6d00h: EIGRP: Neighbor(172.12.123.2) not yet found 6d00h: 6d00h: 6d00h: 6d00h: EIGRP: EIGRP: EIGRP: EIGRP: Neighbor(172.12.123.3) Neighbor(172.12.123.2) Neighbor(172.12.123.3) Neighbor(172.12.123.2) not not not not yet yet yet yet found found found found

6d00h: EIGRP: New peer 172.12.123.2 6d00h: EIGRP: New peer 172.12.123.3

EIGRP Adjacencies And Secondary Addresses Technically, EIGRP will not form adjacencies using secondary addresses. Even though it looks like it will. Let's take a look at R2 and R3, which will be using secondary addresses to form an EIGRP adjacency over an ethernet segment.
R2(config)#interface ethernet0 R2(config-if)#ip address 172.12.23.2 255.255.255.0

R2(config-if)#ip address 23.23.23.2 255.255.255.0 secondary R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 23.23.23.0 0.0.0.255

R3(config)#interface ethernet0 R3(config-if)#ip address 172.12.23.3 255.255.255.0 R3(config-if)#ip address 23.23.23.3 255.255.255.0 secondary R3(config)#router eigrp 100 R3(config-router)#no auto-summary R3(config-router)#network 23.23.23.0 0.0.0.255

Here's the partial output of show ip eigrp neighbor on R3:

R3#show ip eigrp neighbor IP-EIGRP neighbors for process 100 H Address Interface 0 172.12.23.2 Et0

The adjacency has formed! However, the secondary addresses were not used to form the adjacency. Note the address is actually the primary IP address on the interface, even though we used the secondary network number in the EIGRP network command. How EIGRP Routers Determine Successors And Feasible Successors Once the EIGRP neighbor relationships form, DUAL will begin sending a series of queries and responses, and these responses are used to build the EIGRP topology table. These queries and responses are sent by the Reliable Transport Protocol (RTP). As mentioned earlier, show ip eigrp traffic will display the number of queries and replies that have been sent and received.
R1#show ip eigrp traffic IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 110457/115367 Updates sent/received: 43/17 Queries sent/received: 4/0 Replies sent/received: 0/4 Acks sent/received: 14/21 Input queue high water mark 2, 0 drops SIA-Queries sent/received: 0/0 SIA-Replies sent/received: 0/0

Let's take a look at a typical EIGRP topology table.

R1#show ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(11.1.1.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status P 1.1.1.1/32, 1 successors, FD is 128256 via Connected, Loopback0 P 2.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.2 (2297856/128256), Serial0 via 172.12.123.3 (2323456/409600), Serial0 P 3.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 P 172.23.0.0/16, 2 successors, FD is 2195456 via 172.12.123.3 (2195456/281600), Serial0 via 172.12.123.2 (2195456/281600), Serial0 P 172.12.123.0/24, 1 successors, FD is 2169856 via Connected, Serial0

EIGRP will keep up to six valid routes for any given destination. Those six routes don't have to be made up of one successor and five feasible successors, either - when equal-cost load sharing is in effect as it is for the 172.23.0.0 /16 route in the above topology table, there will be multiple successor routes. "SIA" -- Stuck In Active Regarding those codes, notice that all the routes in this table have a "P" next to them, indicating that these routes are passive. Another code shown is "A", for Active. While an "active route" sounds like a good thing, we want to avoid them in EIGRP. If a route shows as Active in the EIGRP topology table, that means the successor for that route has been lost and that no feasible successor was immediately available in the topology table. When a route is Passive, that means it's not being recalculated and it's a usable route. Generally, an Active route will be that way for a very short time; by the time you repeat show ip eigrp topology, it's likely that Active route has gone Passive. That cutover from Active to Passive is so fast that you can work with EIGRP for a long time without even seeing an Active route. Sometimes that doesn't cutover doesn't happen at all, and the route becomes SIA - Stuck In Active. SIA routes begin innocently enough. When an EIGRP router loses a Successor route, it looks in its topology table for a Feasible Successor. If there is no Feasible Successor, that router will send DUAL Query packets to its neighbors, asking them if they have a valid route to the nowunreachable destination.

If the router receiving the query doesn't have a valid, loop-free route to the destination in question within a certain amount of time, that router will in turn ask all of its neighbors for such a route - and they'll ask two friends, and they'll ask two friends, until a route is discovered or it's determined that no queried router has a route. That default time is three minutes and can be changed with the timers active-time command in your EIGRP configuration.
R1(config)#router eigrp 100 R1(config-router)#timers ? active-time EIGRP time limit for active state R1(config-router)#timers active-time ? <1-4294967295> EIGRP active-state time limit in minutes disabled disable EIGRP time limit for active state <cr> R1(config-router)#timers active-time 5

Two things to note in this command: IOS Help shows us the numeric value is minutes. With many Cisco commands, setting a numeric value to zero disables that particular feature - but you can't set this one to zero. To disable the time limit, use the disabled option. If R8 doesn't answer that query within a certain period of time, the route is Stuck In Active - SIA. From experience, I can tell you that troubleshooting SIA routes is more of an art form than a science, but there are four main reasons a route becomes SIA: The link is unidirectional, so the query can't possibly be answered. The queried router's resources are unavailable, generally due to high CPU utilization. The queried router's memory is corrupt or otherwise unable to allow the router to answer the query. The link between the two routers is of low quality, allowing just

enough packets through to keep the neighbor relationship intact, but not good enough to allow the replies through. To sum it up, routes generally become SIA when a neighbor either doesn't answer a query, or either the query or reply took a wrong turn somewhere. Glad I could narrow that down for you. : ) In real-world networking, resolving SIA routes is much more of an art form than a science. A little Googling will show you just what I mean. In my experience, the most common real-world causes of SIA are problems with the neighboring router - either that it's just too busy to answer and it has no CPU to spare, or that it doesn't have the memory to handle the query in the first place. What SIA Routes Look Like If you have eigrp log-neighbor-changes running, the message you get to indicate a route is SIA looks like this:
Route 100.1.4.0/24 stuck-in-active state in IP-EIGRP-100

With the same log command running, a neighbor that does not respond to a query will result in this log entry:
neighbor 90.1.1.1 (Serial0) is down: stuck in active

Another method of spotting SIA issues is in the EIGRP topology table. If you see a lower-case "r" next to an IP address where the Active route is shown, that means a query packet has been sent to that IP address and it has not yet been answered. This code is shown at the top of the EIGRP topology table.
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

The Variance Command And Unequal-Cost Load Sharing Often, we'll have two or more quality paths that we want EIGRP to use. If the metrics aren't exactly the same, by default EIGRP will use only the successor, as shown here:
R1#show ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(11.1.1.1) P 3.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0

via 172.12.123.2 (2323456/409600), Serial0 R1#show ip route eigrp 100 D 3.0.0.0/8 [90/2297856] via 172.12.123.3, 01:16:16, Serial0

We have two options for using that second path, which has been marked as a feasible successor by EIGRP. One is practical, and the other, well, isn't. We could try to change the metric to exactly 2297856, but this is almost impossible. Take a look at the formula EIGRP uses to calculate routes: EIGRP metric calculation: [(10*6 / smallest BW in kbps) + delay] * 256 This would be the impractical method. The best way to handle this situation is to use unequal-cost load balancing via the variance command. Using the variance command is easy; it's coming up with the value of this command that causes a little confusion. With practice, you'll find this to be easy points on the ROUTE exam. We just need the answer to this question: 'What is the smallest number, when multiplied by the metric of the successor, that is greater than the metric of the feasible successor?" To put it a little more formally....what is "x" in the following? (x * [successor metric]) > feasible successor metric I know some of you are looking at that last paragraph and that formula and thinking, "This is the practical method?" It really is, and you'll see that in just a moment. This is one of those concepts that looks ridiculously complicated in theory but is simple in execution. Let's use the same table we looked at earlier for an example. Question: What is the smallest number, multiplied by 2297856, that is greater than 2323456? Answer: Two. Easy! By using the variance 2 command, any route with a metric less than (2 * 2297856) will be placed into the routing table. This doesn't make the route with the higher metric a successor, but the route is placed into the routing table and will be used for unequal-cost

load-balancing.
R1#conf t R1(config)#router eigrp 100 R1(config-router)#variance 2 R1#show ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(11.1.1.1) P 3.0.0.0/8, 1 successors, FD is 2297856 (There is still just one successor....) via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 R1#show ip route eigrp 100 3.0.0.0/8 [90/2297856] via 172.12.123.3, 00:01:52, Serial0 [90/2323456] via 172.12.123.2, 00:01:53, Serial0 (... but now there are two routes in use to reach this network.) D

When unequal-cost load balancing is in effect, the load each link carries is proportional to their metric. If one path's metric indicates that it is twice as good as another, that path will carry roughly twice as much data. If you want only the best path(s) to carry the traffic, use the trafficshare command with the min option. The default is balanced.
R1(config)#router eigrp 100 R1(config-router)#traffic-share ? balanced Share inversely proportional to metric min All traffic shared among min metric paths R1(config-router)#traffic-share min ? across-interfaces Use different interfaces for equal-cost paths R1(config-router)#traffic-share min across-interfaces ? <cr> R1(config-router)#traffic-share min across-interfaces

Now I know what some of you are thinking.... "Why don't I just put variance 25 in there or something like that, and then I'll be using all of my available paths!" Good question. Here's a good answer. Let's say we have three valid paths to the same network with the following metrics: Path 1: Path 2: Path 3: 5000 7000 55000

Sounds like we have two pretty fast links and one sloooow one. Do you really want to load balance over that third path? Probably not. It's

better than having no third link at all, but I wouldn't include it in load balancing. variance is an "all-or-nothing" command -- you can't apply it to just a selected route in the topology table. In my experience, it's a good idea to keep the variance command at the lowest value possible to avoid load balancing over paths that may be loop free but aren't exactly optimal. And note the values available with variance...
R1(config-router)#variance ? <1-128> Metric variance multiplier

... setting variance to 1 is effectively disabling unequal-cost load balancing while retaining equal-cost load balancing. You can't set it to zero. Planning Your Load Balancing Enabling both equal-cost and unequal-cost load balancing is simple enough in EIGRP - the former is on by default, the latter is enabled with one simple command - but you've got to do some planning and verification, too. I strongly recommend you create a network baseline before use the variance command. Besides, if you don't know how much traffic your network is carrying, it's hard to determine if your load balancing is working as desired! After you run the variance command, we need to make sure of two things... The load balancing is going as expected and desired Only the paths you wanted to use are being used When it comes to our old friends ping and traceroute, we tend to ping first and trace second... but when you're testing your load balancing, you can leave the pings alone. Pings will show you that you do have connectivity to a given destination, but they don't show you how we got there. Traceroutes do. (And just in case - remember the ping and traceroute escape sequence, <CTRL- Shift - 6> twice in rapid succession.) Once you've compared the new config's baseline to the old, and you're happy with the result - document your changes. I know it's no fun. I know you'd rather be doing something else. Do it anyway. : ) And one more thing - when testing and creating baselines for your EIGRP load balancing configuration, remember that load balancing is only put

into action for traffic that both enters and leaves that router - traffic actually generated by the local router is no subject to load balancing.

DUAL Queries Let's review the purpose of these packets... It is possible for an EIGRP-speaking router to have only a single path to a given network, which means we have one successor and zero feasible successors. If that successor route is lost, that router will send DUAL Queries to all its neighbors. A DUAL Query is basically one neighbor asking another, "Hey, do you know how to get to this network I just lost my route to?" There's no grey area here - either the downstream router has such a route, or it doesn't. Here are the potential actions the downstream router can take: If that neighbor has a route, the query will be answered with that route. Simple enough! If the neighbor doesn't have such a route, that neighbor will ask its neighbors. The process continues until a downstream router replies with the desired route, or the EIGRP downstream routers run out of neighbors to ask. Just as it's wise to limit the scope of broadcasts in our network, it's a great idea to limit the scope of these Query packets as well. We have two main weapons at our disposal for limiting the scope of Query packets: Manual route summarization EIGRP stub routing We'll look at both later in this section. Feasible Distance and Advertised Distance From all these views of the topology table, you've probably noticed that there are two numbers in parenthesis following each next-hop IP address.
P 172.23.0.0/16, 2 successors, FD is 2195456 via 172.12.123.2 (2195456/281600), Serial0 via 172.12.123.3 (2195456/281600), Serial0

The first number, 2195456, is the route's feasible distance. This is the full metric of the route to the destination network. The second number, 281600, is the route's advertised distance. This

is simply the metric from the next-hop router to the destination network. For the path to be considered valid, the advertised distance must be less than the feasible distance. This ensures that the next-hop router is indeed closer to the destination and acts as a routing loop prevention mechanism. These distances are also used by EIGRP to determine what routes can be feasible successors. Let's look at our two routes to 3.0.0.0 /8 again.
P 3.0.0.0/8, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0

The second route can't be a successor, because its FD (2323456) is higher than the FD of the successor (2297856). Can it be a feasible successor? Yes, because the advertised distance of that route (409600) is lower than the feasible distance of the successor (2297856). This is the Feasibility Condition. That route is then entered into the topology table as a feasible successor, and should the successor go down, the feasible successor will become the successor. Let's use some slightly smaller numbers to walk through an example without using show ip eigrp topology. We'll assume a successor route and three possible feasible successors. Successor: FD 5, AD 4 Possible Feasible Successor #1: FD 9, AD 7 Possible Feasible Successor #2: FD 8, AD 6 Possible Feasible Successor #3: FD 6, AD 4 To decide if any of these three routes could be a feasible successor, just compare the AD of the route to the FD of the successor. Routes #1 and #2 could not be feasible successors, because their ADs are larger than the FD of the successor. Route #3's AD of 4 is less than the successor's FD of 5. As a result, Route #3 will be placed into the EIGRP topology table and marked as a feasible successor. If the successor route goes down, Route #3 will then be named the successor. If the successor is lost and there is no feasible successor, the router takes two actions: The route is put into Active state, making the route unusable.

The router sends DUAL Query packets to EIGRP neighbors, asking them if they have a loop-free path to the destination in question. Either the neighbors will answer this query with an alternate path (with a reply packet), or those neighbors will ask their neighbors if they have a path to the network. This query process continues until a router returns a path to that network, or no router can do so and the query process finally ends. We discussed SIA routes earlier, and another reason that routes become Stuck In Active is the length of this query process. The query process can be limited with proper route summarization. (It bears repeating that the most common reason a route becomes SIA is the failure of a router to answer the query, whether that be a problem with the router or the link itself.) Let's take another look at feasible distance, advertised distance, and the feasibility condition in action. You really have to watch these values, or what you think should happen with your network when a successor goes down might not actually be what will happen. The Feasibility Condition In Action

R1 has three potential paths to R3. The feasible distances and advertised distances for the paths from R1's point of view are: R1 - R4 - R3: FD 40, AD 20 R1 - R2 - R3: FD 70, AD 20 R1 - R5 - R3: FD 115, AD 75

R1 will place the path through R4 into its routing table; since that route has the lowest FD, it is the successor. The successor is also placed into the topology table. R1 will consider the other two routes as potential feasible successors. The Feasibility Condition states that if a potential feasible successor's AD is less than the successor's FD, the route is an FS. The AD of the path through R2 is 20; the FD of the successor is 40. The path through R2 is a feasible successor and will be placed into the EIGRP topology table. What about the third path? The AD of the path through R5 is 75, while the FD of the successor is 40. This indicates to EIGRP that the potential for a routing loop exists, so this route will not be made a feasible successor. If the path through R4 went down, the router would immediately begin using the path through R2, which has already been tagged as a feasible successor. The path through R2 would then be named the successor route, but the path through R5 still would not be a feasible successor, as the path through R5 has an AD of 75 and the path through R2 has a FD of 70.

The Feasibility Condition And The variance Command The Feasibility Condition also impacts the use of the variance command. The value expressed with the variance command is essentially a multiplier that enables unequal-cost load balancing, but there's more to it than that. You already know how to use the variance command, but it's important to keep in mind that if a route doesn't meet the Feasibility Condition, it can't possibly be used in unequal-cost load balancing. Consider the network metrics from the last example: R1 - R4 - R3: FD 40, AD 20 R1 - R2 - R3: FD 70, AD 20 R1 - R5 - R3: FD 115, AD 75 It's very tempting to look at these metrics and think that we could use variance to use all three paths for unequal-cost load balancing. The problem is that you can't use a path that doesn't meet the Feasibility Condition. In the exam room and in the real world, make sure any routes you want to use in unequal-cost load balancing meet the Feasiblity Condition, because if they don't, you cannot use them no matter what the value of the variance command is.

You should always write out the FD and AD of all routes in a network diagram before deciding whether the variance command will allow you to use all the paths. Let's look at another example. How would you go about configuring unequal-cost load balancing in the following network?

The quick and obvious answer would be to just add up the metrics for each path, then figure out what variance value to use. The metric for the best path is 40; the metric for the lesser path is 115; therefore, we just run the command variance 3 (40 x 3 = 120, which will allow all valid routes with a metric of less than 120 to be put into the routing table), and we're all set, right? Wrong. The problem is not with our math, but with the Feasiblity Condition. Let's look at the FD and AD for each path, using the values shown. R1-R2-R3: FD 40, AD 20 R1-R4-R5: FD 55, AD 35 R1-R6-R7: FD 115, AD 75 The successor will be R1-R2-R3; that route will be in both the route and topology tables. R1-R4-R5 meets the Feasiblity Condition, since its AD of 35 is less than the FD of the successor, which is 40. That route is eligible for unequal-cost load balancing and will be placed in the topology table. There's a problem with R1-R6-R7, though. The AD of that path is 75, which is larger than the FD of the current successor; even if R1-R4-R5 became the successor, R1-R6-R7 still couldn't meet the Feasiblity Condition. Therefore, the best solution is to run the command variance 2 to perform load sharing over the single feasible successor. No matter the variance value, the third path cannot participate in unequal-cost load balancing.

EIGRP Administrative Distances The EIGRP routes you saw in the routing table earlier in this chapter were the EIGRP route type you learned about in your CCNA studies. These are EIGRP internal routes, and they have an administrative distance of 90. There are two other EIGRP route types, and they have different administrative distances. Routes learned by EIGRP via route redistribution are external EIGRP routes and have an AD of 170. These routes are preceded in the routing table with the letters "D EX". Keep in mind that redistributed routes don't have to come from other routing protocols -- they can be connected or static routes as well. I've run into situations that had people scratching their heads over an AD value, so let's take a look at one such configuration.

Both routers are in AS 100, and are connected via the common Ethernet segment shown. One day, someone decides to advertise the loopback interface on R2 (2.2.2.2 /32) to the rest of the EIGRP domain. There are two options, with the most common being the network command.
R2(config)#router eigrp 100 R2(config-router)#network 2.2.2.2 0.0.0.0 R3#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/409600] via 172.23.23.2, 00:00:06, Ethernet0

That's what we would expect to see, and that's how R3 would then advertise this network to downstream routers - as an internal route. What if redistribution were used on R2 instead of the network command? Let's remove the network command on R2 and use redistribute connected instead.
R2(config)#router eigrp 100 R2(config-router)#no network 2.2.2.2 0.0.0.0 R2(config-router)#redistribute connected R3#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D EX 2.2.2.2 [170/409600] via 172.23.23.2, 00:00:05, Ethernet0

The difference is significant! R3 now sees the same network as an

external network, which means its AD is 170 instead of 90. R3 would then advertise this network to downstream EIGRP routers as an external route. Even though there is no other AS or no other routing protocol involved, routes can still show up as external routes if route redistribution is used. To change the AD of external or internal EIGRP routes on a single router, use the distance eigrp command. Even if you're only changing the distance of one route type, you still have to specify them both.
R1(config)#router eigrp 100 R1(config-router)#distance ? <1-255> Administrative distance eigrp IP-EIGRP distance R1(config-router)#distance eigrp ? <1-255> Distance for internal routes R1(config-router)#distance eigrp 45 ? <1-255> Distance for external routes R1(config-router)#distance eigrp 45 100

The third type of EIGRP route is an EIGRP summary route. The result of manual route summarization, these routes have an AD of 5 when viewed on the router actually performing the summarization. If you know where to look, that is. EIGRP Route Summarization - Automatic And Manual EIGRP has a default behavior involving route summarization that is almost always turned off at the very beginning of an EIGRP deployment, and that is autosummarization. EIGRP and RIPv2 automatically summarize routes when they are advertised across classful network boundaries. When you have discontiguous networks (subnets of the same major network number that are separated by another major network number), this behavior can result in suboptimal routing at its worst. Consider this network where subnets of the major network number 20.0.0.0 are separated by another major network number, 172.16.0.0.

If EIGRP's default autosummarization is left on, the hub router is going to get two advertisements for the major network number 20.0.0.0 /8. Combined with another EIGRP default behavior, equal-cost load sharing, there is an excellent chance that half of the packets destined for any of the subnets of 20.0.0.0 are going to end up at the wrong spoke router. It's easy enough to turn this behavior off:
R1(config)#router eigrp 100 R1(config-router)#no auto-summary

Many real-world EIGRP deployments have no auto-summary configured on every router in the network. This doesn't really hurt anything, but now that you're training to be a CCNP, you need to know where the command is needed - and where it's unnecessary. Disabling autosummarization on the spoke routers in this network will give the hub router a much more accurate picture of the network. Remember, it's not enough to know the command - you need to know where to configure the command. The no auto-summary command would have no effect on incoming updates if configured on the hub. In this network, the command needs to be placed on each spoke.

Configuring any kind of manual summarization does NOT enable or disable auto-summarization -- they're two separate operations. Route summarization isn't always a bad thing -- configured at the right points in your network, it can be a great thing. Here are just a few reasons why... The routing tables are smaller, making the entire routing process faster. Since the tables are smaller, the load on the CPU from the routing process is lessened. The more-specific network numbers are hidden. Routing updates are smaller. The impact of flapping routes on the rest of the network is lessened, and correct summarization helps to limit the number of EIGRP queries. The key to success with real-world route summarization is that you, the network administrator, should decide where summarization should take place -- not the router. In this example, R1 has seven subnets of the major network number 100.0.0.0 that it's advertising to R3:

R3's EIGRP table shows all seven routes:

R3#show ip route eigrp 100.0.0.0/16 is subnetted, 7 subnets D 100.4.0.0 [90/2297856] via 172.12.123.1, D 100.5.0.0 [90/2297856] via 172.12.123.1, D 100.6.0.0 [90/2297856] via 172.12.123.1, D 100.7.0.0 [90/2297856] via 172.12.123.1, D 100.1.0.0 [90/2297856] via 172.12.123.1, D 100.2.0.0 [90/2297856] via 172.12.123.1, D 100.3.0.0 [90/2297856] via 172.12.123.1,

00:00:00, 00:00:00, 00:00:00, 00:00:00, 00:00:00, 00:00:00, 00:00:00,

Serial0 Serial0 Serial0 Serial0 Serial0 Serial0 Serial0

With the help of manual route summarization, we can knock this table down to one line. First, we use our old friend binary math to convert the subnet numbers to binary strings. 100.1.0.0 100.2.0.0 100.3.0.0 100.4.0.0 100.5.0.0 100.6.0.0 100.7.0.0 01100100 01100100 01100100 01100100 01100100 01100100 01100100 00000001 00000010 00000011 00000100 00000101 00000110 00000111 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Believe it or not, that's the hard part of summarizing routes. The next step in route summarization is to work from left to right and identify the common bits. From there, it's easy: The decimal value of these bits is the summary route. The number of common bits yields the summary mask. Here, the value of the common bits (bolded above) is 100.0.0.0. There are 13 common bits, expressed as /13 in prefix notation and 255.248.0.0 in dotted decimal. Now that we have the summary route and mask, this route and mask will be configured on the ethernet interface.... the physical interface that will be advertising the summary.

R1(config)#interface ethernet0 R1(config-if)#ip summary-address eigrp 100 100.0.0.0 255.248.0.0 2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.3 (Serial0) is down: summary configured 2d11h: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.2 (Serial0) is down: summary configured

It's important to keep in mind that when you configure EIGRP summary addresses, your neighbor relationships will be lost. When they come back up, R3 will have a single summary route instead of the seven morespecific routes it previously had.
R3#show ip route eigrp 100 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:03:33, Ethernet0

We saw the impact on R3 after route summarization, but there's something of interest on R1 you should note.
R1#show ip route < code table removed for clarity > 100.0.0.0/8 is variably subnetted, 8 subnets, 2 masks 100.4.0.0/16 is directly connected, Loopback4 100.5.0.0/16 is directly connected, Loopback5 100.6.0.0/16 is directly connected, Loopback6 100.7.0.0/16 is directly connected, Loopback7 100.0.0.0/13 is a summary, 00:07:32, Null0 100.1.0.0/16 is directly connected, Loopback0 100.2.0.0/16 is directly connected, Loopback2 100.3.0.0/16 is directly connected, Loopback3

C C C C D C C C

On R1, the summary route is seen as a route to Null0, which is basically a route to the trash can. If a packet comes into this router that doesn't match one of the seven more-specific routes, it will be "black-holed" dropped by the router. This default behavior of EIGRP route summarization helps to prevent routing loops. This null route will only be seen on the router performing the manual summarization. The Mystery Of The AD5 One of the jumps from CCNA to CCNP in your EIGRP studies involves these three administrative distances: Internal: 90 External: 170 Summary: 5 We've seen that AD of 90 for internal EIGRP routes since the beginning of our studies; the AD of 170 has been seen in this section as well as the Redistribution section of the course. So what about that AD of 5 for EIGRP summary routes?

When we looked at the summary route on the downstream router R3, we saw...
R3#show ip route eigrp 100 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:03:33, Ethernet0

.. an AD of 90. Actually, that's the value we should expect, since the summary route will have an AD of 5 only on the router that originates the summary. Great! Let's take another look at R1's routing table and that line for the summary route, and I'm sure we'll see...
D 100.0.0.0/13 is a summary, 02:11:48, Null0

... no AD at all.

So where is it?

After some information mining (a fancy way to say "I looked it up again"), I found that you need to run the show ip route command followed by the network number.
R1#show ip route 100.0.0.0 Routing entry for 100.0.0.0/8, 8 known subnets Attached (7 connections) Variably subnetted with 2 masks C 100.4.0.0/16 is directly connected, Loopback3 C 100.5.0.0/16 is directly connected, Loopback4 C 100.6.0.0/16 is directly connected, Loopback5 C 100.7.0.0/16 is directly connected, Loopback6 D 100.0.0.0/13 is a summary, 00:19:54, Null0 C 100.1.0.0/16 is directly connected, Loopback0 C 100.2.0.0/16 is directly connected, Loopback1 C 100.3.0.0/16 is directly connected, Loopback2

Hmm. I still don't see an AD. Do you? When all else fails, ask for directions from Mr. IOS Help:
R1#show ip route 100.0.0.0 ? A.B.C.D Network mask longer-prefixes Show route matching the specified Network/Mask pair only | Output modifiers <cr>

Let's try it with the mask:

R1#show ip route 100.0.0.0 255.248.0.0 Routing entry for 100.0.0.0/13 Known via "eigrp 100", distance 5, metric 128256, type internal Redistributing via eigrp 100 Routing Descriptor Blocks: * directly connected, via Null0 Route metric is 128256, traffic share count is 1

Total delay is 5000 microseconds, minimum bandwidth is 10000000 Kbit Reliability 255/255, minimum MTU 1514 bytes Loading 1/255, Hops 0

Ta da!

Where Should Manual Route Summarization Be Performed? Part of configuring anything Cisco, from manual route summarization to access lists, is figuring out the best point in your network to actually perform the operation. As you well know by this point in your Cisco studies, there's rarely a "one-size-fits-all" solution to this question! When it comes to EIGRP route summarization, I've found the most efficient point to perform this operation is at the ASBR. We generally associate the term ASBR with OSPF, but an EIGRP router that performs route redistribution is also considered an ASBR. Just as with OSPF, route summarization is more efficient when it's configured on the ASBR. EIGRP Design Recommendations With networks growing and changing all the time, it's impossible for anyone to give you a hard-and-fast set of design rules that will fit any network. Having said that, there are some solid general guidelines when it comes to EIGRP. Make sure you spend some time and set up a solid address allocation scheme before you deploy your network. This pointer is the EIGRP equivalent of "measure twice, cut once". Ensure that you'll be able to perform manual route summarization where desired. Avoid discontiguous networks whenever possible. Make sure your routers have sufficient memory and CPU to do their jobs. Your hub routers in any hub-and-spoke deployments will be the workhorses of your network. Cisco has a few recommendations when it comes to EIGRP bandwidth allocations over the NBMA cloud. Your EIGRP traffic on each Virtual Circuit (VC) shouldn't exceed the Committed Information Rate (CIR). (The CIR is the amount of bandwidth the service provider guarantees to be available to us.) The total EIGRP traffic crossing all of your VCs should not be greater than the total capacity of the line.

The bandwidth allocated to EIGRP on each VC should be the same on each interface. There are also some details to attend to when it comes to allocating bandwidth over an NBMA network. The typical Serial interface is going to have multiple Virtual Circuits, so you have to know how EIGRP will run in that situation. The calculation for the bandwidth command varies according to two factors: the type of interface in use on the hub the CIR assigned to each circuit Just looking at these guidelines give you an idea of some good questions to ask before you start configuring: What IS the current CIR? What are the current bandwidth value of the client's interfaces? Does the client have any special requests or policies that need to be taken into consideration - bandwidth maximums / minimums, stub routers, non-transient routers, etc.? Let's take a look at several different scenarios, beginning with a physical interface on the hub and three circuits all assigned the same CIR. No Subinterfaces, All VCs Using Same CIR

When there are no subinterfaces in use and the CIR is the same for every VC, just add up the CIRs and you've got your bandwidth value. Doing this ensures that none of the circuits are overloaded, which could happen if we leave the bandwidth setting at the default.
R1(config)#int serial0 R1(config-if)#bandwidth 768

No Subinterfaces, VCs Using Different CIRs

Cisco has stated you can take the lowest CIR value and multiply it by the number of VCs. This isn't the recommended solution, but it is valid. Using this solution, the bandwidth setting on R5's Serial0 interface would be (3 x 56), or 168.
R1(config)#int s0 R1(config-if)#bandwidth 168

This would prevent R7 from being overrun with packets, but it doesn't allow R6 or R4 to work to capacity. A more viable solution involves configuring point-to-point interfaces and assigning individual bandwidth values, having those match the individual CIR of each VC. This is Cisco's recommendation for this situation, and this allows each router to work more closely to capacity! Point-to-Point Subinterfaces, VCs Using Different CIRs

R1(config)#int serial0.1 point-to-point R1(config-subif)#ip address 20.1.1.1 255.255.255.0 R1(config-subif)#bandwidth 512

R1(config-subif)#int s0.2 point-to-point R1(config-subif)#ip address 40.1.1.1 255.255.255.0 R1(config-subif)#bandwidth 256 R1(config-subif)#int s0.3 point-to-point R1(config-subif)#ip address 50.1.1.1 255.255.255.0 R1(config-subif)#bandwidth 56

Multipoint Subinterfaces, VCs Using Different CIRs

Of course, you may have a multipoint subinterface on the hub router! In that case, simply add the CIR values for each circuit using that multipoint subinterface to arrive at the correct bandwidth setting. In the following example, there are three circuits using the same multipoint interface. The CIRs are 512, 256, and 56 kbps; the bandwidth setting on R5's multipoint interface should be set to 824 kbps.
R1(config)#interface s0.467 multipoint R1(config-subif)#bandwidth 824

By default, EIGRP uses up to 50 percent of a given interface's bandwidth as set by the bandwidth command. If you wish to change this default, it can be done with the interface-level command ip bandwidth-percent eigrp.
R1(config)#int s0 R1(config-if)#ip bandwidth-percent eigrp ? <1-65535> Autonomous system number R1(config-if)#ip bandwidth-percent eigrp 100 ? <1-999999> Maximum bandwidth percentage that EIGRP may use R1(config-if)#ip bandwidth-percent eigrp 100 300

In this command, the values look really strange. According to IOS Help, we can set the interface bandwidth usage to more than 100 percent!

I set it to 300% here and didn't get an error message of any kind. How in the world can I set EIGRP 100 to use 300% of an interface's available bandwidth? There is always the chance that the actual physical speed of the interface exceeds the logical setting. You could take an interface with a 512 kbps capacity and give it a logical setting of 56 kbps. If you then wanted the line to allow EIGRP to use 168 kbps of the physical bandwidth, you'd set the bandwidth-percent value to 300, which allocates 300% of 56kbps to EIGRP traffic - which is 3 x 56, or 168. I know it sounds crazy, so here's the proof that you can actually do this:
R3(config)#interface serial0 R3(config-if)#bandwidth 56 R3(config-if)#ip bandwidth-percent eigrp ? <1-65535> Autonomous system number R3(config-if)#ip bandwidth-percent eigrp 100 ? <1-999999> Maximum bandwidth percentage that EIGRP may use R3(config-if)#ip bandwidth-percent eigrp 100 300

Watch that syntax - the first number is the EIGRP AS; the second number is the bandwidth percentage. EIGRP Stub Routers Here's a great method of limiting the size of some routing tables in your EIGRP deployment and the scope of DUAL Query packets. While EIGRP does not have the stub area options that OSPF does, EIGRP does allow a router to be configured as stub. This is commonly done with a hub-and-spoke configuration where the spoke routers do not have the resources or the need to keep a full routing table. Since the spoke's next hop will always be the hub, all the spoke really needs is a default route. For this reason, the only neighbor an EIGRP stub router can have is the hub router -- two EIGRP stub routers cannot become neighbors. Configuring EIGRP stub routers also combats the SIA problem. EIGRP stub routers are not queried for routes when the hub does not have a feasible successor for a successor route that has gone down. This limits the scope of EIGRP Query packets and is a popular reason for configuring EIGRP stub routing. By default, EIGRP stub routers advertise information about two types of routes back to the hub - directly connected networks and summary routes. Configuring an EIGRP router as stub is very simple:

R1(config)#router eigrp 100 R1(config-router)#eigrp stub

To change this default, use the eigrp stub command followed by the types of routes you want the stub to advertise back to the hub.
R1(config)#router eigrp 100 R1(config-router)#eigrp stub connected Do advertise receive-only Set IP-EIGRP static Do advertise summary Do advertise <cr> ? connected routes as receive only neighbor static routes summary routes

The network we looked at earlier in this section has several excellent candidates for EIGRP stub routers. As long as R4, R6, and R7 are each only neighbors with the hub, R5, they can be configured as stub routers. Those stub routers will then advertise their directly connected networks and summary routes back to the hub and will receive only a default route back from the hub. If R5 loses a successor and has no feasible successor, it will not send a query packet to any of the stub routers. Basically, what we're doing is preventing R5 from asking a question of those other routers that they can't possibly have an answer to in the first place. An EIGRP stub deployment can have more than one hub, as the following illustration shows. The important thing is that the spoke routers are not interconnected. The hub routers R5 and R8 are interconnected, but not the spokes R4, R6, and R7.

Just A Reminder... I know you remember this from your CCNA studies, but I'm going to tell you anyway - EIGRP assumes that a serial interface is connected to a T1 line, which runs at 1544 kbps (or 1.544 mbps). If this isn't the case in your network, the bandwidth command can be used to give EIGRP a more accurate reflection of the line speed. For example, if you have a serial interface connected to a 56 kbps line, it's a good idea to tell EIGRP to reflect that in its routing calculations with the bandwidth command.
R1(config)#int s0 R1(config-if)#bandwidth 56

Always use IOS Help to verify the unit of measurement for any value. There's a big difference between entering bandwidth 56 and bandwidth 56000 on that line! And Just Another Reminder... There's some confusion out there as to whether the use of wildcard masks with EIGRP is required. I personally recommend you use wildcard masks every time you can, but it's not required.
R1(config)#router eigrp 100 R1(config-router)#network 10.0.0.0 ? A.B.C.D EIGRP wild card bits <cr> R1(config-router)#network 10.0.0.0

This IOS Help readout shows that you can configure wildcard bits with this network command, and the <cr> indicates that it's a legal command just the way it is. Pre-12.0 IOS versions don't support EIGRP wildcard

masks, so you should also be prepared for that possibility. I've seen one or two routers running at least 12.0 that didn't seem to like wildcard masks either - that seems to have been an anomaly - the important point here is that their use is not required, but is recommended. What's So Passive About A Passive Interface? On occasion - say, maybe your CCIE lab date :) - you may want to advertise a network via EIGRP, but not want to send EIGRP-related traffic out the interface you're advertising. For example, let's say you want to advertise our Ethernet segment of 172.23.23.0 /24 to R1, but you don't want any EIGRP traffic, Hellos or otherwise, to be sent out the interfaces on that segment. Configuring the Ethernet0 interfaces on R2 and R3 as passive will make that happen. When you configured an EIGRP-enabled interface as passive, that interface will not transmit Hello packets. Since the absence of Hello packets means no adjacencies, no other EIGRP packets will go out those interfaces. There are two approaches to configuring passive interfaces: Option 1: Use the passive-interface default command to make every EIGRP-enabled interface on the router passive, and then use the no passive-interface command to indicate the interfaces that should not be passive. The following configuration will first enable EIGRP passive interface as the default, and the next command disables that same feature on Serial0 .
R1(config)#router eigrp 100 R1(config-router)#passive-interface ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Loopback Loopback interface Null Null interface Serial Serial default Suppress routing updates on all interfaces <cr> R1(config-router)#passive-interface default R1(config-router)#no passive-interface ? BRI ISDN Basic Rate Interface Ethernet IEEE 802.3 Loopback Loopback interface Null Null interface Serial Serial default Suppress routing updates on all interfaces <cr> R1(config-router)#no passive-interface serial0

Option 2: Use the no passive-interface default command to disable this feature globally, and then use the passive-interface command to indicate interfaces that should be passive. Naturally, as a result of making Serial0 passive, any existing adjacencies formed through that interface are lost - and the DUAL message tells you why.
R2(config)#router eigrp 100 R2(config-router)#no passive-interface default R2(config-router)#passive-interface serial 0 R2(config-router)# 00:48:36: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.1 (Serial0) is down: interface passive

When you realize you made the wrong interface passive, just use the no passive-interface command to make things right and the adjacency should quickly reappear.
R2(config-router)#no passive-interface serial 0 R2(config-router)# 00:50:08: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.1 (Serial0) is up: new adjacency

Note that all commands discussed above are run in the EIGRP configuration, not at the interface level. Propagating A Default Route Via EIGRP First, the bad news: We don't have OSPF's default information-originate option in EIGRP ("always" or otherwise). The good news: We can redistribute a static default route into EIGRP, or we can indicate a default network with the ip default-network command. To go with the static default option, just create a static default route with the ip route command and follow that with the redistribute command.
R1(config)#ip route 0.0.0.0 0.0.0.0 ethernet0 R1(config)#router eigrp 100 R1(config-router)#redistribute static ? metric Metric for redistributed routes route-map Route map reference <cr> R1(config-router)#redistribute static metric ? <1-4294967295> Bandwidth metric in Kbits per second R1(config-router)#redistribute static metric 1544 ? <0-4294967295> IGRP delay metric, in 10 microsecond units R1(config-router)#redistribute static metric 1544 10 ? <0-255> IGRP reliability metric where 255 is 100% reliable R1(config-router)#redistribute static metric 1544 10 255 ? <1-255> IGRP Effective bandwidth metric (Loading) where 255 is 100% loaded R1(config-router)#redistribute static metric 1544 10 255 1 ? <1-4294967295> IGRP MTU of the path R1(config-router)#redistribute static metric 1544 10 255 1 1500

Downstream routers will see this route as follows:

R2#show ip route eigrp 100.0.0.0/13 is subnetted, 1 subnets D*EX 0.0.0.0/0 [170/2172416] via 172.12.123.1, 00:01:15, Serial0

You can use the network 0.0.0.0 command in the EIGRP config in lieu of the redistribute command. R2 will still see the default route, but it will have an AD of 90 rather than 170 since redistribution is not involved.
R1(config)#router eigrp 100 R1(config-router)#network 0.0.0.0 ? A.B.C.D EIGRP wild card bits <cr> R2#show ip route eigrp 100.0.0.0/13 is subnetted, 1 subnets D* 0.0.0.0/0 [90/2195456] via 172.12.123.1, 00:00:05, Serial0

Just one more option for redistribution (for now). Remember the route to null0 that was placed in our routing table as a result of route summarization? That route can also be redistributed, but it can lead to some routing issues depending on your network topology. I'm personally not big on redistributing a route to null0, but it's an important option to keep in mind. Using The IP Default-Network Command You can advertise a non-zero network number as the default route with the ip default-network command, but there's just one thing to watch out for .... The router that originates this advertisement MUST have that network number in their IP routing table. The reason I'm making such a big deal of that is with OSPF, we had the option of advertising a default route even when the router didn't have such a default route in its routing table ("default information-originate always"). We have no such option with EIGRP. After removing the above default static route and the redistribute command, I'll configure 20.0.0.0 as the default network for EIGRP...
R1(config)#router eigrp 100 R1(config-router)#ip default-network ? % Unrecognized command

... or will I? Don't try to use the ip default-network command in the EIGRP config itself - it's a globally configured command.

R1(config)#ip default-network 20.0.0.0

But on R2, no such network appears and there is no gateway of last resort.
R2#show ip rout Gateway of last resort is not set 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:02:30, Serial0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0

Let's go back to R1, remove the 20.0.0.0 network, and add the 10.0.0.0 network that does have an entry in the routing table:
R1(config)#no ip default-network 20.0.0.0 R1(config)#ip default-network 10.0.0.0

The route is flagged as a candidate default in R1's routing table..

C* 10.0.0.0/8 is directly connected, Ethernet0

... and is advertised via EIGRP to downstream routers.

R2#show ip route eigrp 100.0.0.0/13 is subnetted, 1 subnets D 100.0.0.0 [90/2297856] via 172.12.123.1, 00:02:46, Serial0 D* 10.0.0.0/8 [90/2195456] via 172.12.123.1, 00:01:37, Serial0

Authenticating Our EIGRP Neighbors In today's world, it's not always a good idea to assume that any neighbors dynamically discovered by EIGRP are actually desirable neighbors. They could be rogue routers that will have the ability to inject a malicious routing update into our network - and the resulting IP routing table could end up sending all of our network's data to a rogue router. EIGRP neighbor authentication isn't the most intuitive feature you'll ever configure, and there are quite a few command options. Before you even get that far, though, you have to decide whether you're going to use clear-text passwords or use MD5 authentication to encrypt those passwords.... ... and while I'll show you how to do both, in the real world that shouldn't be much of a decision. If you're going to the trouble to configure EIGRP neighbor authentication in the first place, go all the way and use MD5 authentication. Note that MD5 only encrypts the password used for our neighbor authentication - it does not protect the payload of the packets.

Since you're much more likely to work with MD5 EIGRP authentication, let's configure that right now! First, define the password and any other options such as start-time and end-time with the key chain command. Before setting any options, though, configure the actual password with the key-string command.
R3(config)#key chain ? WORD Key-chain name R3(config)#key chain EIGRPNEIGHBOR ? <cr> R3(config)#key chain EIGRPNEIGHBOR R3(config-keychain)#key ? <0-2147483647> Key identifier R3(config-keychain)#key 1 R3(config-keychain-key)#key-string ? <0-7> Encryption type (0 to disable encryption, 7 for proprietary) LINE The key R3(config-keychain-key)#key-string KINISKI

You can define how long a particular password should be sent and accepted with the send-lifetime and accept-lifetime commands. For your intro to this command, we'll use the infinite option for the expiration date - which means that it never expires!
R3(config-keychain-key)#? Key-chain key configuration commands: accept-lifetime Set accept lifetime of key default Set a command to its defaults exit Exit from key-chain key configuration mode key-string Set key string no Negate a command or set its defaults send-lifetime Set send lifetime of key R3(config-keychain-key)#accept-lifetime ? hh:mm:ss Time to start local Specify time in local timezone R3(config-keychain-key)#accept-lifetime 10:00:00 ? <1-31> Day of the month to start MONTH Month of the year to start R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 ? <1993-2035> Year to start R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 2010 ? duration Set key lifetime duration hh:mm:ss Time to stop infinite Never expires R3(config-keychain-key)#accept-lifetime 10:00:00 Jan 1 2010 infinite R3(config-keychain-key)#send-lifetime 10:00:00 Jan 1 2010 infinite

You might expect that we would have lost our EIGRP adjacencies from R3, but that's not the case yet - we've just created the key, but we haven't applied the key to the interface(s). In essence, we've forged the key but haven't locked the door. That's about to change. Let's apply this authentication to the Ethernet segment over which R2 and R3 are exchanging EIGRP traffic.

This actually requires two commands on each interface. On R3, we'll begin by configuring the MD5 authentication mode on that Ethernet interface, taking a look at the options along the way:
R3(config)#int e0 R3(config-if)#ip authentication ? key-chain key-chain mode mode R3(config-if)#ip authentication mode ? eigrp Enhanced Interior Gateway Routing R3(config-if)#ip authentication mode eigrp <1-65535> Autonomous system number R3(config-if)#ip authentication mode eigrp md5 Keyed message digest R3(config-if)#ip authentication mode eigrp <cr> R3(config-if)#ip authentication mode eigrp R3(config-if)# 04:01:46: %DUAL-5-NBRCHANGE: IP-EIGRP 100: (Ethernet0) is down: Auth failure

Protocol (EIGRP) ? 100 ? 100 md5 ? 100 md5 Neighbor 172.23.23.2

Almost immediately, the adjacency to R2 is dropped - "Auth failure". Let's finish the config with the ip authentication key-chain command and see if it comes back up!
R3(config-if)#ip authentication ? key-chain key-chain mode mode R3(config-if)#ip authentication key-chain ? eigrp Enhanced Interior Gateway Routing Protocol R3(config-if)#ip authentication key-chain eigrp ? <1-65535> Autonomous system number R3(config-if)#ip authentication key-chain eigrp 100 WORD name of key-chain R3(config-if)#ip authentication key-chain eigrp 100 <cr> R3(config-if)#ip authentication key-chain eigrp 100

(EIGRP)

? EIGRPNEIGHBOR ? EIGRPNEIGHBOR

We have no chance of getting the adjacency back until we configure R2 with the same config, so I've done that as well - here's the resulting configuration:
key chain EIGRPNEIGHBOR key 1 key-string KINISKI accept-lifetime 10:00:00 Jan 1 2010 infinite send-lifetime 10:00:00 Jan 1 2010 infinite ! ! ! interface Ethernet0 ip address 172.23.23.2 255.255.255.0 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 EIGRPNEIGHBOR

And in just a few seconds....

04:09:18: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.23.23.2 (Ethernet0) is up: new adjacency

.. the adjacency is back! pings to that neighbor.)

(Of course, trust but verify - I'd send a few

There is a show verification command for the key chain that gives you a very important piece of information at the very far right of the output:
R2#show key chain Key-chain EIGRPNEIGHBOR: key 1 -- text "EIGRP" accept lifetime (10:00:00 UTC Jan 1 2010) - (infinite) [valid now] send lifetime (10:00:00 UTC Jan 1 2010) - (infinite) [valid now]

The key "KINISKI" is shown to be "valid now". What if it wasn't valid? Let's create a key chain with the same name where I mistyped a single number:
R2(config)#key chain EIGRPNEIGHBOR R2(config-keychain)#key 1 R2(config-keychain-key)#key-string SPIDERS R2(config-keychain-key)#accept-lifetime 00:00:00 Jan 1 2020 infinite R2(config-keychain-key)#send-lifetime 00:00:00 Jan 1 2010 infinite

When you're typing this many numbers, it's easy to hit just one wrong key - so always verify with show key chain. If you're expecting this key chain to be valid now, but you don't see that phrase next to each line of the output...
R2#show key chain Key-chain EIGRPNEIGHBOR: key 1 -- text "SPIDERS" accept lifetime (00:00:00 UTC Jan 1 2020) - (infinite) send lifetime (00:00:00 UTC Jan 1 2010) - (infinite) [valid now]

.. you know you mistyped something. To fix this, don't delete the entire key chain - just reenter the config mode and use the no option to remove the unwanted part of the config. Then enter what you meant to enter! :)

Copyright 2011 by The Bryant Advantage. All Rights Reserved.