Welcome to your Bulldog Study Guide for the CCNP ROUTE exam! I know you’re anxious to get started, so I’ll keep this short… Your CCNP ROUTE exam prep requires you to tackle some complex subjects, with BGP, multiarea OSPF, and route redistribution among them. In this guide, you’ll find clear and comprehensive explanations for each and every one of these topics, along with hundreds of illustrations and configs from live Cisco routers.
(I do not use simulators in my books or videos.)
Speaking of videos, I’ve added a special feature to this ebook that’s guaranteed to help you master these complex concepts.
And just as exciting, these features don’t cost anything!
At the end of each section, you’ll find links to videos on my YouTube computer certification video training channel that are related to the topic you just studied.
You’ll find Video Practice Exams, 5-minute Video Boot Camps, and other video types - all of which will help you nail this difficult exam.
You’ll also find links to my free CCNP ROUTE Video Boot Camp on route redistribution and OSPF stub areas, and my full 22-hour CCNP ROUTE Video Boot Camp, available on both DVD and in downloadable format.
That last one’s not quite free, but in a world of $500 video courses, you’ll find the price to be quite
refreshing.
I also invite you to join me on Twitter, Facebook, LinkedIn, and other social media sites. I’m there live every day and happy to chat with you there!
‘Nuff said! Let’s get started … … and as always, thanks for making TBA part of your CCNP success story!
Chris Bryant CCIE #12933
Bulldog” Chris Bryant CCIE #12933
“The Computer Certification Bulldog” [email protected] Website: http://www.thebryantadvantage.com/ Twitter: http://www.twitter.com/ccie12933 Facebook: http://on.fb.me/gPq52d Blog: http://thebryantadvantage.blogspot.com/
YouTube:
Free Resources To Help You
Pass The CCNP ROUTE
Exam!
In addition to this information-packed CCNP ROUTE Study Guide, TBA has literally dozens of additional practice exams, Video Boot Camps, and illustrated tutorials to help you destroy this exam!
First, for some videos!
Certification Channel has quite a few videos on the CCNP ROUTE exam:
http://www.youtube.com/user/ccie12933
I hope you’ll click “subscribe” while you’re out there - I’m adding new videos AND certifications on a regular basis, including Security+, Network+, and a new CCNA Security course in 2012!
You’ll also find links to individual videos on that channel at the end of most chapters of this ebook.
I have a separate Videos & Tutorials page on my website for each of the CCNP exams - here’s the page dedicated to ROUTE:
http://www.thebryantadvantage.com/CCNPCertificationROUTEExam642902Tutorials.htm
Be sure to scroll ALL the way down that page - there are links to practice exams, tutorials, and Video Boot Camps!
For future reference, or for review, here are my pages for the SWITCH and TSHOOT exams:
http://www.thebryantadvantage.com/CCNPCertificationSWITCHExam642813Test.htm
TSHOOT:
http://www.thebryantadvantage.com/CCNPCertificationTSHOOTExam642832Tutorials.htm
I also have a Video Boot Camp hosted on Udemy.com -- well, actually, two of them!
The first is 100% free and is a tremendous lab and lecture on route redistribution and multiarea OSPF. This is must-see material, my friends… and you can watch it online, or you can download it - or both!
http://www.udemy.com/ccnp-route- boot-camp-redistribution-and-ospf-stub-areas/
There’s also a full hour-long preview from my CCNP ROUTE DVD on that site:
http://www.udemy.com/ccnp-route-on-demand-video-boot-camp/
And should you choose to enroll in that course OR get the DVD, please remember to use this link and save yourself $10!
http://www.thebryantadvantage.com/CCNPROUTEStudyGuideUpgrade.htm
When I post new videos or tutorials, or whenever there’s important news in the computer certification world, I always post it on our Facebook and Twitter feeds as well as the Bulldog Blog.
I urge you to click these links and join us!
We have some great conversations and the occasional giveaway out there -- and if you have a question or comment, just send it via Twitter
or leave it on Facebook! I’m always happy to hear from you! Twitter:
http://www.twitter.com/ccie12933
Facebook: http://on.fb.me/gPq52d
Bulldog Blog:
http://thebryantadvantage.blogspot.com/
The CCNP ROUTE exam is a tough one. Use all of these resources in addition to this study guide - and thanks for making TBA part of your CCNP success story!
Chris Bryant CCIE #12933
“The Computer Certification Bulldog”
Copyright © 2012 The Bryant Advantage. All Rights Reserved.
Dedication
For Suzy and Squeaky
Copyright © 2012 The Bryant Advantage. All Rights Reserved.
There’s only one way
to get my crystal-clear
CCNP ROUTE Video
Boot Camp instruction
---- and that’s directly
from TBA.
All of my Video
Boot Camp DVDs give
of training to let you
“Try Before You Buy”!
It’s this sweet and simple:My CCNP Bulldog Boot Camps DVDs have helped network admins around the world - from the UK to Australia, from Russia to the US -become CCNPs.
No other DVD offers my crystal-clear and concise instruction - and I never use simulators in my labs. And I don’t charge you an arm and a
leg for a DVD.
Even better - you can save $10 on any DVD or Bulldog DVD Bundle by following this link:
http://www.thebryantadvantage.com/CCNPROUTEStudyGuideUpgrade.htm
I know you’ll be happy with any and all of my Video Boot Camp DVDs.
You have my word and my name on it.
Chris Bryant CCIE #12933
Bulldog”
Copyright Information:
Cisco®, Cisco® Systems, CCIE™, CCNP, CCNA, Cisco Certified Network Administrator, Cisco Certified Network Professional, and Cisco Certified Internetwork Expert are registered trademarks of Cisco® Systems, Inc., and/or its affiliates in the U.S. and certain countries.
All other products and company names are the trademarks, registered trademarks, and service marks of the respective owners.
Throughout this Study Guide, The Bryant Advantage has used its best efforts to distinguish proprietary trademarks from descriptive names by following the capitalization styles used by the manufacturer. Disclaimer:
This publication, The Bryant
Advantage CCNP ROUTE Study Guide, is designed and intended to
assist candidates in preparation for the CCNP ROUTE exam for the Cisco Certified Network Professional ® certification.
All efforts have been made by the author to make this book as accurate and complete as possible, but no guarantee, warranty, or fitness are implied, expressly or implicitly. The enclosed material is presented on an “as is” basis.
Neither the author, The Bryant Advantage, Incorporated, or the parent company assume any liability or responsibility to any person or entity with respect to loss or damages incurred from the information contained in this workbook.
This Course Guide is an original work by the Author. Any similarities between materials presented in this Study Guide and actual CCNP® exam questions are completely coincidental.
Copyright 2012 © The Bryant Advantage
Copyright © 2012 The Bryant Advantage. All Rights Reserved.
Table Of Contents
Introduction:
Free Resources For The CCNP ROUTE Exam:
Dedication:
DVD Discount Offer: Legal Notices:
EIGRP Fundamentals: EIGRP Intermediate and Advanced Skills:
Link State Protocols And Single-Area OSPF:
Multi-Area OSPF And OSPF Route Redistribution:
BGP:
Remote Workplace: VPNs and IPSec:
Remote Workplace, Part II :
IP Version 6:
Route Redistribution: Bonus Section: Creating A VLSM Scheme:
IP Routing Fundamentals
Okay, I know what you’re thinking! “I’m a CCNA already, I already studied RIP, I know all the Distance Vector stuff, I know my admin distances. Let’s get to the new stuff!”
Before we do that, we’re going to take some time to review and master some fundamental routing skills …
can’t become truly great.
And while I know you’re familiar with these protocols, this chapter is going to be more than a review for you - it’s going to sharpen your skills with these critical protocols to the point where the CCNP ROUTE questions will be child’s play for you.
There’s also more than a little material in this section that will help you big time on your CCNP TSHOOT exam as well.
Let’s get started!
How and Where Distance Vector Protocols Operate
Typically, distance vector protocols are used on Local Area Networks (LANs). While DV protocols work well in smaller and more stable environments, they have several drawbacks that prevent them from being used as Wide Area Network (WAN) protocols.
One drawback is that RIP broadcasts routing updates every 30 seconds, as illustrated by show ip
protocols:
R5#show ip protocols Routing Protocol is “rip”
Sending updates every 30 seconds, next due in 16 seconds Invalid after 180 seconds, hold down 180, flushed after 240
RIPv1 will broadcast full routing tables as the update, regardless of whether anything has actually changed since the last update. This is a waste of bandwidth and resources, since your average LAN’s subnets aren’t going to change every minute. (We hope!)
RIPv2 multicasts updates to 224.0.0.9 rather than broadcasting them, but the updates are still sent out every 30 seconds.
In a larger network, another problem arises. RIP routing updates can hold a maximum of 25 routes, so if there are 105 routes in your network, five separate update packets would be needed. Since these updates would go out every 30 seconds, whether anything had actually changed in the network, RIP is generally a poor choice for a WAN protocol.
Remember, everything we do on a router has a cost to that router and others - a cost in CPU, bandwidth, and time. Those continual RIP updates have a high cost and very little value.
Drawback 2: RIPv1 is a classful routing protocol, and therefore does not support VLSM. The only masks RIPv1 understands are the classful masks for Class A (255.0.0.0), Class B (255.255.0.0), and Class C (255.255.255.0).
Drawback 3: Both versions of RIP only understand hop count
-literally, how many “hops” there are from Point A to Point B. On a LAN, this really isn’t a problem, but RIP’s limitations quickly become a problem on a WAN.
There are two paths between A and B. The path using the two T1 lines is much faster than the 56 kbps path,
but RIP will see these paths as equals. RIP’s routing algorithm, the Bellman-Ford algorithm, considers only hop count in computing its metric.
In this example, RIP will then perform equal-cost load balancing over the two links. (DV protocols perform equal-cost load balancing over four paths by default.)
Default DV Protocol Behaviors
DV protocols do have some drawbacks, but they also have some default behaviors that help prevent
routing loops. You saw all of these in your CCNA studies, but let’s do a quick review.
Split Horizon simply means that a routing protocol cannot advertise a route via the same interface upon which it was learned. Here, Router 3 cannot advertise the loopback network 2.0.0.0 via its ethernet interface, because that is the interface upon which the router first learned about the network.
Poison Reverse allows a router to advertise a network with an metric of “unreachable” when that network becomes unavailable. This allows the other routers to learn that the network is unreachable much faster than if it were left up to the normal DV protocol behaviors -- and in turn, that results in fewer misrouted / lost packets.
It’s obviously in our best interest to have the quickest convergence time possible. If some routers think “network A” is available and others think the network is unavailable, routing for that network is going to be substandard at best and routing loops can easily form.
The Basics Of RIPv1, RIPv2, and EIGRP
RIPv1:
Broadcasts updates every 30 seconds
Classful, does not recognize VLSM, update carries entire routing table
Uses Bellman-Ford algorithm
default, max hop count is 15
No routing update
authentication available
Updates carry 25 routes max
RIPv2:
Multicasts updates every 30 seconds to 224.0.0.9
Classless, supports VLSM, update carries entire routing
table
Uses Bellman-Ford and default equal-cost load
sharing, max hop count is 15, updates carry 25 routes max
Supports routing update authentication (clear-text and MD5)
EIGRP:
Sends entire routing table only when the adjacency is first formed
Sends only routing update after that when necessary, update reflects only the changes
Uses DUAL routing algorithm
Equal-cost load sharing by default, unequal-cost load sharing configured with the variance command
EIGRP is not a pure distance-vector protocol, but I’ve put it here for easy comparison to RIP. I also didn’t go into a discussion of EIGRP here, since we’ll be doing plenty of that later in the course.
The Role Of Administrative Distance
When a route lookup is performed in a routing table, there may be more than one path that meets the criteria for being selected. Basically, there is a four-step process a router goes through when
looking for the best route to use: 1. If there are multiple routes to a destination, the route with the longest prefix length is used.
2. If there are multiple routes to a destination and they have the same prefix length, the route with the lowest administrative distance is used.
3. If there are multiple routes with the same prefix length and
AD, the route with the lowest metric is used.
4. If there are multiple routes with the same prefix length, AD, and metric, all of these routes will be used in load balancing as allowed by the protocol.
Consider a router that is looking through its routing table to decide the next-hop IP address to use to reach the destination 222.1.3.1. I’m going to use IGRP in this
example, but please note that IGRP is obsolete and is no longer tested on Cisco certification exams.
In the unlikely but possible circumstance that the router has one path discovered by OSPF and another by IGRP, the two paths could look like this:
O: 222.1.3.0 /25 via 172.1.1.2, serial1 I: 222.1.3.0 /24 via 175.1.1.2, serial0
In this case, the OSPF route would be chosen, because it is the longest match; its mask is /25, a longer match than IGRP’s classful mask of
/24. The administrative distance (AD) does not come into use. But what if the masks were the exact same length?
O: 222.1.3.0 /24 via 172.1.1.2, serial1 I: 222.1.3.0 /24 via 175.1.1.2, serial0
A tiebreaker is needed, and that’s where the AD comes in. The path discovered by the protocol with the lowest AD will be used. Since IGRP’s AD is 100 and OSPF’s is 110, the IGRP path will actually be used over the OSPF path.
AD values to know:
Directly connected route / Static route using exit interface: 0
Static route with next-hop IP address: 1
EIGRP Summary: 5 (if you know where to look -- more on that later)
Internal EIGRP: 90 OSPF: 110 RIP: 120 External EIGRP: 170 Internal BGP: 200 Unknown network: 255
here from the ADs you learned in earning your CCNA. There are now two kinds of non-summary EIGRP routes listed, internal and external. Much more about those route types in the EIGRP sessions.
Routing Table Operation
This entire operation is practically transparent to you and I as network admins, and that’s fine when things go as we expect.
When things don’t go as we expect -and when we’re studying for Cisco exams! -- we better know the
“hows” and “whys” of the routing table.
We love it when the router has multiple paths to a given network! That way, if we lose one path, we have another - and we’ll take all the redundancy we can get in today’s delay-sensitive networks.
Now that we know how a routing table is built, let’s take a closer look at a small table and identify the different values.
R1#show ip route
Codes: C connected, S static, I IGRP, R -RIP, M - mobile, B - BGP
D EIGRP, EX EIGRP external, O -OSPF, IA - OSPF inter area
N1 OSPF NSSA external type 1, N2 -OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route Gateway of last resort is not set
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:01, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0 C 172.12.123.0/24 is directly connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Ethernet0
There is one RIP route and two directly connected routes. Since we’re primarily interested in the RIP route for this discussion, we’ll run show ip route rip to see only the routes that RIP has discovered.
R1#show ip route rip
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:04, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0
The network 172.12.23.0/27 is the destination. The numbers contained in the brackets are the administrative distance of the protocol that discovered the route, followed by the metric for that path. Since this is a RIP route, the metric shown is the number of hops to that network.
The IP addresses following the word “via” are the next-hop IP addresses, followed by the time this route was last refreshed. Since RIP sends full routing updates every 30 seconds regardless of version, this value will not exceed 30 seconds
for a valid RIP route unless the holddown timers are in use.
Finally, each line ends by naming an interface. This is the local interface that data sent to this destination will use to exit the router. It has nothing to do with the downstream router. In this example, we have two separate paths listed for a single destination. Remember the process a router uses to determine the best path? It’s worth repeating….
The route with the longest prefix length will be selected.
The term “longest prefix match” refers to the length of the subnet mask.
If there are multiple routes with the same prefix length, the route with the lowest
administrative distance will be used. Generally referred to as “AD”, this is a measurement of a protocol’s believability. The lower the AD, the more
believable the protocol.
with the same prefix length and AD, the route with the lowest metric will be preferred.
Finally, if the preceding three values are all equal, equal-cost load sharing will be put into action.
The prefix length, administrative distance, and metrics are all the same. Therefore, RIP will use both paths via equal-cost load sharing. You can verify that load sharing is in operation (and a lot of other
things!) by running show ip protocols.
In this example, we can also see when the next routing update is expected, what version of RIP you’re running, whether routing updates are being authenticated (you would see a value under “Key-chain” if authentication was in use), and whether autosummarization is on or off.
R1#show ip protocols
Routing Protocol is “rip”
Sending updates every 30 seconds, next due in 7 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv
Serial0 2 2
Automatic network summarization is not in effect (autosummarization has been turned
off)
Maximum path: 4
Routing for Networks: 172.12.0.0
Routing Information Sources:
Gateway Distance 172.12.123.3 120
172.12.123.2 120
Distance: (default is 120)
As great as dynamic routing protocols are, I can guarantee you that the time will come when you need to use a routing method that has less overhead. Maybe you’re working with a router with very limited resources; maybe you want to have more personal control about routing operations. There are several methods you can use in these scenarios, and the most common are static routes and default static routes.
Static Routing
Routing protocols are much more effective in keeping an accurate routing table, and adapt to network changes much more quickly than static routing - and it takes a lot less of our time, too.
So why use static routing at all? If a route has one IP address as the next-hop address for every single route in its table, why keep a full dynamic routing table when a single static default route will do?
As we’ll see in the Advanced EIGRP and especially the multiarea OSPF sections, this strategy is actually built in to these dynamic routing protocols.
Static routes can also serve as a tourniquet of sorts for your network. If something goes wrong with your dynamic protocol and you need to give your users a quick path to a gateway that can get them where they need to go, a quick static route can give you (some) peace and quiet while you fix the problem. A static route can also serve as a
backup to a dynamic routing protocols - a floating static route, that is.
A floating static route is assigned an administrative distance higher than that of any dynamic protocol running on the router, ensuring that the only way the static route can be used is if all dynamic routes leave the table.
A default static route serves as a router’s gateway of last resort. Remember that a default static route isn’t the path packets will take first, it’s the path they’ll take if there is
no other match in the routing table at all.
You learned how to configure a static route in your CCNA studies, but let’s quickly review the syntax:
R1(config)#ip route 3.3.3.3 255.255.255.255 172.12.123.3
R1(config)#ip route 3.3.3.3 255.255.255.255 serial0
These two static routes are both host routes; that is, they are valid for only one destination, in this case 3.3.3.3 /32. Note that the mask is a subnet mask, not a wildcard mask.
In the first example, the IP address at the end of the static route is the next-hop IP address for the route. In the second, the interface named at the end of the static route is the local exit interface.
You will never configure a static route that uses a local IP address or a remote interface name.
You’ll use the ip route command for a default static route, but the IP address and mask look rather odd:
R1(config)#ip route 0.0.0.0 0.0.0.0 172.12.123.3 R1#show ip route
< code table removed for clarity >
Gateway of last resort is 172.12.123.3 to network 0.0.0.0 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:14, Serial0 [120/1] via 172.12.123.3, 00:00:26, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 S* 0.0.0.0/0 [1/0] via 172.12.123.3
The ip route statement contains all zeroes for both the destination and mask. The gateway of last resort is now set, and any data that does not
have a match in the routing table will be sent to the next-hop address 172.12.123.3. The asterisk next to the S indicates that this is a default route.
The ip route statement for a default route can also end with the local exit interface:
R1(config)#ip route 0.0.0.0 0.0.0.0 serial0 R1#show ip route
< code table removed for clarity >
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:26, Serial0 [120/1] via 172.12.123.3, 00:00:08, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0 S* 0.0.0.0/0 is directly connected, Serial0 R1#
While the gateway is now set to 0.0.0.0 rather than 172.12.123.3, the net effect is the same. I personally like to configure a default static route with a specified next-hop address, but it’s up to the individual.
Floating Static Routes In Action
In this lab and all others in the course, all IP addresses end with the router’s number. For example, R1’s Serial0 interface on the 172.12.123.0 /24 network has an IP address of 172.12.123.1.
Note that RIP is not running over the entire network -- it’s not running over the serial link connecting R1 and R3’s serial1 interfaces.
172.12.123.0 /24
R1 / R3 Serial Connection: 210.1.1.0 /24
R2 / R3 Ethernet Network: 172.12.23.0 /27
You might be wondering if there will ever actually be a situation where you wouldn’t run a dynamic protocol over that link. If you’re
like me, you’re thinking “Why wouldn’t I just run RIP over the link and let the protocol figure all of this out?”
Ordinarily we’d be happy to do that, but in this case we’re being asked not to use the S1 link unless the S0 link goes down. That happens more often than you might think, for these reasons…
Bandwidth availability through the S0 link is much higher than that of the S1 link, but RIP will see them as equal
Perhaps the S1 link flaps on occasion and the S0 link is considered to be much more stable
Perhaps the client just doesn’t want to listen to reason and just doesn’t want to use that link and just doesn’t want to hear anything about it (this happens on occasion, too)
Now let’s hit this lab!
R1 has two next-hop addresses for the 172.12.23.0 /27 network:
R1#show ip route rip 172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:04, Serial0 [120/1] via 172.12.123.3, 00:00:04, Serial0
We need a static route that will appear in the routing table only if those RIP links are gone, but we also know the AD of a static route is much lower than that of a RIP-discovered route.
Here’s how we fix that:
R1(config)#ip route 172.12.23.0 255.255.255.224 210.1.1.3 ?
<1-255>
Distance metric for this route name Specify name of the next hop permanent permanent route
tag this routeSet tag for
R1(config)#ip route 172.12.23.0 255.255.255.224 210.1.1.3 200
Using the option to change the static route’s administrative distance (that’s what “distance metric for
this route” refers to) creates the static route with an AD of 200. In this case, anything higher than 120 will do.
We hope. Let’s check it out….
R1#show ip route
< code table removed for clarity >
172.12.0.0/16 is variably subnetted, 3 subnets, 2 masks C 172.12.13.0/24 is directly connected, Serial1 R 172.12.23.0/27 [120/1] via 172.12.123.2, 00:00:21, Serial0 [120/1] via 172.12.123.3, 00:00:05, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Ethernet0
Now we need to test the config, and since we’re in a lab environment, we’ll close S0 and cut off the RIP updates. The result:
R1#show ip route
< code table removed for clarity >
172.12.0.0/27 is subnetted, 1 subnets
S 172.12.23.0 [200/0] via 210.1.1.3
10.0.0.0/24 is subnetted, 1 subnets
C 10.1.1.0 is directly connected, Ethernet0
C 210.1.1.0/24 is directly connected, Serial1 R1#ping 172.12.23.3
Sending 5, 100-byte ICMP Echos to 172.12.23.3, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms
When we reopen R1’s S0 interface, the RIP updates will again be received by R1 and the floating static route will be removed from the table due to its higher AD.
R1(config)#int s0
R1(config-if)#no shutdown
R1#show ip route
< code table removed for clarity >
172.12.0.0/16 is variably subnetted, 2 subnets, 2 masks
172.12.123.2, 00:00:17, Serial0 [120/1] via 172.12.123.3, 00:00:00, Serial0 C 172.12.123.0/24 is directly connected, Serial0 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, Ethernet0
C 210.1.1.0/24 is directly connected, Serial1
On-Demand Routing (ODR)
In today’s world, the phrase “On-Demand” brings to mind the latest in technology, where you can watch anything from my Cisco certification video training to the latest episode of Pawn Stars or Parking Wars anytime you like with
the push of a button or the click of a mouse.
The latest and greatest in technology, right?
Right! Except for “On-Demand Routing” (ODR). ODR can come in handy for one major reason:
Everything we do on a Cisco router or switch has a cost, in the form of CPU, bandwidth, and / or time.
This is especially true of dynamic routing protocols, so in small
networks with routers that don’t have resources to spare, static routing can be beneficial.
In a larger network, though, there is the need for a middle ground between static routing and running a dynamic routing protocol. In Cisco, this is ODR.
Why just Cisco? Because ODR uses our old friend Cisco Discovery Protocol (CDP). As you well know, CDP is Cisco-proprietary, so if we have a multivendor environment, ODR is not a viable solution.
Make sure your ODR routers are running CDP with show cdp.
On top of that, ODR is designed for use only in a hub-and-spoke network. If you have such a network and the bandwidth is limited, ODR may be an appropriate solution. ODR also supports VLSM.
The spokes are going to use ODR to send directly connected network prefixes to the hub. The spoke will use the IP address of the hub on the common link as its default gateway. By using only a single default route, the spoke routers conserve their
resources.
Propagating A Default Route With RIP, IGRP, And No IP Routing
When it comes to default routing, you’ve got three choices:
Use the ip route command with all zeroes for the destination address and subnet mask
Use the ip default-network command
command
You’ve got the ip route command down cold at this point, so let’s take a closer look at ip default-network. We’ll use the following network. The common subnet is 172.12.123.0 /24. We want R1 to advertise its directly connected network 100.1.1.0 /24 to R2 and R3 as a default route.
The ip default-network command is used to flag a network as a candidate default route. The routers are already running RIP over the
common subnet. R1 will now introduce 100.1.1.0 /24 as the default network.
R1(config)#ip default-network 100.1.1.0
R2 and R3 will see this route as a default route discovered by RIP:
R2#show ip route
Codes: C connected, S static, I IGRP, R -RIP, M - mobile, B - BGP
D EIGRP, EX EIGRP external, O -OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 OSPF external type 1, E2 -OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
static route, o - ODR
P - periodic downloaded static route Gateway of last resort is 172.12.123.1 to network 0.0.0.0 2.0.0.0/32 is subnetted, 1 subnets C 2.2.2.2 is directly connected, Loopback0 172.12.0.0/24 is subnetted, 1 subnets C 172.12.123.0 is directly connected, Serial0 R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:02:20, Serial0
The default route named by ip default-network didn’t have to be manually redistributed into RIP. It’s placed there automatically by the
router when this command is used. Speaking of redistribution, we could have created a default static route on R1 and then redistributed it into RIP. We’ll remove the ip default-network command and do just that.
R1(config)#no ip default-network 100.0.0.0 R1(config)#ip route 0.0.0.0 0.0.0.0 ethernet0 R1(config)#router rip
R1(config-router)#redistribute static metric 1
R2 and R3 will both see the default route.
R2#show ip route rip
00:00:12, Serial0 R3#show ip route rip
R* 0.0.0.0/0 [120/1] via 172.12.123.1, 00:00:02, Serial0
Much more redistribution to come!
IP Helper Addresses
While routers accept and generate broadcasts, they do not forward them. That can present quite a problem with DHCP requests when a router is between the requesting host and the DHCP server. The initial step in the DHCP process has the host generating a
DHCPDiscover packet - and that packet is a broadcast.
If this PC attempts to locate a DHCP server with a broadcast, the broadcast will be stopped by the router and will never get to the DHCP server. By configuring the ip
helper-address command on the router, UDP broadcasts such as this will be translated into a unicast by the router, making the communication possible.
The command should be configured on the interface that will be receiving the broadcasts --not the interface closest to the destination device.
R1(config)#int e0
R1(config-if)#ip helper-address ? A.B.C.D IP destination address R1(config-if)#ip helper-address 100.1.12
DHCP messages are not the only broadcasts being relayed to the correct destination with this command -- there are nine of them.
TIME, port 37
TACACS, port 49
DNS, port 53
BOOTP/DHCP Server, port 67
TFTP, port 69
NetBIOS name service, port 137
NetBIOS datagram service, port 138
IEN-116 name service, port 42
That’s going to cover most scenarios where the ip
helper-address command will be useful, but what about those situations where the broadcast you need forwarded is not on this list? You can use the ip forward-protocol command to add any UDP port number to the list.
To remove protocols from the list, use the no ip forward-protocol command. In the following example, we’ll add the Network Time Protocol port to the forwarding list while removing the NetBIOS ports. Remember, you can use IOS Help to get a list of commonly filtered ports!
R1(config)#ipforward-protocol udp ? <0-65535> Port number biff Biff (mail notification, comsat, 512) bootpc Bootstrap Protocol (BOOTP) client (68) bootps Bootstrap Protocol (BOOTP) server (67) discard Discard (9) DNSIX security
dnsix protocol auditing (195)
domain Domain Name Service (DNS, 53) echo Echo (7) isakmp (500) Internet Security Association and Key Management Protocol mobile-ip Mobile IP registration (434) nameserver IEN116 name service (obsolete, 42) netbios-dgm NetBios datagram service (138)
netbios-ns NetBios name service (137) netbios-ss NetBios session
service (139) ntp Network Time Protocol (123) pim-auto-rp PIM Auto-RP (496) rip Routing Information Protocol (router, in.routed, 520) snmp Simple Network Management Protocol (161) SNMP Traps
snmptrap (162) sunrpc Sun Remote Procedure Call (111) syslog System Logger (514)
tacacs TAC Access Control System (49) talk Talk (517) tftp Trivial File Transfer Protocol (69) time Time (37) who Who service
(rwho, 513) X Display
xdmcp Manager Control Protocol (177) <cr>
R1(config)#ip forward-protocol udp 123 R1(config)#no ip forward-protocol udp 137 R1(config)#no ip forward-protocol udp 138
Recommended Video Viewing: Three-part Video Boot Camp on Floating Static Routes on TBA website:
http://bit.ly/bxNIBh
on Static Routes on TBA Website:
http://bit.ly/dourQ2
Free CCNP ROUTE Video Boot Camp on route redistribution:
http://bit.ly/Arnhjq
My CCNP ROUTE Video Boot Camp - Exclusive Discount Link For My Ebook Readers Only!
Just click this link for a free hour-long preview AND $10 off the already low price!
http://bit.ly/A7pLBu
and on DVD!
Copyright © 2012 The Bryant Advantage. All Rights Reserved.
EIGRP Fundamentals
Introduction To EIGRP
Link state protocols (OSPF) and distance vector protocols (RIP) have clear-cut differences in the way the best routes are determined and what is actually exchanged between routers. Just as a hybrid plant has characteristics of more than one plant, a hybrid routing protocol has characteristics of both link state and distance vector protocols. The hybrid protocol is
Enhanced Interior Gateway Routing Protocol – EIGRP.
EIGRP has a lot going for it: Rapid convergence upon a change in the network, because backup routes (“Feasible Successors”) are calculated before they’re actually needed due to the loss of a primary route (“Successor”)
Offers multiprotocol support (supports IP, IPX, and
Supports Variable-Length Subnet Masking (VLSM) and Classless Inter-Domain Routing (CIDR)
The one little problem with EIGRP is that it’s Cisco-proprietary, making it unsuitable for a multivendor environment.
EIGRP is the enhanced version of the original Interior Gateway Routing Protocol (IGRP), which is no longer supported by new Cisco IOSes and is no longer a part of
Cisco certification exams. I’ll mention it occasionally in the EIGRP sections for comparison’s sake.
EIGRP acts like a distance vector protocol in that EIGRP neighbors initially exchange full routing tables. Just about every other EIGRP behavior is more like a link state protocol.
Hello Packets and RTP: The Heartbeat Of EIGRP
EIGRP uses Hello packets (multicast to 224.0.0.10) to
establish and maintain neighbor relationships. The Reliable Transport Protocol (RTP) is used to handle the transport of messages between EIGRP-enabled routers. EIGRP also acts like a link state protocol in that when network topology changes occur, updates containing only the change are sent, rather than another full routing table.
EIGRP uses autonomous systems to identify routers that will belong to the same logical group. EIGRP routers that exist in separate autonomous systems will not
exchange routes. They won’t even become neighbors in the first place! For an EIGRP neighbor relationship to be established, the routers must receive Hello packets from the neighbor, the Autonomous System number must match, and the metric weights must match.
The metric weights refer to the level of importance EIGRP gives to the bandwidth, delay, load, and reliability metrics. By default, EIGRP considers bandwidth and delay when calculating metrics, and does not consider the other metric
weights.
Changing the metric weights is covered in the Advanced EIGRP section; for now, know that these metric weights must be the same on each router or the neighbor relationship will not be established. As with OSPF, once the neighbor relationship is present, it is the Hello packets that keep it alive. If the Hellos are no longer received by a router, the neighbor relationship will eventually be terminated.
The Successor and Feasible Successor
EIGRP keeps three tables - the route table, where the best route to each destination is kept; the topology table, where all feasible routes are kept; and the neighbor table, where the EIGRP neighbors and information about them are kept.
As an EIGRP-enabled router learns about the network, the router will put the best route to a given destination in its routing table. EIGRP keeps the best routes along
with less-desirable but still valid routes in the topology table. EIGRP actually calculates these backup routes before a failure occurs, making convergence after a failure much faster than RIP.
The EIGRP term for the best route is Successor. Any valid alternate route is referred to as the Feasible Successor. The decision process for whether a route can become a Feasible Successor can be summed up in one question….
The EIGRP Feasible Successor Question:
The router asks itself, “Is the neighboring router’s metric for this route lower than my metric?”
If so, no loop is present, and that route is a Feasible Successor.
If not, a loop may be present, and that route cannot be a Feasible Successor.
That’s all well and good - but what if there is no Feasible Successor? EIGRP uses the Diffusing Update Algorithm (DUAL) to issue queries
to neighbors for a loop-free route to the destination. If the routers receiving the DUAL queries do not have a route, those routers will also send DUAL queries to their neighbors. This process continues until a route is found and the original router is informed of the route, or no valid route is found. More about those queries later in the two EIGRP sections.
EIGRP’s Major Advantage Over RIP
RIPv2 is not. Both support VLSM, so why not use RIPv2 over EIGRP? Consider the following:
If you or I were asked what the optimal path(s) are between R1 and
R2, we wouldn’t hesitate - T1 lines run at 1544 kbps, almost thirty times faster than a 56 kbps line, so the extra “hop” over the R1 paths will hardly matter.
EIGRP would agree with us, but RIPv2 would not. RIPv2 does have its uses, but it only considers hop count as a metric. Therefore, RIPv2 would consider the path from R1-R5-R2 the best path - and it’s nowhere near the best path!
Since both EIGRP and OSPF consider the speed of a link in its calculations, we’re almost always
better off to use those two protocols for our WANs. OSPF is not Cisco-proprietary, so if we do have some non-Cisco routers (booooo!) in the WAN, we could still use that instead of RIPv2.
Configuring EIGRP
EIGRP uses Autonomous Systems to put EIGRP-enabled routers into logical groups. For two routers to become EIGRP neighbors, they must agree on the AS number. To enable EIGRP on a particular interface, we’ll use the network command. The use of wildcard
masks is optional, but you’ll see them in 99% of real-world EIGRP deployments. Just watch that on the exam - EIGRP and OSPF both use wildcard masks in their network statements, not subnet masks.
R1#conf t R1(config)#router eigrp 100 R1(config-router)#no auto-summary R1(config-router)#network 172.12.123.0 0.0.0.255 R2#conf t
R2(config)#router eigrp 100 R2(config-router)#no auto-summary R2(config-router)#network 172.12.123.0 0.0.0.255 R3(config)#router eigrp 100 R3(config-router)#network 172.12.0.0 0.0.255.255 R3(config-router)#no auto-summ
Note that I disabled auto-summarization on all three routers. EIGRP has autosummarization running by default, and usually you’re going to disable it even before you enter your network statements! You’ll see why - and what can happen if you don’t disable auto-summarization - later in this chapter. You can also enter the no auto-summary command after your network statements, as shown on R3.
Wildcard masks are used when configuring network numbers in EIGRP. This mask type allows the
configuration to be more specific in what interfaces will be running EIGRP. With the above wildcard masks, any interfaces in the network 172.12.123.0 /24 will run EIGRP.
Wildcard Masks
Wildcard masks do look a little odd at first, but since we use them in access lists, EIGRP, and OSPF, we better know how to configure them! They’re really just “reverse subnet masks”. For instance, the network 172.12.123.0 255.255.255.0 means
that all hosts that begin with
172.12.123 are part of that network. When you write out the network number and the mask in binary and compare the two, the ones in the subnet mask are “care” bits and the zeroes are “don’t care” bits.
172.12.123.0 = 10101100 00001100 01111011 00000000 255.255.255.0 = 11111111 11111111 11111111 00000000
What do I mean by “care” and “don’t care”? For a host to be on
the 172.12.123.0 /24 network, the host’s address must match every bit where there is a 1 in the network mask. After that, I don’t care!
Wildcard masks take the opposite approach. The zeroes are “I care”, and the ones are “I don’t care”. In this example, we want to enable EIGRP on all interfaces whose first three octets are 172.12.123, and after that, we don’t care!
10101100 00001100 01111011 00000000 = 172.12.123.0
11111111 = 0.0.0.255
Using wildcard masks takes some getting used to, and just make sure to be careful on your exam:
Subnet masks begin with strings of consecutive 1s
Wildcard masks begin with strings of consecutive 0s and are required in OSPF network statements, but not EIGRP network statements
Now let’s get back to our EIGRP deployment!
A few seconds after configuring the three routers with EIGRP, this console message appears on R1:
The Diffusing Update Algorithm (DUAL) has run and two new neighbors, 172.12.123.2 and 172.12.123.3, have formed adjacencies with R1. Show ip eigrp neighbors gives the details:
The key values are the IP addresses of the EIGRP AS 100 neighbors, the interface on which they were discovered, and the Uptime, indicating how long the neighbor relationship has existed.
The loopbacks on each router will now be added to EIGRP 100, as well as the Ethernet segment between R2 and R3. The ethernet segment’s network number is 172.23.23.0 /27, so we get a little more practice with our wildcard masks! The loopbacks all have their router number for each octet, and each loopback has been configured
with a host mask (255.255.255.255 or /32).
R1(config)#router eigrp 100 R1(config-router)#network 1.1.1.1 0.0.0.0 R2(config)#router eigrp 100 R2(config-router)#network 172.23.23.0 0.0.0.31 R2(config-router)#network 2.2.2.2 0.0.0.0 R3(config)#router eigrp 100 R3(config-router)#network 172.23.23.0 0.0.0.31 R3(config-router)#network 3.3.3.3 0.0.0.0
show ip route eigrp 100 is then run at each router to ensure each router is seeing the other routers’ loopbacks, and that R1 is seeing the Ethernet segment via EIGRP. R2 and R3 are both directly connected to the 172.23.23.0 /27 network, so
there will be no EIGRP route to that network in their EIGRP tables. The Successor routes appear in two of our three EIGRP tables. The EIGRP Route table, seen with show ip route eigrp, contains only the Successor routes. R1 has two Successor routes for 172.23.23.0 /27.
R1#show ip route eigrp
2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:01:01, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:58, Serial0 172.23.0.0/27 is subnetted, 1 subnets
D 172.23.23.0 [90/2195456] via 172.12.123.2, 00:01:01, Serial0
[90/2195456] via 172.12.123.3, 00:01:01, Serial0
R2#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets D 1.1.1.1 [90/2297856] via 172.12.123.1, 00:01:33, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/409600] via 172.23.23.3, 00:01:35, Ethernet0
R3#show ip route eigrp
1.0.0.0/32 is subnetted, 1 subnets D 1.1.1.1 [90/2297856] via 172.12.123.1, 00:01:46, Serial0 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/409600] via 172.23.23.2, 00:01:49, Ethernet0
As always, the first number in the brackets is the protocol’s Administrative Distance. The second number is the EIGRP metric for that route.
Each router sees the other routers’ loopbacks, and can ping them (ping results not shown). R1 can not only ping the Ethernet interfaces of R2 and R3, but has two routes to that subnet in its routing table. EIGRP is performing equal-cost load balancing.
The metric for the route is 2195456 for both routes, so data flows going
from R1 to the 172.23.23.0 /27 network will be balanced over the two Frame Relay cloud links.
To see the Successor and Feasible Successor routes in EIGRP, run show ip eigrp topology. On R1, two successors for the route 172.23.23.0/27 exist, so both are placed into the routing table as seen previously. There are also two routes for destinations 2.2.2.2/32 and 3.3.3.3/32, but those have not been placed into the EIGRP routing table. Why?
R1#show ip eigrp topology
AS(100)/ID(1.1.1.1)
Codes: P Passive, A Active, U Update, Q -Query, R - Reply,
r - reply Status, s - sia Status P 3.3.3.3/32, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 P 2.2.2.2/32, 1 successors, FD is 2297856 via 172.12.123.2 (2297856/128256), Serial0 via 172.12.123.3 (2323456/409600), Serial0 P 1.1.1.1/32, 1 successors, FD is 128256 via Connected, Loopback0
P 172.23.23.0/27, 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
R1 has two valid, loop-free routes to 2.2.2.2/32 and 3.3.3.3/32 in its Topology table… P 3.3.3.3/32, 1 successors, FD is 2297856 via 172.12.123.3 (2297856/128256), Serial0 via 172.12.123.2 (2323456/409600), Serial0 P 2.2.2.2/32, 1 successors, FD is 2297856 via 172.12.123.2 (2297856/128256), Serial0 via 172.12.123.3 (2323456/409600), Serial0
…. but the metrics are unequal, so only the best path (the Successor) is placed into the EIGRP Route table.
R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:12:54, Serial0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/2297856] via 172.12.123.3, 00:12:51, Serial0 172.23.0.0/27 is subnetted, 1 subnets D 172.23.23.0 [90/2195456] via 172.12.123.2, 00:12:54, Serial0 [90/2195456] via 172.12.123.3, 00:12:54, Serial0
The metrics for those routes are very close, so close that it’s a good idea for us to use both of them for load balancing. We can use the variance command here to configure unequal-cost load balancing.
The variance Command
The variance command is simply a multiplier. The router will multiply the Feasible Distance by this value. Any feasible successor with a metric less than that new value will be entered into the routing table. In print, that sounds a little confusing. In reality, it’s simple, as you’re about to see!
Consider the path from R1 to R2’s loopback in the previous tables. The primary route has a metric of 2297856; the other route has a
metric of 2323456. By default, the second route will serve only as a backup and will not carry packets unless the primary goes down.
By configuring variance 2 in R1’s EIGRP process, the process multiplies the metric of the best route (2297856) by the variance value:
2297856 x 2 = 4595712 Any feasible successor with a metric less than 4595712 will now participate in unequal-cost load sharing.
R1’s feasible successor to 2.2.2.2 has a metric of 2323456, so it qualifies! After changing the variance value to 2 (by default, it’s 1) and clearing the routing table, show ip route eigrp 100 verifies that two valid routes to both R2’s and R3’s loopbacks appear in the EIGRP routing table.
R1(config)#router eigrp 100 R1(config-router)#variance ?
<1-128> Metric variance multiplier R1(config-router)#variance 2
R1#clear ip route * (clears the routing table of all dynamically learned routes)
R1#show ip route eigrp 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/2297856] via 172.12.123.2, 00:00:26, Serial0 [90/2323456] via 172.12.123.3, 00:00:26, Serial0 3.0.0.0/32 is subnetted, 1 subnets 3.3.3.3 [90/2297856] via 172.12.123.3, 00:00:26, Serial0 [90/2323456] via 172.12.123.2, 00:00:26, Serial0 172.23.0.0/27 is subnetted, 1 subnets D 172.23.23.0 [90/2195456] via 172.12.123.2, 00:00:26, Serial0 [90/2195456] via 172.12.123.3, 00:00:26, Serial0
The variance command does not actually change the metrics; it makes a higher metric acceptable
for load sharing.
Autosummarization - One Default You’ll Want To Change
EIGRP and RIP version 2 perform autosummarization by default, which is the act of summarizing network routes when those routes are sent across a network boundary; that is, when they are advertised via an interface that is not part of the network being summarized.
In the earlier lab, I disabled autosummarization immediately, but
I will not do so here.
To illustrate, we’ll use a hub-and-spoke network where both hub-and-spokes have subnets of 20.0.0.0/8. The Serial interfaces are all on the 172.12.123.0 /24 network, with the router number serving as the final octet. All interfaces will be placed into EIGRP AS 100.
Here are the current configurations. I did not configure the auto-summary command -- it’s on by default and will appear in the router configuration. R1: router eigrp 100 network 172.12.123.0 0.0.0.255 auto-summary R2: router eigrp 100 network 20.1.0.0 0.0.255.255
network 20.2.0.0 0.0.255.255 network 172.12.0.0 auto-summary R3: router eigrp 100 network 20.3.0.0 0.0.255.255 network 20.4.0.0 0.0.255.255 network 172.12.0.0 auto-summary Network 20.0.0.0 is discontiguous – there is no single path to all subnets of the major network number. That’s a problem for routing protocols such as RIPv1 that do not carry subnet mask
information.
EIGRP and RIPv2 do carry subnet mask information, but the default autosummarization causes trouble with this network. R1 is now receiving the exact same update from both R2 and R3, and it’s for the classful network 20.0.0.0 /8.
Here’s R1’s EIGRP route table. None of the subnets are present in the routing table.
R1#show ip route eigrp
D 20.0.0.0/8 [90/2297856] via 172.12.123.3, 00:11:19, Serial0
[90/2297856] via 172.12.123.2, 00:11:19, Serial0
Since the metrics for both paths are exactly the same, equal-cost load balancing for the classful network 20.0.0.0 will be performed, ensuring that at least half of the packets destined for any particular subnet of 20.0.0.0 will be going to
the wrong router.
If the metric were unequal, a single route for the classful network 20.0.0.0 would be placed into the routing table. All packets for the four subnets will go to the same router, and two of the four subnets will never receive any packets that were originally intended for them. I’ll ping each loopback IP address from R1 - as you’d guess from that routing table, we’re going to get some really interesting results.
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds:
!U!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 68/68/68 ms
R1#ping 20.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.2.2.2, timeout is 2 seconds:
U!.!U
Success rate is 40 percent (2/5), round-trip min/avg/max = 68/68/68 ms
R1#ping 20.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.3.3.3, timeout is 2 seconds:
U!.!U
min/avg/max = 68/68/68 ms R1#ping 20.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.4.4.4, timeout is 2 seconds:
!U!.!
Success rate is 60 percent (3/5), round-trip min/avg/max = 68/68/68 ms
That is one ugly combination of successful pings, timeouts, and Unreachables - and an ugly success rate as well.
This default behavior is easily removed with the no auto-summary command. When both of the routers sending updates add this command
to their EIGRP configuration, the routes will no longer be summarized at the network boundary.
One often-ignored side effect of adding no auto-summary to an existing EIGRP configuration - the adjacencies will drop.
R3(config)#router eigrp 100
R3(config-router)#no auto-summary R3(config-router)#^Z
R3#wr
00:26:09: %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 172.12.123.1 (Serial0) is down: summary configured
After configuring no auto-summary on both R2 and R3 and waiting for the adjacencies to reform, R1 now has a much more accurate routing table.
R1#show ip route eigrp
20.0.0.0/16 is subnetted, 4 subnets D 20.4.0.0 [90/2297856] via 172.12.123.3, 00:00:11, Serial0 D 20.1.0.0 [90/2297856] via 172.12.123.2, 00:03:47, Serial0 D 20.2.0.0 [90/2297856] via 172.12.123.2, 00:03:47, Serial0 D 20.3.0.0 [90/2297856] via 172.12.123.3, 00:00:20, Serial0
Bottom line: If you’re running EIGRP and you’re not seeing the subnets or routes you expect, the first thing I’d check is to see if the no auto-summary command is in the configuration. If it’s not, I’d put it there.
