Skip to main content

NETWORK BASICS

Network A system of interconnected computers and computerized peripherals such as printers is called computer network. This interconnection among computers facilitates information sharing among them. Computers may connect to each other by either wired or wireless media. A computer network consists of a collection of computers, printers and other equipment that is connected together so that they can communicate with each other.  


Network application
A Network application is any application running on one host and provides a communication to another application running on a different host, the application may use an existing application layer protocols such as: HTTP(e.g. the Browser and web server), SMTP(e.g. the email-client). And may be the application does not use any existing protocols and depends on the socket programming to communicate to another application. So the web application is a type of the network applications. 
There are lots of advantages from build up a network, but the th…

Enhanced IGRP

routing technologyTHE FOLLOWING ICND2 EXAM TOPICS ARE COVERED IN THIS CHAPTER:

Routing Technologies Compare and contrast distance vector and link-state routing protocols Compare and contrast interior and exterior routing protocols Configure, verify, and troubleshoot EIGRP for IPv4 (excluding authentication, filtering, manual summarization, redistribution, stub) Configure, verify, and troubleshoot EIGRP for IPv6 (excluding authentication, filtering, manual summarization, redistribution, stub Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco protocol that runs on Cisco routers and on some Cisco switches. In this chapter, I’ll cover the many features and functions of EIGRP, with an added focus on the unique way that it discovers, selects, and advertises       routes.
EIGRP has a number of features that make it especially useful within large, complex networks. A real standout among these is its support of VLSM, which is crucial to its ultra-efficient scalability. EIGRP even includes benefits gained through other common protocols like OSPF and RIPv2, such as the ability to create route summaries at any location you choose.
I’ll also cover key EIGRP configuration details and give you examples of each, as well as demonstrate the various commands required to verify that EIGRP is working properly. Finally, I’ll wrap up the chapter by showing you how to configure and verify EIGRPv6. I promise that after you get through it, you’ll agree that EIGRPv6 is truly the easiest part of this chapter!

EIGRP Features and Operations

EIGP is a classless, distance-vector protocol that uses the concept of an autonomous system to describe a set of contiguous routers that run the same routing protocol and share routing information; it also includes the subnet mask in its route updates. This is a very big deal because by advertising subnet information, this robust protocol enables us to use VLSM and permits summarization to be included within the design of EIGRP networks.

EIGRP is sometimes referred to as a hybrid routing protocol or an advanced distance-vector protocol because it has characteristics of both distance-vector and some link-state protocols. For example, EIGRP doesn’t send link-state packets like OSPF does. Instead, it sends traditional distance-vector updates that include information about networks plus the cost of reaching them from the perspective of the advertising router

EIGRP has link-state characteristics as well—it synchronizes network topology information between neighbors at startup and then sends specific updates only when topology changes occur (bounded updates). This particular feature is a huge advancement over RIP and is a big reason that EIGRP works so well in very large networks.

EIGRP has a default hop count of 100, with a maximum of 255, but don’t let this confuse you because EIGRP doesn’t rely on hop count as a metric like RIP does. In EIGRP-speak, hop count refers to how many routers an EIGRP route update packet can go through before it will be discarded, which limits the size of the autonomous system (AS). So don’t forget that this isn’t how metrics are calculated with EIGRP!
There are a bunch of powerful features that make EIGRP a real standout from other protocols. Here’s a list of some of the major ones:
Support for IP and IPv6 (and some other useless routed protocols) via protocol-dependent modules Considered classless (same as RIPv2 and OSPF) Support for VLSM/CIDR Support for summaries and dis-contiguous networks Efficient neighbor discovery Communication via Reliable Transport Protocol (RTP) Best path selection via Diffusing Update Algorithm (DUAL) Reduced bandwidth usage with bounded updates

No broadcasts Neighbor Discovery
Before EIGRP routers can exchange routes with each other, they must become neighbors, and there are three conditions that must be met before this can happen, And these three things will be exchanged with directly connected neighbors: Hello or ACK received AS numbers match Identical metrics (K values)Link-state protocols often use Hello messages to establish who their neighbors are because they usually don’t send out periodic route updates but still need a way to help neighbors know when a new peer has arrived or an old one has gone down. And because Hellos are also used to maintain neighbor relationships, it follows that EIGRP routers must also continuously receive Hellos from their neighbors. But EIGRP routers that belong to different ASs don’t automatically share routing information and, therefore, don’t become neighbors. This factor is really helpful operating in larger networks because it reduces the amount of route information propagated through a specific AS. But it also means that manual redistribution can sometimes be required between different ASs as a result. Because metrics play a big role in choosing between the five possible factors to be evaluated when choosing the best possible route, it’s important that all EIGRP neighbors agree on how a specific route is chosen. This is vital because the calculations on one router depend upon the calculations of its neighbors. Hellos between EIGRP routers are set to 5 seconds by default. Another timer that’s related to the hello timer is the hold timer. The hold timer determines the amount of time a router is willing to wait to get a Hello from a neighbor before declaring it dead. Once a neighbor is declared dead, it’s removed from the neighbor table and all routes that depended upon it are recalculated. Interestingly, the hold timer configuration doesn’t determine how long a router waits before it declares neighbors dead; it establishes how long the router will tell others to wait before they can declare it dead. This means that the hold timers on neighboring routers don’t need to match because they only tell the others how long to wait.
The only time EIGRP advertises its entire information is when it discovers a new neighbor and forms a relationship or adjacency with it by exchanging Hello packets. When this happens, both neighbors then advertise their complete information to one another. After each has learned its neighbor’s routes, only changes to the routing table will be propagated. During each EIGRP session running on a router, a neighbor table is created in which the router stores information about all routers known to be directly connected neighbors. Each neighboring router’s IP address, hold time interval, smooth round-trip timer (SRTT), and queue information are all kept in this table. It’s an important reference used to establish that topology changes have occurred that neighboring routers need to know about.
To sum this all up, remember that EIGRP routers receive their neighbors’ updates and store them in a local topology table that contains all known routes from all known neighbors and serves as the raw material from which the best routes are selected.

Let’s define some terms before we move on:
Reported/advertised distance (RD/AD) This is the metric of a remote network, as reported by a neighbor. It’s also the routing table metric of the neighbor and is the same as the second number in parentheses as displayed in the topology table. The first number is the administrative distance, and I’ll discuss more about these values in a minute. In Figure 17.2, routers SF and NY are both advertising the path to network 10.0.0.0 to the Corp router, but the cost through SF to network
10.0.0.0 is less than NY.
We’re not done yet because the Corp router still needs to calculate its cost to each neighbor.
Feasible distance (FD) This is the best metric among all paths to a remote network, including the metric to the neighbor that’s advertising the remote network. The route with the lowest FD is the route that you’ll find in the routing table because it’s considered the best path. The metric of a feasible distance is calculated using the metric reported by the neighbor that’s referred to as the reported or advertised distance plus the metric to the neighbor reporting the route. In Figure 17.3, the Corp router will have the path through router SF to network 10.0.0.0 in the routing table since it’s the lowest feasible distance. It’s the lowest true cost from end to end.
Take a look at an EIGRP route that’s been injected into a routing table and find the FD listed in the entry.
D 10.0.0.0/8 [90/2195456] via 172.16.10.2, 00:27:06,Serial0/0
First, the D means Dual, and it’s an EIGRP injected route and the route used by EIGRP to forward traffic to the 10.0.0.0 network via its neighbor, 172.16.10.2. But that’s not what I want to focus on right now. See the [90/2195456] entry in the line? The first number (90) is the administrative distance (AD), which is not to be confused with advertised distance (AD), which is why a lot of people call it the reported distance! The second number, is the feasible distance (FD), or the entire cost for this router to get to network 10.0.0.0. To sum this up, the neighbor router sends a reported, or advertised, distance (RD/AD) for network 10.0.0.0, and EIGRP calculates the cost to get to that neighbor and then adds those two numbers together to get the FD, or total cost.

Neighbor table Each router keeps state information about adjacent neighbors. When a newly discovered neighbor is found, its address and interface are recorded and the information is held in the neighbor table, stored in RAM. Sequence numbers are used to match acknowledgments with update packets. The last sequence number received from the neighbor is recorded so that out-of-order packets can be detected. We’ll get into this more, later in the chapter, when we look at the neighbor table and find out how it’s useful for troubleshooting links between neighbor routers.

Topology table The topology table is populated by the neighbor table and the Diffusing Update Algorithm (DUAL) calculates the best loop-free path to each remote network. It contains all destinations advertised by neighboring routers, holding each destination address and a list of neighbors that have advertised the destination. For each neighbor, the advertised metric (distance), which comes only from the neighbor’s routing table, is recorded, as well as the FD. The best path to each remote network is copied and placed in the routing table and then IP will use this route to forward traffic to the remote network. The path copied to the routing table is called a successor router—think “successful” to help you remember. The path with a good, but less desirable, cost will be entered in the topology table as a backup link and called the feasible successor.

Feasible successor (FS) So a feasible successor is basically an entry in the topology table that represents a path that’s inferior to the successor route(s). An FS is defined as a path whose advertised distance is less than the feasible distance of the current successor and considered a backup route. EIGRP will keep up to 32 feasible successors in the topology table in 15.0 code but only up to 16 in previous IOS versions, which is still a lot! Only the path with the best metric—the successor—is copied and placed in the routing table. The show ip eigrp topology command will display all the EIGRP feasible successor routes known to the router.
Successor A successor route—again, think “successful”—is the best route to a remote network. A successor route is the lowest cost to a destination and stored in the topology table along with everything else. However, this particular best route is copied and placed in the routing table so IP can use it to get to the remote network. The successor route is backed up by a feasible successor route, which is also stored in the topology table, if there’s one available. The routing table contains only successor routes; the topology table contains successor and feasible successor routes. illustrates that the SF and NY routers each have subnets of the 10.0.0.0 network and the Corp router has two paths to get to this network.

There are two paths to network 10.0.0.0 that can be used by the Corp router. EIGRP picks the best path and places it in the routing table, but if both links have equal-cost paths, EIGRP would load- balance between them—up to four links, by default. By using the successor, and having feasible successors in the topology table as backup links, the network can converge instantly and updates to any neighbor make up the only traffic sent from EIGRP—very clean!

Reliable Transport Protocol (RTP)

EIGRP depends on a proprietary protocol, called Reliable Transport Protocol (RTP), to manage the communication of messages between EIGRP-speaking routers. As the name suggests, reliability is a key concern of this protocol, so Cisco designed this mechanism, which leverages multi-casts and uni-casts, to ensure that updates are delivered quickly and that data reception is tracked accurately.

But how does this really work? Well, when EIGRP sends multicast traffic, it uses the Class D address 224.0.0.10, and each EIGRP router knows who its neighbors are. For each multicast it sends out, a list is built and maintained that includes all the neighbors who have replied. If a router doesn’t get a reply from a neighbor via the multicast, EIGRP will then try using uni-casts to resend the same data. If there’s no reply from a neighbor after 16 uni-cast attempts, that neighbor will then be declared dead. This process is often referred to as reliable multicast.

Routers keep track of the information they send by assigning a sequence number to each packet that enables them to identify old, redundant information and data that’s out of sequence. You’ll get to actually see this information in the neighbor table coming up when we get into configuring EIGRP.

Remember, EIGRP is all about topology changes and updates, making it the quiet, performance-optimizing protocol it is. Its ability to synchronize routing databases at startup time, while maintaining the consistency of databases over time, is achieved quietly by communicating only necessary changes. The downside here is that you can end up with a corrupted routing database if any packets have been permanently lost or if packets have been mishandled out of order!

Here’s a description of the five different types of packets used by EIGRP:
Update An Update packet contains route information. When these are sent in response to metric or topology changes, they use reliable multi-casts. In the event that only one router needs an update, like when a new neighbor is discovered, it’s sent via uni-casts. Keep in mind that the uni-cast method still requires an acknowledgment, so updates are always reliable regardless of their underlying delivery mechanism.
Query A Query packet is a request for specific routes and always uses the reliable multicast method. Routers send queries when they realize they’ve lost the path to a particular network and are searching for alternatives.
Reply A Reply packet is sent in response to a query via the uni-cast method. Replies either include a specific route to the queried destination or declare that there’s no known route.
Hello A Hello packet is used to discover EIGRP neighbors and is sent via unreliable multicast, meaning it doesn’t require an acknowledgment.
ACK An ACK packet is sent in response to an update and is always uni-cast. ACKs are never sent reliably because this would require another ACK sent for acknowledgment, which would just create a ton of useless traffic!
It’s helpful to think of all these different packet types like envelopes. They’re really just types of containers that EIGRP routers use to communicate with their neighbors. What’s really interesting is the actual content envelopes these communications and the procedures that guide their conversations, and that’s what we’ll be exploring next!

Diffusing Update Algorithm (DUAL)

I mentioned that EIGRP uses Diffusing Update Algorithm (DUAL) for selecting and maintaining the best path to each remote network. DUAL allows EIGRP to carry out these vital tasks:

Figure out a backup route if there’s one available. Support variable length subnet masks (VLSMs). Perform dynamic route recoveries.

Query neighbors for unknown alternate routes. Send out queries for an alternate route.
Quite an impressive list, but what really makes DUAL so great is that it enables EIGRP to converge amazingly fast! The key to the speed is twofold: First, EIGRP routers maintain a copy of all of their neighbors’ routes to refer to for calculating their own cost to each remote network. So if the best path goes down, all it often takes to find another one is a quick scan of the topology table looking for a feasible successor. Second, if that quick table survey doesn’t work out, EIGRP routers immediately ask their neighbors for help finding the best path. It’s exactly this, ahem, DUAL strategy of reliance upon, and the leveraging of, other routers’ information that accounts for the algorithm’s “diffusing” character.
Unlike other routing protocols where the change is propagated through the entire network, EIGRP bounded updates are propagated only as far as needed. Three critical conditions must be met for DUAL to work properly: Neighbors are discovered or noted as dead within a finite time. All transmitted messages are received correctly. All changes and messages are processed in the order in which they’re detected. As you already know, the Hello protocol ensures the rapid detection of new or dead neighbors, and RTP provides a reliable method of conveying and sequencing messages. Based upon this solid foundation, DUAL can then select and maintain information about the best paths. Let’s check further into the process of route discovery and maintenance next.

Route Discovery and Maintenance

The hybrid nature of EIGRP is fully revealed in its approach to route discovery and maintenance. Like many link-state protocols, EIGRP supports the concept of neighbors that are formally discovered via a Hello process and whose state is monitored thereafter. And like many distance- vector protocols, EIGRP uses the routing-by-rumor approach, which implies that many routers within an AS never actually hear about a route update firsthand. Instead, these devices rely on “network gossip” to hear about neighbors and their respective status via another router that may have also gotten the info from yet another router and so on.

Given all of the information that EIGRP routers have to collect, it follows that they must have a place to store it, and they do this in the tables I referred to earlier in this chapter. As you know, EIGRP doesn’t depend on just one table—it actually uses three of them to store important information about its environment:

Neighbor table Contains information about the specific routers with whom neighbor relationships have been formed. It also displays information about the Hello transmit interval and queue counts for unaccounted Hello acknowledgment.

Topology table Stores the route advertisements received from each neighbor. All routes in the AS are stored in the topology table, both successors and feasible successors.

Route table Stores the routes that are currently in use to make local routing decisions. Anything in the routing table is considered a successor route.

We’ll explore more of EIGRP’s features in greater detail soon, beginning with a look at the metrics associated with particular routes. After that, I’ll cover the decision-making process that’s used to select the best routes, and then we’ll review the procedures followed when routes change.

Configuring EIGRP

I know what you’re thinking! “We’re going to jump in to configuring EIGRP already when I’ve heard how complex it is?” No worries here— what I’m about to show is basic, and I know you won’t have a problem with it at all! We’re going to start with the easy part of EIGRP, and by configuring it on our little internetwork, you’ll learn a lot more this way than you would if I just continued explaining more at this point. After we’ve completed the initial configuration, we’ll fine-tune it and have fun experimenting with it throughout this chapter!

Okay, there are two modes for entering EIGRP commands: router configuration mode and interface configuration mode. In router configuration mode, we’ll enable the protocol, determine which networks will run EIGRP, and set global factors. When in interface configuration mode, we’ll customize summaries and bandwidth.

To initiate an EIGRP session on a router, I’ll use the router eigrp command followed by our network’s AS number. After that, we’ll enter the specific numbers of the networks that we want to connect to the router using the network command followed by the network number. This is pretty straightforward stuff—if you can configure RIP, then you can configure EIGRP! 

Just so you know, we’ll use the same network I used in the previous CCENT routing chapters, but I’m going to connect more networks so we can look deeper into EIGRP. With that, I’m going to enable EIGRP for autonomous system 20 on our Corp router connected to four networks.

The network we’ll be configuring throughout this chapter and the next chapter. Here’s the Corp configuration:

Configuring our little internetwork with EIGRP

Corp#config t Corp(config)#router eigrp 20

Corp(config-router)#network 172.16.0.0

Corp(config-router)#network 10.0.0.0

Remember, just as we would when configuring RIP, we need to use the classful network address, which is all subnet and host bits turned off. This is another thing that makes EIGRP so great: it has the complexity of a link-state protocol running in the background and the same easy configuration process used for RIP!

But wait, the EIGRP configuration can’t be that easy, can it? A few simple EIGRP commands and my network just works? Well, it can be and usually is, but not always. Remember the wildcards you learned about in your access list configurations in your preparation for the Cisco exam?

Let’s say, for example, that we wanted to advertise all the directly connected networks with EIGRP off the Corp router. By using the command network 10.0.0.0, we can effectively advertise to all subnets within that classful network; however, take a look at this configuration now:

Corp#config t

Corp(config)#router eigrp 20

Corp(config-router)#network 10.10.11.0 0.0.0.255

Corp(config-router)#network 172.16.10.0 0.0.0.3

Corp(config-router)#network 172.16.10.4 0.0.0.3

This configuration should look pretty familiar to you because by now you should have a solid understanding of how wildcards are configured. This configuration will advertise the network connected to g0/1 on the Corp router as well as the two WAN links. Still, all we accomplished with this configuration was to stop the g0/0 interface from being placed into the EIGRP process, and unless you have tens of thousands of networks worldwide, then there is really no need to use wildcards because they
don’t provide any other administrative purpose other than what I’ve already described.
Now let’s take a look at the simple configuration needed for the SF and NY routers in our internetwork:
SF(config)#router eigrp 20
SF(config-router)#network 172.16.0.0
SF(config-router)#network 10.0.0.0
000060:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor
172.16.10.1 (Serial0/0/0) is up:
new adjacency
NY(config)#router eigrp 20
NY(config-router)#network 172.16.0.0
NY(config-router)#network 10.0.0.0
*Jun 26 02:41:36:%DUAL-5-NBRCHANGE:IP
EIGRP(0) 20:Neighbor
172.16.10.5 (Serial0/0/1) is up: new adjacency Nice and easy—or is it? We can see that the SF and NY router created an adjacency to the Corp router, but are they actually sharing routing information? To find out, let’s take a look at the number that I pointed out as the autonomous system (AS) number in the configuration.
EIGRP uses ASs to identify the group of routers that will share route information. Only routers that have the same AS share routes. The range of values we can use to create an AS with EIGRP is 1–65535:
Corp(config)#router eigrp ?
<1-65535>      Autonomous System
WORD EIGRP Virtual-Instance Name
Corp(config)#router eigrp 20

Notice that I could have used any number from 1 to 65,535, but I chose to use 20 because it just felt good at the time. As long as all routers use the same number, they’ll create an adjacency. Okay, now the AS makes sense, but it looks like I can type a word in the place of the AS number, and I can! Let’s take a look at the configuration:
Corp(config)#router eigrp Todd
Corp(config-router)#address-family ipv4
autonomous-system 20
Corp(config-router-af)#network 10.0.0.0
Corp(config-router-af)#network 172.16.0.0
What I just showed you is not part of the Cisco exam objectives, but it’s also not really necessary for any IPv4 routing configuration in your network. The previous configuration examples I’ve gone through so far in this chapter covers the objectives and work just fine, but I included this last configuration example because it’s now an option in IOS 15.0 code.

VLSM Support and Summarization

Being one of the more sophisticated classless routing protocols, EIGRP supports using variable length subnet masks. This is good because it allows us to conserve address space by using subnet masks that map to specific host requirements in a much better way. Being able to use 30-bit subnet masks for the point-to-point networks that I configured in our internetwork is a great example. Plus, because the subnet mask is propagated with every route update, EIGRP also supports the use of dis-contiguous subnets, giving us greater administrative flexibility when designing a network IP address scheme. Another versatile feature is that EIGRP allows us to use and place route summaries at strategically optimal locations throughout the EIGRP network to reduce the size of the routing table. Keep in mind that EIGRP automatically summarizes networks at their classful boundaries and supports the manual creation of summaries at any and all EIGRP routers. This is usually a good thing, but by checking out the routing table in the Corp router, you can see the possible complications that auto-summarization can cause:

Corp#sh ip route

[output cut]

172.16.0.0/16 is variably subnetted, 3 subnets, 2

masks 

C   172.16.10.4/30 is directly connected,

Serial0/1

C     172.16.10.0/30 is directly connected,

Serial0/0 

D      172.16.0.0/16 is a summary,

00:01:37, Null0

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks

C      10.10.10.0/24 is directly connected,

GigabitEthernet0/0 D    10.0.0.0/8 is a summary,

00:01:19, Null0

C      10.10.11.0/24 is directly connected,

GigabitEthernet0/1

Now this just doesn’t look so good—both 172.16.0.0 and 10.0.0.0/8 are being advertised as summary routes injected by EIGRP, but we have multiple subnets in the 10.0.0.0/8 classful network address, so how would the Corp router know how to route to a specific network like 10.10.20.0? 

The networks we’re using make up what is considered a discontinuous network because we have the 10.0.0.0/8 network subnetted across a different class of address, the 172.16.0.0 network, with 10.0.0.0/8 subnets on both sides of the WAN links.

You can see that the SF and NY routers will both create an automatic summary of 10.0.0.0/8 and then inject it into their routing tables. This is a common problem, and an important one that Cisco really wants you to understand (by including it in the objectives)! With this type of topology, disabling automatic summarization is definitely the better option.

Actually, it’s the only option if we want this network to work.

Let’s take a look at the routing tables on the NY and SF routers to find out what they’re seeing:

SF>sh ip route

[output cut]

172.16.0.0/16 is variably subnetted, 3 subnets, 3

masks 

C   172.16.10.0/30 is directly connected,

Serial0/0/0

D     172.16.10.0/24 [90/2681856] via

172.16.10.1, 00:54:58,

Serial0/0/0

D      172.16.0.0/16 is a summary, 00:55:12,

Null0 10.0.0.0/8 is variably subnetted, 3 subnets, 2

masks

D        10.0.0.0/8 is a summary, 00:54:58, Null

C         10.10.20.0/24 is directly connected,

FastEthernet0/0 

C          10.10.30.0/24 is directly

connected, Loopback 0

SF>

NY>sh ip route

[output cut]

172.16.0.0/16 is variably subnetted, 2 subnets, 2

masks 

C   172.16.10.4/30 is directly connected,

Serial0/0/1

D    172.16.0.0/16 is a summary, 00:55:56,

Null0 10.0.0.0/8 is variably subnetted, 3 subnets, 2

masks

D       10.0.0.0/8 is a summary, 00:55:26, Null0

C        10.10.40.0/24 is directly connected,

FastEthernet0/0 

C         10.10.50.0/24 is directly

connected, Loopback0 NY>ping 10.10.10.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5) NY>

The confirmed answer is that our network isn’t working because we’re dis-contiguous and our classful boundaries are auto-summarizing. We can see that EIGRP is injecting summary routes into both the SF and NY routing tables.

We need to advertise our subnets in order to make this work, and here’s how we make that happen, starting with the Corp router:

Corp#config t

Corp(config)#router eigrp 20 Corp(config

router)#no auto-summary Corp(config-router)#

*Feb 25 18:29:30%DUAL-5-NBRCHANGE:IP

EIGRP(0) 20:Neighbor 172.16.10.6 (Serial0/1)

is resync: summary configured

*Feb 25 18:29:30%DUAL-5-NBRCHANGE:IP

EIGRP(0) 20:Neighbor 172.16.10.2 (Serial0/0)

is resync: summary configured Corp(config-router)#

Okay—our network still isn’t working because the other routers are still sending a summary. So let’s configure the SF and NY routers to advertise subnets:

SF#config t

SF(config)#router eigrp 20 SF(config-router)#no

auto-summary SF(config-router)#

000090:%DUAL-5-NBRCHANGE:IP-EIGRP(0)

20:Neighbor 172.16.10.1

(Serial0/0/0) is resync: summary configured

NY#config t

NY(config)#router eigrp 20 NY(config-router)#no

auto-summary NY(config-router)#

*Jun 26 21:31:08%DUAL-5-NBRCHANGE:IP

EIGRP(0) 20:Neighbor

172.16.10.5 (Serial0/0/1)

is resync: summary configured

Let’s take a look at the Corp router’s output now:

Corp(config-router)#do show ip route

[output cut]

172.16.0.0/30 is subnetted, 2 subnets

C      172.16.10.4 is directly connected, Serial0/1 C

172.16.10.0 is directly connected, Serial0/0

10.0.0.0/24 is subnetted, 6 subnets

C      10.10.10.0 is directly connected,

GigabitEthernet0/0 C      10.10.11.0 is directly

connected, GigabitEthernet0/1 D 10.10.20.0

[90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

D       10.10.30.0 [90/3200000] via 172.16.10.2, 00:00:27,

Serial0/0

 10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:29,

Serial0/1

D  10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:30,

Serial0/1

Corp# ping 10.10.20.1

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.20.1, timeout is 2 seconds:

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Wow, what a difference compared to the previous routing table output! We can see all the subnets now. It would be hard to justify using auto- summarization today. If you want to summarize, it should definitely be done manually. Always typing in no auto-summary under RIPv2 and EIGRP is common practice today.

Controlling EIGRP Traffic

But what if you need to stop EIGRP from working on a specific interface? Maybe it’s a connection to your ISP, or where we didn’t want to have the g0/0 interface be part of the EIGRP process as in our earlier example. All you need to do is to flag the interface as passive, and to do this from an EIGRP session, just use this command: passive-interface interface-type interface-number This works because the interface-type portion defines the type of interface and the interface-number portion defines the number of the interface. The following command makes interface serial 0/0 into a passive interface:
Corp(config)#router eigrp 20
Corp(config-router)#passive-interface g0/0
What we’ve accomplished here is to prevent this interface from sending or reading received Hello packets so that it will no longer form adjacencies or send or receive route information. But this still won’t stop EIGRP from advertising the subnet of this interface out all other interfaces without using wildcards. This really illustrates the reason you must understand why and when to use wildcards as well as what the passive-interface command does. This knowledge really helps you to make an informed decision on which command you need to use to meet your specific business requirements!

Typically, EIGRP neighbors use multicast to exchange routing updates. You can change this by specifically telling the router about a particular neighbor, which will ensure that uni-cast packets will only be used for the routing updates with that specific neighbor. To take advantage of this feature, apply the neighbor command and execute it under the EIGRP process.
I’m going to configure the Corp router with information about routers SF and NY:
Corp(config)#router eigrp 20
Corp(config-router)#neighbor 172.16.10.2
Corp(config-router)#neighbor 172.16.10.6

Understand that you don’t need to use the preceding commands to create neighbor relationships, but they’re available if you need them.

EIGRPMetrics

Unlike many other protocols that use a single element to compare routes and select the best possible path, EIGRP uses a combination of these four factors:
Bandwidth Delay Load Reliability

It’s worth noting that there’s a fifth element, maximum transmission unit (MTU), which has never been used in EIGRP metrics calculations though it’s still a required parameter in some EIGRP-related commands— especially those involving redistribution. The value of the MTU element represents the smallest MTU value encountered along the path to the destination network.
Also good to know is that there’s a mathematical formula that combines the four main elements to create a single value representing just how good a given route actually is. The higher the metric associated with it, the less desirable the route. Here’s that formula:
The formula’s components break down like this:  By default, K1 = 1, K2 = 0, K3 = 1, K4 = 0, K5 = 0.
Delay equals the sum of all the delays of the links along the path.

Delay = [Delay in 10s of microseconds] × 256.

Bandwidth is the lowest bandwidth of the links along the path.

Bandwidth = [10000000 / (bandwidth in Kbps)] × 256.

By default, metric = lowest bandwidth along path + sum of all delays along path.

If necessary, you can adjust the constant K values on a per-interface basis, but I would recommend that you only do this under the direction of the Cisco Technical Assistance Center (TAC). Metrics are tuned to change the manner in which routes are calculated. The K values can be seen with a show ip protocols output:
Corp#sh ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0

Notice that that the K1 and K3 values are enabled by default—for example, K1 =  the relationship between each constant and the metric it affects.
Each constant is used to assign a weight to a specific variable, meaning that when the metric is calculated, the algorithm will assign a greater importance to the specified metric. This is very cool because it means that by assigning a weight, you get to specify the factor that’s most important to you. For example, if bandwidth is your priority, you would assign K1 to weight it accordingly, but if delay is totally unacceptable, then K3 would be assigned a greater weight. A word of caution though: Always remember that any changes to the default values could result in  instability and convergence problems, particularly if delay or reliability values are constantly changing! But if you’re looking for something to do on a rainy Saturday, it’s an interesting experiment to pass some time and gain some nice networking insight!


Constant
Metric
K1
Bandwidth (Be)
K2
Load (utilization on path)
K3
Delay (Dc)
K4
Reliability (r)
K5
MTU

Maximum Paths and Hop Count

By default, EIGRP can provide equal-cost load balancing across up to 4 links. RIP and OSPF do this too. But you can have EIGRP actually load- balance across up to 32 links with 15.0 code (equal or unequal) by using the following command:
orp(config)#router eigrp 10
Corp(config-router)#maximum-paths ?
<1-32>      Number of paths

As I mentioned, pre–15.0 code routers allowed up to 16 paths to remote networks, which is still a lot!
EIGRP has a default maximum hop count of 100 for route update packets, but it can be set up to 255. Chances are you wouldn’t want to ever change this, but if you did, here is how you would do it:
Corp(config)#router eigrp 10
Corp(config-router)#metric maximum-hops ?
<1-255>      Hop count

As you can see from this router output, EIGRP can be set to a maximum of 255 hops. Even though it doesn’t use hop count in the path metric calculation, it still uses the maximum hop count to limit the scope of the AS.

Route Selection

Now that you’ve got a good idea how EIGRP works and also how easy it actually is to configure, it’s probably clear that determining the best path simply comes down to seeing which one gets awarded the lowest metric. But it’s not the winning path that really sets EIGRP apart from other protocols. You know that EIGRP stores route information from its neighbors in its topology table and that as long as a given neighbor remains alive, it will rarely throw out anything it has learned from that neighbor. This makes EIGRP able to flag the best routes in its topology table for positioning in its local routing table, enabling it to flag the next- best routes as alternatives if the best route goes down.  you can see that I added another Fast Ethernet link between the SF and NY routers. This will give us a great opportunity to play with the topology and routing tables!
EIGRP route selection process
First, let’s take another look at the routing table on the Corp router before I bring up the new interfaces:
172.16.0.0/30 is subnetted, 2 subnets
C  172.16.10.4 is directly connected, Serial0/1 
C 172.16.10.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 6 subnets
C 10.10.10.0 is directly connected, GigabitEthernet0/0 
C 10.10.11.0 is directly connected, GigabitEthernet0/1 
D 10.10.20.0 [90/3200000] via 172.16.10.2, 00:00:27,
Serial0/0
D                10.10.30.0 [90/3200000] via 172.16.10.2, 00:00:27,
Serial0/0
D                10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:29,
Serial0/1
D                10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:30,
Serial0/1

We can see the three directly connected interfaces as well as the other four networks injected into the routing table by EIGRP. Now I’ll add the network 192.168.10.0/24 between the SF and NY routers, then enable the interfaces. And let’s check out the routing table of the Corp router now that I’ve configured that link:
D     192.168.10.0/24 [90/2172416] via 172.16.10.6, 00:04:27,
Serial0/1
172.16.0.0/30 is subnetted, 2 subnets
C                172.16.10.4 is directly connected, Serial0/1 
C 172.16.10.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 6 subnets
C      10.10.10.0 is directly connected, GigabitEthernet0/0 
C      10.10.11.0 is directly connected, GigabitEthernet0/1 
D 10.10.20.0 [90/3200000] via 172.16.10.2, 00:00:27,
Serial0/0
D                10.10.30.0 [90/3200000] via 172.16.10.2, 00:00:27,
Serial0/0
D                10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:29,
Serial0/1
D                10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:30,
Serial0/1

Okay—that’s weird. The only thing different I see is one path to the 192.168.10.0/24 network listed first. Glad it is there, which means that  we can route to that network. Notice that we can reach the network from the Serial0/1 interface, but what happened to my link to the SF router— shouldn’t we have an advertisement from that router and be load- balancing? Let’s take a look the topology table to find out what’s going on:
Corp#sh ip eigrp topology
IP-EIGRP Topology Table for AS(20)/ID(10.10.11.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

P 10.10.10.0/24, 1 successors, FD is 128256 via Connected, GigbitEthernet0/0
P 10.10.11.0/24, 1 successors, FD is 128256 via Connected, GigbitEthernet0/1
P 10.10.20.0/24, 1 successors, FD is 2300416
via 172.16.10.6 (2300416/156160), Serial0/1 via 172.16.10.2 (3200000/128256), Serial0/0
P 10.10.30.0/24, 1 successors, FD is 2300416
via 172.16.10.6 (2300416/156160), Serial0/1 via 172.16.10.2 (3200000/128256), Serial0/0
P 10.10.40.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1



via 172.16.10.2 (3202560/156160), Serial0/0
P 10.10.50.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (3202560/156160), Serial0/0
P 192.168.10.0/24, 1 successors, FD is 2172416  via 172.16.10.6 (2172416/28160), Serial0/1 via 172.16.10.2 (3074560/28160), Serial0/0
P 172.16.10.4/30, 1 successors, FD is 2169856 via Connected, Serial0/1
P 172.16.10.0/30, 1 successors, FD is 3072000 via Connected, Serial0/0

Okay, we can see there are two paths to the 192.168.10.0/24 network, but it’s using the next hop of 172.16.10.6 (NY) because the feasible distance (FD) is less! The advertised distance from both routers is 28160, but the cost to get to each router via the WAN links is not the same. This means the FD is not the same, meaning we’re not load-balancing by default.
Both WAN links are a T1, so this should have load-balanced by default, but EIGRP has determined that it costs more to go through SF than through NY. Since EIGRP uses bandwidth and delay of the line to determine the best path, we can use the show interfaces command to verify our stats like this:
Corp#sh int s0/0
Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: <<Connection to CR1>> Internet address is 172.16.10.1/30
MTU 1500 bytes, BW 1000 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set Keepalive set (10 sec)

Corp#sh int s0/1
Serial0/1 is up, line protocol is up Hardware is PowerQUICC Serial Internet address is 172.16.10.5/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set Keepalive set (10 sec)
I highlighted the statistics that EIGRP uses to determine the metrics to a next-hop router: MTU, bandwidth, delay, reliability, and load, with bandwidth and delay enabled by default. We can see that the bandwidth on the Serial0/0 interface is set to 1000 Kbit, which is not the default bandwidth. Serial0/1 is set to the default bandwidth of 1544 Kbit. Let’s set the bandwidth back to the default on the s0/0 interface and we should start load-balancing to the 192.168.10.0 network. I’ll just use the no bandwidth command, which will set it back to its default of 1544 Mbps:
Corp#config t Corp(config)#int s0/0 Corp(config-if)#no bandwidth Corp(config-if)#^Z
Now let’s take a look at the topology table and see if we’re equal.
Corp#sh ip eigrp topo | section 192.168.10.0
P 192.168.10.0/24, 2 successors, FD is 2172416  via 172.16.10.2 (2172416/28160), Serial0/0 via 172.16.10.6 (2172416/28160), Serial0/1
Since the topology tables can get really huge in most networks, the show  ip eigrp topology | section network command comes in handy because it allows us to see information about the network we want to look into in   a couple of lines. Let’s use the show ip route network command and check out what is going on there:
Corp#sh ip route 192.168.10.0
Routing entry for 192.168.10.0/24
Known via "eigrp 20", distance 90, metric 2172416, type internal Redistributing via eigrp 20
Last update from 172.16.10.2 on Serial0/0, 00:05:18 ago Routing Descriptor Blocks:
* 172.16.10.6, from 172.16.10.6, 00:05:18 ago, via Serial0/1
Route metric is 2172416, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 1544

Kbit

Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1

172.16.10.2, from 172.16.10.2, 00:05:18 ago, via Serial0/0
Route metric is 2172416, traffic share count is 1
Total delay is 20100 microseconds, minimum bandwidth is 1544

Kbit
Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1

Lots of detail about our routes to the 192.168.10.0 network! The Corp route has two equal-cost links to the 192.168.10.0 network. And to reveal load balancing even better, we’ll just use the plain, ever useful show ip route command:

Corp#sh ip route
[output cut]
D         192.168.10.0/24 [90/2172416] via 172.16.10.6, 00:05:35,
Serial0/1
[90/2172416] via 172.16.10.2, 00:05:35,
Serial0/0

Now we can see that there are two successor routes to the 192.168.10.0 network. Pretty sweet! But in the routing table, there’s one path to 192.168.20.0 and 192.168.30.0, with the link between the SF and NY routers being feasible successors. And it’s the same with the 192.168.40.0 and 192.168.50.0 networks. Let’s take a look at the topology table to examine this more closely:

Corp#sh ip eigrp topology

IP-EIGRP Topology Table for AS(20)/ID(10.10.11.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

P 10.10.10.0/24, 1 successors, FD is 128256 via Connected, GigabitEthernet0/0
P 10.10.11.0/24, 1 successors, FD is 128256 via Connected, GigabitEthernet0/1
P 10.10.20.0/24, 1 successors, FD is 2297856
via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1
P 10.10.30.0/24, 1 successors, FD is 2297856
via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1
P 10.10.40.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0
P 10.10.50.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0
P 192.168.10.0/24, 2 successors, FD is 2172416  via 172.16.10.2 (2172416/28160), Serial0/0 via 172.16.10.6 (2172416/28160), Serial0/1
P 172.16.10.4/30, 1 successors, FD is 2169856 via Connected, Serial0/1
P 172.16.10.0/30, 1 successors, FD is 2169856 via Connected, Serial0/0

It is nice that we can see that we have a successor and a feasible successor to each network, so we know that EIGRP is doing its job. Let’s take a close look at the links to 10.10.20.0 now and dissect what it’s telling us:

P 10.10.20.0/24, 1 successors, FD is 2297856
via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1

Okay—first, we can see that it’s passive (P), which means that it has found all the usable paths to the network 10.10.20.0 and is happy! If we see active (A), that means that EIGRP is not happy at all and is querying its neighbors for a new path to that network. The (2297856/128256) is the FD/AD, meaning that the SF router is advertising the 10.10.20.0 network as a cost of 128256, which is the AD. The Corp router adds the bandwidth and delay of the line to get to the SF router and then adds that number to the AD (128256) to come up with a total cost (FD) of 2297856 to get to network 10.10.20.0.

Unequal-Cost Load Balancing

As with all routing protocols running on Cisco routers, EIGRP automatically supports load balancing over four equal-cost routes and can be configured to support up to 32 equal-cost paths with IOS 15.0 code. As you know, previous IOS versions supported up to 16. I’ve mentioned this a few times in this chapter already, but I want to show you how to configure unequal-cost load balancing with EIGRP. First let’s take a look at the Corp router by typing in the show ip protocols command:
Corp#sh ip protocols
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 20
EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4
Routing for Networks:

10.0.0.0
172.16.0.0
Routing Information Sources:
Gateway                     Distance                                     Last Update (this router)                                   90                                     19:15:10
172.16.10.6                              90              00:25:38
172.16.10.2                              90              00:25:38

Distance: internal 90 external 170

The variance 1 means equal-path load balancing with the maximum paths set to 4 by default. Unlike most other protocols, EIGRP also supports unequal-cost load balancing through the use of the variance parameter.
To clarify, let’s say the parameter has been set to a variance of 2. This would effectively load-balance traffic across the best route plus any route with a feasible distance of up to twice as large. But still keep in mind that load balancing occurs in proportion with and relative to the cost of the route, meaning that more traffic would travel across the best route than the suboptimal one. Let’s configure the variance on the Corp router and see if we can load- balance across our feasible successors now:
Corp# config t
Corp(config)#router eigrp 20
Corp(config-router)#variance 2
Corp(config-router)#
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.20.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.20.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.30.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.30.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.40.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.40.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.50.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 10.10.50.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 192.168.10.0
*Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 192.168.10.0 Corp(config-router)#do show ip route [output cut]
D         192.168.10.0/24 [90/2172416] via 172.16.10.6, 00:00:18,
Serial0/1
[90/2172416] via 172.16.10.2, 00:00:18,
Serial0/0
172.16.0.0/30 is subnetted, 2 subnets
C      172.16.10.4 is directly connected, Serial0/1 C 172.16.10.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 6 subnets
C      10.10.10.0 is directly connected, GigabitEthernet0/0 
C      10.10.11.0 is directly connected, GigabitEthernet0/1 
D 10.10.20.0 [90/2300416] via 172.16.10.6, 00:00:18,
Serial0/1
[90/2297856] via 172.16.10.2, 00:00:19,
Serial0/0
D                10.10.30.0 [90/2300416] via 172.16.10.6, 00:00:19,
Serial0/1
[90/2297856] via 172.16.10.2, 00:00:19,
Serial0/0
D                10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:19,
Serial0/1
[90/2300416] via 172.16.10.2, 00:00:19,
Serial0/0
D                10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:20,
Serial0/1
[90/2300416] via 172.16.10.2, 00:00:20,
Serial0/0
Corp(config-router)#

Nice—it worked! Now we have two paths to each remote network in the routing table, even though the feasible distances to each route aren’t equal. Don’t forget that unequal load balancing is not enabled by default and that you can perform load balancing through paths that have up to 128 times worse metrics than the successor route!

Split Horizon

Split horizon is enabled on interfaces by default, which means that if a route update is received on an interface from a neighbor router, this interface will not advertise those networks back out to the neighbor router who sent them. Let’s take a look at an interface and then go through an example:
Corp#sh ip int s0/0
Serial0/0 is up, line protocol is up Internet address is 172.16.10.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes
Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.10 Outgoing access list is not set Inbound     access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled
[output cut]
Okay—we can see that split horizon is enabled by default. But what does this really mean? Most of the time it’s more helpful than harmful, but  let’s check out our internetwork in Figure 17.8 so I can really explain what split horizon is doing.
Notice that the SF and NY routers are each advertising their routes to the Corp router. Now, let’s see what the Corp router sends back to each router in Figure 17.9.
Can you see that the Corp router is not advertising back out the advertised networks that it received on each interface? This is saving the SF and NY routers from receiving the incorrect route information that they could possibly get to their own network through the Corp router, which we know is wrong.
So how can this cause a problem? After all, it seems reasonable not to send misinformation back to an originating router, right? You’ll see this create a problem on point-to-multi-point links, such as Frame Relay, when multiple remote routers connect to a single interface at the Corp location. We can use logical interfaces, called sub-interfaces, which I’ll tell you all about in Chapter 21, “Wide Area Networks,” to solve the split horizon issue on a point-to-multi-point interface.

Verifying and Troubleshooting EIGRP
Even though EIGRP usually runs smoothly and is relatively low maintenance, there are several commands you need to memorize for using on a router that can be super helpful when troubleshooting EIGRP! I’ve already shown you a few of them, but I’m going to demonstrate all the tools you’ll need to verify and troubleshoot EIGRP now. Table 17.2 contains all of the commands you need to know for verifying that EIGRP is functioning well and offers a brief description of what each command does.

Command
Description/Function
show ip eigrp neighbors
Shows all EIGRP neighbors, their IP addresses, and the re-transmit interval and queue counts for the adjacent routers
show ip eigrp interfaces
Lists the interfaces on which the router has actually enabled EIGRP
show ip route eigrp
Shows EIGRP entries in the routing table
show ip eigrp topology
Shows entries in the EIGRP topology table
show ip eigrp traffic
Shows the packet count for EIGRP packets sent and received
show ip protocols
Shows information about the active protocol sessions
When troubleshooting an EIGRP problem, it’s always a good idea to start by getting an accurate map of the network, and the best way to do that is by using the show ip eigrp neighbors command to find out who your directly connected neighbors are. This command shows all adjacent routers that share route information within a given AS. If neighbors are missing, check the configuration, AS number, and link status on both routers to verify that the protocol has been configured correctly.

Let’s execute the command on the Corp router:
Corp#sh ip eigrp neighbors
IP-EIGRP neighbors for process 20

H   Address
Interface
Hold Uptime
SRTT
RTO  Q  Seq





(sec)
(ms)
Cnt Num



1   172.16.10.2
Se0/0
11 03:54:25
1
200  0  127



0   172.16.10.6
Se0/1
11 04:14:47
1
200  0  2010




Here’s a breakdown of the important information we can see in the preceding output:
H indicates the order in which the neighbor was discovered. Hold time in seconds is how long this router will wait for a Hello packet to arrive from a specific neighbor. The Uptime value indicates how long the neighbor relationship has been established. The SRTT field is the smooth round-trip timer and represents how long it takes to complete a round-trip from this router to its neighbor and back. This value delimits how long to wait after a multicast for a reply from this neighbor. As mentioned earlier, the router will attempt to establish communication via unicasts if it doesn’t receive a reply. The time between multicast attempts is specified by the Re-transmission Time Out (RTO) field, which is based upon the SRTT values. The Q value tells us if there are any outstanding messages in the queue. We can make a mental note that there’s a problem if we see consistently large values here! Finally, the Seq field shows the sequence number of the last update from that neighbor, which is used to maintain synchronization and avoid duplicate messages or their out-of-sequence processing. The neighbors command is a great command, but we can get local status of our router by also using the show ip eigrp interface command like this:

Corp#sh ip eigrp interfaces
IP-EIGRP interfaces for process 20

Xmit Queue       Mean      Pacing Time                    Multicast
Pending
Interface Peers          Un/Reliable                       SRTT                   Un/Reliable              Flow Timer        Routes
Gi0/0                                 0                  0/0                     0                0/1                                            0
0
Se0/1                                 1                   0/0                     1                 0/15                                            50
0
Se0/0                                 1                   0/0                     1                 0/15                                            50
0
Gi0/1                                 0                  0/0                     0                0/1                                            0
0

Corp#sh ip eigrp interface detail s0/0
IP-EIGRP interfaces for process 20

Xmit Queue       Mean      Pacing Time                    Multicast
Pending
Interface Peers          Un/Reliable                       SRTT                   Un/Reliable              Flow Timer        Routes
Se0/0                                 1                   0/0                     1                 0/15                                            50
0
Hello interval is 5 sec Next xmit serial <none>
Un/reliable mcasts: 0/0    Un/reliable ucasts: 21/26 Mcast exceptions: 0         CR packets: 0                                                ACKs suppressed: 9
Retransmissions sent: 0            Out-of-sequence rcvd: 0 Authentication mode is not set

The first command, show ip eigrp interfaces, lists all interfaces for which EIGRP is enabled as well as those the router is currently sending Hello messages to in an attempt to find new EIGRP neighbors. The show ip eigrp interface detail interface command lists more details per interface, including the local router’s own Hello interval. Understand that you can use these commands to verify that all your interfaces are within the AS process used by EIGRP, but also note that the passive interfaces won’t show up in these outputs. So be sure to also check to see if an interface has been configured as passive if is not present in the outputs.
Okay, if all neighbors are present, then verify the routes learned. By executing the show ip route eigrp command, you’re given a quick picture of the routes in the routing table. If a certain route doesn’t appear in the routing table, you need to verify its source. If the source is functioning properly, then check the topology table.

The routing table according to Corp looks like this:
D         192.168.10.0/24 [90/2172416] via 172.16.10.6, 02:29:09,
Serial0/1
[90/2172416] via 172.16.10.2, 02:29:09,
Serial0/0
172.16.0.0/30 is subnetted, 2 subnets
C                172.16.10.4 is directly connected, Serial0/1 
C 172.16.10.0 is directly connected, Serial0/0
10.0.0.0/24 is subnetted, 6 subnets
C                10.10.10.0 is directly connected, Loopback0 
C         10.10.11.0 is directly connected, Loopback1
D                10.10.20.0 [90/2300416] via 172.16.10.6, 02:29:09,
Serial0/1
[90/2297856] via 172.16.10.2, 02:29:10,
Serial0/0
D                10.10.30.0 [90/2300416] via 172.16.10.6, 02:29:10,
Serial0/1
[90/2297856] via 172.16.10.2, 02:29:10,
Serial0/0
D                10.10.40.0 [90/2297856] via 172.16.10.6, 02:29:10,
Serial0/1
[90/2300416] via 172.16.10.2, 02:29:10,
Serial0/0
D                10.10.50.0 [90/2297856] via 172.16.10.6, 02:29:11,
Serial0/1
[90/2300416] via 172.16.10.2, 02:29:11,
Serial0/0

You can see here that most EIGRP routes are referenced with a D and that their administrative distance is 90. Remember that the [90/2300416] represents AD/FD, and in the preceding output, EIGRP is performing equal- and unequal-cost load balancing between two links to our remote networks.
We can see this by looking closer at two different networks. Pay special attention to the FD of each output:
Corp#sh ip route | section 192.168.10.0
D         192.168.10.0/24 [90/2172416] via 172.16.10.6, 01:15:44,
Serial0/1
[90/2172416] via 172.16.10.2, 01:15:44,
Serial0/0


The preceding output shows equal-cost load balancing, and here’s our unequal-cost load balancing in action:
Corp#sh ip route | section 10.10.50.0
D                10.10.50.0 [90/2297856] via 172.16.10.6, 01:16:16,
Serial0/1
[90/2300416] via 172.16.10.2, 01:16:16,
Serial0/0
We can get the topology table displayed for us via the show ip eigrp topology command. If the route is in the topology table but not in the routing table, it’s a pretty safe assumption that there’s a problem between the topology database and the routing table. After all, there must be a good reason the topology database isn’t adding the route into the routing table, right? We discussed this issue in detail earlier in the chapter, and it’s oh so important!
Corp’s topology table looks like this:
P 10.10.10.0/24, 1 successors, FD is 128256 via Connected, GigabitEthernet0/0
P 10.10.11.0/24, 1 successors, FD is 128256 via Connected, GigabitEthernet0/1
P 10.10.20.0/24, 1 successors, FD is 2297856
via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1
P 10.10.30.0/24, 1 successors, FD is 2297856
via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1
P 10.10.40.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0
P 10.10.50.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0
P 192.168.10.0/24, 2 successors, FD is 2172416  via 172.16.10.2 (2172416/28160), Serial0/0 via 172.16.10.6 (2172416/28160), Serial0/1
P 172.16.10.4/30, 1 successors, FD is 2169856 via Connected, Serial0/1
P 172.16.10.0/30, 1 successors, FD is 2169856 via Connected, Serial0/0
Notice that every route in this output is preceded by a P, which shows that these routes are in a passive state. This is good because routes in the active state indicate that the router has lost its path to this network and is searching for a replacement. Each entry also reveals the feasible distance, or FD, to each remote network as well as the next-hop neighbor through which packets will travel to this destination. Each entry also has two numbers in brackets, with the first indicating the feasible distance and the second, the advertised distance to a remote network. Again, here’s our equal- and unequal-cost load-balancing output shown in the topology table:
Corp#sh ip eigrp top | section 192.168.10.0
P 192.168.10.0/24, 2 successors, FD is 2172416  via 172.16.10.2 (2172416/28160), Serial0/0 via 172.16.10.6 (2172416/28160), Serial0/1
The preceding output shows equal-cost load
balancing, and here is our unequal-cost load
balancing in action:
Corp#sh ip eigrp top | section 10.10.50.0
P 10.10.50.0/24, 1 successors, FD is 2297856
via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0

The command show ip eigrp traffic enables us to see if updates are being sent. If the counters for EIGRP input and output packets don’t increase, it means that no EIGRP information is being sent between peers. The following output indicates that the Corp router is experiencing normal traffic:
Corp#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process
200 Hellos sent/received: 2208/2310
Updates sent/received: 184/183 Queries sent/received: 17/4 Replies sent/received: 4/18 Acks sent/received: 62/65
Input queue high water mark 2, 0 drops
All of the packet types I talked about in the section on RTP are represented in the output of this command. And we can’t forget the always useful troubleshooting command show ip protocols. Here’s the output the Corp router gives us after using it:
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100 EIGRP maximum metric variance 2 Redistributing: eigrp 20
EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4
Routing for Networks: 10.0.0.0
172.16.0.0
Routing Information Sources:
Gateway                     Distance                                     Last Update (this router)                                      90                                     04:23:51
172.16.10.6                              90              02:30:48
172.16.10.2                              90              02:30:48
Distance: internal 90 external 170

In this output, we can see that EIGRP is enabled for autonomous system 20 and that the K values are set to their defaults. The variance is 2, so both equal- and unequal-cost load balancing is happening here.
Automatic summarization has been turned off. We can also see that EIGRP is advertising two classful networks and that it sees two neighbors.
The show ip eigrp events command displays a log of every EIGRP event: when routes are injected and removed from the routing table and when EIGRP adjacencies are reset or fail. This information is so helpful in determining if there are routing instabilities in the network! Be advised that this command can result in quite a flood of information even for really simple configurations like ours. To demonstrate, here’s the output the Corp router divulged after I used it:
Corp#show ip eigrp events
Event information for AS 20:
1
22:24:24.258
Metric set: 172.16.10.0/30 2169856
2
22:24:24.258
FC sat rdbmet/succmet: 2169856 0
3
22:24:24.258
FC sat nh/ndbmet: 0.0.0.0 2169856
4
22:24:24.258
Find FS: 172.16.10.0/30 2169856
5
22:24:24.258
Metric set: 172.16.10.4/30 2169856
6
22:24:24.258
FC sat rdbmet/succmet: 2169856 0
7
22:24:24.258
FC sat nh/ndbmet: 0.0.0.0 2169856
8
22:24:24.258
Find FS: 172.16.10.4/30 2169856
9
22:24:24.258
Metric set: 192.168.10.0/24 2172416
10
22:24:24.258
Route install: 192.168.10.0/24 172.16.10.2
11
22:24:24.258
Route install: 192.168.10.0/24 172.16.10.6
12
22:24:24.254
FC sat rdbmet/succmet: 2172416 28160
13
22:24:24.254
FC sat nh/ndbmet: 172.16.10.6 2172416

14       22:24:24.254 Find FS: 192.168.10.0/24 2172416
15        22:24:24.254 Metric set: 10.10.50.0/24 2297856
16       22:24:24.254 Route install: 10.10.50.0/24 172.16.10.6
17        22:24:24.254 FC sat rdbmet/succmet: 2297856 128256
18       22:24:24.254 FC sat nh/ndbmet: 172.16.10.6 2297856
19       22:24:24.254 Find FS: 10.10.50.0/24 2297856
20       22:24:24.254 Metric set: 10.10.40.0/24 2297856
21       22:24:24.254 Route install: 10.10.40.0/24 172.16.10.6
22       22:24:24.250 FC sat rdbmet/succmet: 2297856 128256
--More--

Troubleshooting Example with EIGRP

Throughout this chapter I’ve covered many of the problems that commonly occur with EIGRP and how to verify and troubleshoot these issues. Make sure you clearly understand what I have shown you so far in this chapter so you’re prepared to answer any question the Cisco exam could possibly throw at you! Just to make sure you’re solidly armed with all the skills you need to ace the exam as well as successfully administer a network, I’m going to provide even more examples about verifying EIGRP. We’ll be dealing with mostly the same commands and problems we’ve already covered, but this is so important, and the best way to get this all nailed down is to practice troubleshooting an EIGRP network as much as possible! With that, after you’ve configured EIGRP, you would first test connectivity to the remote network by using the Ping program. If that fails, you need to check whether the directly connected router is in the neighbor table. Here are some key things to look for if neighbors haven’t formed an adjacency: Interfaces between the devices are down. The two routers have mismatching EIGRP autonomous system numbers. Proper interfaces are not enabled for the EIGRP process. An interface is configured as passive. The K values are mismatched.


Also, if the adjacency is up but you’re not receiving remote network updates, there may be a routing problem, likely caused by these issues: The proper networks aren’t being advertised under the EIGRP process. An access list is blocking the advertisements from remote networks. Automatic summary is causing confusion in your discontiguous network.
Let’s use  as our example network and run through some troubleshooting scenarios. I’ve preconfigured the routers with IP addresses, and without having to try too hard, I also snuck in a few snags for us to find and fix. Let’s see what we’re facing.
Troubleshooting scenario

A good place to start is by checking to see if we have an adjacency with show ip eigrp neighbors and show ip eigrp interfaces. It’s also smart to see what information the show ip eigrp topology command reveals:
Corp#sh ip eigrp neighbors
IP-EIGRP neighbors for process 20 Corp#

Corp#sh ip eigrp interfaces


Pending Interface

Peers
Xmit Queue

Un/Reliable
Mean

SRTT
Pacing Time

Un/Reliable
Multicast

Flow
Timer   Routes





Se0/1              0
0/0
0
0/15
50
Fa0/0              0
0/0
0
0/1
0
Se0/0              0
0
0/0
0
0/15
50

Corp#sh ip eigrp top





 
IP-EIGRP interfaces for process 20






0

0




IP-EIGRP Topology Table for AS(20)/ID(10.10.11.1)

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



r - reply Status, s - sia Status

P 10.1.1.0/24, 1 successors, FD is 28160 via Connected, FastEthernet0/0

Alright—we can see by looking at the neighbor and the interface as well as the topology table command that our LAN is up on the Corp router but the serial link isn’t working between routers because we don’t have an adjacency. From theshow ip eigrp interfaces command, we can establish that EIGRP is running on all interfaces, so that means our network statements under the EIGRP process are probably correct, but we’ll verify that later.
Let’s move on by checking into our Physical and Data Link status with the show ip int brief command because maybe there’s a physical problem between routers:
Corp#sh ip int brief
Interface                                        IP-Address                                                          OK? Method Status Protocol

FastEthernet0/0                          10.1.1.1                                                          YES manual up up
Serial0/0                                        192.168.1.1                                                          YES manual up up
FastEthernet0/1                           unassigned           YES manual administratively down down
Serial0/1                                        172.16.10.5            YES manual administratively down down
Corp#
Corp#sh protocols s0/0
Serial0/0 is up, line protocol is up Internet address is 192.168.1.1/30
Well, since the Serial0/0 interface shows the correct IP address and the status is up/up, it means we have a good Data Link connection between routers, so it’s not a physical link issue between the routers, which is good! Notice I also used the show protocols command, which gave me the subnet mask for the link. Remember, the information obtained via the two commands gives us only layer 1 and layer 2 status and doesn’t mean we can ping across the link. In other words, we might have a layer 3 issue, so let’s check the Branch router with the same commands:
Branch#sh ip int brief
Interface                                          IP-Address            OK? Method Status



Protocol

FastEthernet0/0

10.2.2.2
YES
manual
up
up





FastEthernet0/1

unassigned
YES
manual
administratively
down down





Serial0/0/0

192.168.1.2
YES
manual
up
up





Serial0/0/1

unassigned
YES
unset
administratively
down down





Branch#sh proto
s0/0/0




Serial0/0/0 is up, line protocol is up Internet address is 192.168.1.2/30
Okay, well, we can see that our IP address and mask are correct, and that the link shows up/up, so we’re looking pretty good! Let’s try to ping from the Corp router to the Branch router now:
Corp#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Now because that was successful, we’ve ruled out layer 1, 2, or 3 issues between routers at this point! Since everything seems to be working between the routers, except EIGRP, checking our EIGRP configurations is our next move. Let’s start with the show ip protocols command:
Corp#sh ip protocols
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100 EIGRP maximum metric variance 2 Redistributing: eigrp 20
EIGRP NSF-aware route hold timer is 240s Automatic network summarization is in effect Maximum path: 4
Routing for Networks:
10.0.0.0
172.16.0.0
192.168.1.0


Passive Interface(s): FastEthernet0/1
Routing Information Sources:
Gateway
Distance
Last Update
(this router)
90
20:51:48
192.168.1.2
90
00:22:58
172.16.10.6
90
01:58:46
172.16.10.2
90
01:59:52
Distance: internal 90 external 170

This output shows us we’re using AS 20, that we don’t have an access-list filter list set on the routing tables, and that our K values are set to default. We can see that we’re routing for the 10.0.0.0, 172.16.0.0, and  192.168.1.0 networks and that we have a passive interface on interface FastEthernet0/1. We don’t have an interface configured for the 172.16.0.0 network, which means that this entry is an extra network statement  under EIGRP. But that won’t hurt anything, so this is not causing our issue. Last, the passive interface is not causing a problem with this network either, because we’re not using interface Fa0/1. Still, keep in mind that when troubleshooting, it’s always good to see if there are any interfaces set to passive.
Let’s see what the show interfaces command will tell us:
Corp#sh interfaces s0/0
Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: <<Connection to Branch>> Internet address is 192.168.1.1/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set [output cut]
Looks like our statistics are set to defaults, so nothing really pops as a problem here. But remember when I covered the steps to check if there is no adjacency back at the beginning of this section? In case you forgot, here’s a list of things to investigate:
The interface between the devices are down.

The two routers have mismatching EIGRP autonomous system numbers. The proper interfaces aren’t enabled for the EIGRP process. An interface is configured as passive. K values are mismatched.


Okay, our interfaces are not down, our AS number matches, layer 3 is working between routers, all the interfaces show up under the EIGRP process, and none of our needed interfaces are passive, so now we’ll have to look even deeper into the EIGRP configuration to uncover the problem.
Since the Corp router has the basic default configurations, we need to check the Branch router’s EIGRP configuration:
Branch#sh ip protocols
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is 10 Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=0, K4=0, K5=0
EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 20
EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4
Routing for Networks:
10.0.0.0
192.168.1.0
Routing Information Sources:
Gateway                     Distance                                     Last Update 192.168.1.1                90                                     00:27:09
Distance: internal 90 external 170
This router has the correct AS—always check this first—and we’re routing for the correct networks. But I see two possible snags here, do you? First, the outgoing ACL filter list is set, but the metrics are not set to default.
Remember, just because an ACL is set doesn’t mean it’s automatically giving you grief. Second, the K values must match, and we know these values are not matching the Corp router!
Let’s take a look at the Branch interface statistics to see what else might be wrong:
Branch>sh int s0/0/0

Serial0/0/0 is up, line protocol is up Hardware is GT96K Serial
Internet address is 192.168.1.2/30
MTU 1500 bytes, BW 512 Kbit, DLY 30000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set [output cut]

Aha! The bandwidth and delay are not set to their defaults and don’t match the directly connected Corp router. Let’s start by changing those back to the default and see if that fixes our problem:
Branch#config t Branch(config)#int s0/0/0 Branch(config-if)#no bandwidth Branch(config-if)#no delay
And let’s check out our stats now to see if we’re back to defaults:
Branch#sh int s0/0/0
Serial0/0/0 is up, line protocol is up Hardware is GT96K Serial
Internet address is 192.168.1.2/30
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255
Encapsulation HDLC, loopback not set [output cut]

The bandwidth and delay are now at the defaults, so let’s check our adjacencies next:
Corp#sh ip eigrp neighbors
IP-EIGRP neighbors for process 20

Okay, so it wasn’t the bandwidth and delay settings because our adjacency didn’t come up, so let’s set our K values back to default like this:
Branch#config t
Branch(config)#router eigrp 20
Branch(config-router)#metric weights 0 1 0 1 0 0
Branch(config-router)#do sho ip proto
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is 10 Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0


[output cut]

I know this probably seems a little complicated at first, but it’s something you shouldn’t have to do much, if ever. Remember, there are five K values, so why 6 numbers? The first number listed is type of service (ToS), so always just set that to 0, which means you must type in six numbers as shown in my configuration example. After we chose the default of 0 first, the default K values are then 1 0 1 0 0, which is bandwidth and delay enabled. Let’s check our adjacency now:
Corp#sh ip eigrp neighbors
IP-EIGRP neighbors for process 20
H   Address
Interface
Hold Uptime
SRTT
RTO  Q  Seq





(sec)
(ms)
Cnt Num



0   192.168.1.2
Se0/0
14 00:02:09
7
200  0  18



Bam! There we go! Looks like mismatched K values were our problem. Now let’s just check to make sure we can ping from end to end and we’re done:
Corp#ping 10.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5) Corp#
Rats! It looks like even though we have our adjacency, we still can’t reach our remote network. Next step? Let’s see what the routing table shows us:
Corp#sh ip route
[output cut]

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C   10.1.1.0/24 is directly connected, FastEthernet0/0 D          10.0.0.0/8 is a summary, 00:18:55, Null0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C   192.168.1.0/30 is directly connected, Serial0/0
D                192.168.1.0/24 is a summary, 00:18:55, Null0

The problem is screamingly clear now because I went through this in detail throughout this chapter. But just in case you still can’t find it, let’s look at the show ip protocols command output:
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming
updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100 EIGRP maximum metric variance 2 Redistributing: eigrp 20
EIGRP NSF-aware route hold timer is 240s Automatic network summarization is in effect Automatic address summarization:
192.168.1.0/24 for FastEthernet0/0 Summarizing with metric 2169856
10.0.0.0/8 for Serial0/0 Summarizing with metric 28160
[output cut]
By looking at the Figure 17.10, you should have noticed right away that we had a discontiguous network. This means that unless they are running
           IOS code, the routers will auto-summarize, so we need to disable auto-summary:
Branch(config)#router eigrp 20
Branch(config-router)#no auto-summary
008412:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor 192.168.1.1
(Serial0/0/0) is resync:
peer graceful-restart

Corp(config)#router eigrp 20 Corp(config-router)#no auto-summary Corp(config-router)#
*Feb 27 19:52:54:%DUAL-5-NBRCHANGE: IP-EIGRP(0) 20:Neighbor 192.168.1.2 (Serial0/0)
is resync: summary configured
*Feb 27 19:52:54.177:IP-EIGRP(Default-IP-Routing-
Table:20):10.1.1.0/24 - do advertise out Serial0/0
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int
10.1.1.0/24 metric 2816
0 - 25600 2560
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing- Table:20):192.168.1.0/30 - do advertise out Serial0/0
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing- Table:20):192.168.1.0/24 - do advertise out Serial0/0
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int


192.168.1.0/24 metric 4294967295 - 0 4294967295
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):10.0.0.0/8 - do advertise
out Serial0/0 Corp(config-router)#
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int
10.0.0.0/8 metric 4294967295 - 0 4294967295
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Processing incoming REPLY packet
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int
192.168.1.0/24 M 4294967295 - 1657856 4294967295 SM 4294967295 -
1657856 4294967295
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int
10.0.0.0/8 M 4294967295 - 25600 4294967295 SM 4294967295 - 25600
4294967295
*Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Processing incoming UPDATE packet
Finally the Corp looks happy, so it looks like we’re good to go! Let’s just check our routing table to be sure:
Corp#sh ip route
[output cut]
10.0.0.0/24 is subnetted, 1 subnets
C                10.1.1.0 is directly connected, FastEthernet0/0 192.168.1.0/30 is subnetted, 1 subnets
C                192.168.1.0 is directly connected, Serial0/0

What the heck? How can this be! We saw all those updates on the Corp console, right? Let’s check the configuration of EIGRP by looking at the active configuration on the Branch router:
Branch#sh run
[output cut]
!
router eigrp 20
network 10.0.0.0
network 192.168.1.0
distribute-list 10 out no auto-summary
!

We can see that the access list is set outbound on the routing table of the Branch router. This may be preventing us from receiving the updates from remote networks! Let’s see what the ACL 10 list is doing:
Branch#sh access-lists
Standard IP access list 10



10 deny         any (40 matches)
20 permit any

Now who in the world would stick an access list like this on a router? This ACL says to deny every packet, which makes the second line of the ACL irrelevant since every single packet will match the first line! This has got to be the source of our troubles, so let’s remove that list and see if the Corp router starts working:
Branch#config t
Branch(config)#router eigrp 20
Branch(config-router)#no distribute-list 10 out

Okay, with that ugly thing gone, let’s check to see if we’re receiving our remote networks now:
Corp#sh ip route
[output cut]
10.0.0.0/24 is subnetted, 2 subnets
D                10.2.2.0 [90/2172416] via 192.168.1.2, 00:00:24, Serial0/0
C                10.1.1.0 is directly connected, FastEthernet0/0 192.168.1.0/30 is subnetted, 1 subnets
C                192.168.1.0 is directly connected, Serial0/0 Corp#
Corp#ping 10.2.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Corp#

Clear skies! We’re up and running. We had mismatched K values, discontiguous networking, and a nasty ACL on our routing table. For the CCNA R/S objectives, always check for an ACL on the actual interface as well, not just in the routing table. It could be set on the interface or routing table, either one, or both! And never forget to check for passive interfaces when troubleshooting a routing protocol issue!
All of these commands are seriously powerful tools in the hands of a savvy professional faced with the task of troubleshooting myriad network issues. I could go on and on about the profusion of information these commands can generate and how well they can equip us to solve virtually every networking ill, but that would be way outside the scope of this book.



Even so, I have no doubt that the foundation I’ve given you here will prove practical and valuable for certification purposes as well as for working in the real networking world.

Simple Troubleshooting EIGRP for the CCNA

Let’s do one more troubleshooting scenario. You have two routers not forming an adjacency. What would you do first? Well, we went through a lot in this chapter, but let me make it super easy for you when you’re troubleshooting on the CCNA exam.
All you need to do is perform a show running-config on each router. That’s it! I can then fix anything regarding EIGRP. Remember that dynamic routing is all about the router you are looking at—it’s not important to be looking at another router’s configuration to get EIGRP correct on the router you’re configuring as long as you know your AS number.
Let’s look at each router’s configuration and determine what the problem is—no network figure needed here because this is all about the router you’re looking at.
Here is the first router’s configuration:
R1#sh run
Building configuration...

Current configuration : 737 bytes
!
version 15.1
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
int FastEthernet0/0
ip address 192.168.16.1 255.255.255.0
int Serial1/1
ip address 192.168.13.1 255.255.255.0
bandwidth 1000 int Serial1/3
ip address 192.168.12.1 255.255.255.0
!
router eigrp 1
network 192.168.12.0
network 192.168.13.0
network 192.168.16.0



Here is the neighbor router’s configuration:
R2#sh run
Building configuration...

Current configuration : 737 bytes
!
version 15.1
!
interface Loopback0
ip address 10.2.2.2 255.255.255.255
interface Loopback1
ip address 10.5.5.5 255.255.255.255
interface Loopback2
ip address 10.5.5.55 255.255.255.255
int FastEthernet0/0
ip address 192.168.123.2 255.255.255.0
int Serial2/1
ip address 192.168.12.2 255.255.255.0
!
router eigrp 2
network 10.2.2.2 0.0.0.0
network 192.168.12.0
network 192.168.123.0

Can you see the problems? Pretty simple. First, notice that we’re running
           codeso we don’t need to worry about discontiguous networks or need to configure theno auto-summary command. One thing down!
Now, let’s look at each interface and either remember or write down the network numbers under each interface, including the loopback interfaces. Once we do that we can then make sure our EIGRP configuration is correct.
Here is the new configuration for R1:
R1#config t
R1(config)#router eigrp 1
R1(config-router)#network 10.1.1.1 0.0.0.0

That’s it! I just added the missing network statement from the loopback0 interface under the EIGRP process; all the other networks were already under the EIGRP process. We’re golden on R1. Let’s fix R2 now:
R2#config t
R2(config)#no router eigrp 2
R2(config)#router eigrp 1
R2(config-router)#network 10.2.2.2 0.0.0



R2(config-router)#network 10.5.5.5 0.0.0.0
R2(config-router)#network 10.5.5.55 0.0.0.0
R2(config-router)#network 192.168.123.0
R2(config-router)#network 192.168.12.0

Notice I started by deleting the wrong AS number—they have to match! I then created another EIGRP process using AS 1 and then added all the networks found under every interface, including the loopback interfaces.
It’s that easy! Just perform a Show running-config on each router, add any missing networks found under each interface to the EIGRP process, make sure the AS numbers match, and you’re set!
Now it’s time to relax a bit as we move into the easiest part of this chapter, seriously—not joking! You still need to pay attention though.
As I was just saying, welcome to the easiest part of the chapter! Of course, I only mostly mean that, and here’s why: I talked about IPv6 in the earlier ICND1 chapters, and in order to continue on with this section of the chapter, you need to have that vital, foundational part of IPv6 down solidly before you dare to dwell here! If you do, you’re pretty much set and this will all be pretty simple for you.
EIGRPv6 works much the same way as its IPv4 predecessor does—most of the features that EIGRP provided before EIGRPv6 will still be available.
EIGRPv6 is still an advanced distance-vector protocol that has some link- state features. The neighbor discovery process using Hellos still happens, and it still provides reliable communication with Reliable Transport Protocol that gives us loop-free fast convergence using the Diffusing Update Algorithm (DUAL).
Hello packets and updates are sent using multicast transmission, and as with RIPng, EIGRPv6’s multicast address stayed almost the same. In IPv4 it was 224.0.0.10; in IPv6, it’s FF02::A (A = 10 in hexadecimal notation).
But clearly, there are key differences between the two versions. Most notably the use of the pesky network command is gone, so it’s hard to make a mistake with EIGRPv6. Also, the network and interface to be



advertised must be enabled from interface configuration mode with one simple command.
But you still have to use the router configuration mode to enable the routing protocol in EIGRPv6 because the routing process must be literally enabled like an interface with the no shutdown command— interesting! However, the 15.0 code does enable this by default, so this command actually may or may not be needed.
Here’s an example of enabling EIGRPv6 on the Corp router:
Corp(config)#ipv6 unicast-routing
Corp(config)#ipv6 router eigrp 10

The 10 in this case is still the AS number. The prompt changes to
(config-rtr), and from here, just initiate a no shutdown if needed:
Corp(config-rtr)#no shutdown

Other options also can be configured in this mode, like redistribution and router ID (RID). So now, let’s go to the interface and enable IPv6:
Corp(config-if)#ipv6 eigrp 10

The 10 in the interface command again references the AS number that was enabled in the configuration mode.
Figure 17.11 shows the layout we’ve been using throughout this chapter, only with IPv6 addresses now assigned to interfaces. I used the EUI-64 option on each interface so each router assigned itself an IPv6 address after I typed in the 64-bit network/subnet address.
 Configuring EIGRPv6 on our internetwork
We’ll start with the Corp router. Really, all we need to know in order to enable EIGRPv6 are which interfaces we’re using and want to advertise our networks.
Corp#config t
Corp(config)#ipv6 router eigrp 10 Corp(config-rtr)#no shut Corp(config-rtr)#router-id 1.1.1.1 Corp(config-rtr)#int s0/0/0 Corp(config-if)#ipv6 eigrp 10 Corp(config-if)#int s0/0/1 Corp(config-if)#ipv6 eigrp 10 Corp(config-if)#int g0/0 Corp(config-if)#ipv6 eigrp 10 Corp(config-if)#int g0/1 Corp(config-if)#ipv6 eigrp 10
I had erased and reloaded the routers before I started this EIGRPv6 section of the chapter. What this means is that there were no 32-bit addresses on the router in order to create the RID for EIGRP, so I had to set it under the IPv6 router global command, which is the same  command used with EIGRP and EIGRPv6. Unlike with OSPF, the RID isn’t that important, and it can actually be the same address on every router. You just can’t get away with doing this with OSPF! The configuration for EIGRPv6 was pretty straightforward because unless you type the AS number wrong, it’s pretty hard to screw this up!
Okay, let’s configure the SF and NY routers now, and then we’ll verify our networks:
SF#config t
SF(config)#ipv6 router eigrp 10 SF(config-rtr)#no shut SF(config-rtr)#router-id 2.2.2.2 SF(config-rtr)#int s0/0/0 SF(config-if)#ipv6 eigrp 10 SF(config-if)#int g0/0 SF(config-if)#ipv6 eigrp 10 SF(config-if)#int g0/1 SF(config-if)#ipv6 eigrp 10

NY#config t
NY(config)#ipv6 router eigrp 10 NY(config-rtr)#no shut NY(config-rtr)#router-id 3.3.3.3 NY(config-rtr)#int s0/0/0 NY(config-if)#ipv6 eigrp 10 NY(config-if)#int g0/0



NY(config-if)#ipv6 eigrp 10
NY(config-if)#int g0/1

Since we configured EIGRPv6 on a per-interface basis, no worries about having to use the passive-interface command. This is because if we don’t enable the routing protocol on an interface, it’s just not part of the EIGRPv6 process. We can see which interfaces are part of the EIGRPv6 process with the show ipv6 eigrp interfaces command like this:
Corp#sh ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 10

Pending Interface

Peers
Xmit Queue

Un/Reliable
Mean

SRTT
Pacing Time

Un/Reliable
Multicast

Flow
Timer    Routes





Se0/0/0
1
0/0
1236
0/10
0
0





Se0/0/1
1
0/0
1236
0/10
0
0





Gig0/1
0
0/0
1236
0/10
0
0





Gig0/0
0
0/0
1236
0/10
0
0





Corp#





Looks great so far—all the interfaces we want in our AS are listed, so we’re looking good for our Corp’s local configuration. Now it’s time to check if our adjacencies came up with the show ipv6 eigrp neighbors command:
Corp#sh ipv6 eigrp neighbors
IPv6-EIGRP neighbors for process 10
H      Address                                        Interface               Hold         Uptime                                         SRTT RTO                     Q      Seq
(sec)                         (ms)
Cnt Num
0       Link-local address:                        Se0/0/0               10         00:01:40                                           40
1000     0       11
FE80::201:C9FF:FED0:3301
1       Link-local address:                        Se0/0/1               14         00:01:24                                           40
1000     0       11
FE80::209:7CFF:FE51:B401

It’s great that we can see neighbors listed off of each serial interface, but do you notice something missing from the preceding output? That’s right, the actual IPv6 network/subnet addresses of the links aren’t listed in the neighbor table! Only the link-local addresses are used for forming EIGRP neighbor adjacencies. With IPv6, neighbor interfaces and next-hop addresses are always link-local.
We can verify our configuration with the show ip protocols command:
Corp#sh ipv6 protocols
IPv6 Routing Protocol is "connected" IPv6 Routing Protocol is "static  IPv6 Routing Protocol is "eigrp                                                 10 "
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Interfaces:
Serial0/0/0 Serial0/0/1 GigabitEthernet0/0 GigabitEthernet0/1
Redistributing: eigrp 10
Maximum path: 16
Distance: internal 90 external 170

You can verify the AS number from this output, but be sure to verify your K values, variance, and interfaces too. Remember that the AS number and interfaces are the first factors to check when troubleshooting.
The topology table lists all feasible routes in the network, so this output can be rather long, but let’s see what this shows us:
Corp#sh ipv6 eigrp topology
IPv6-EIGRP Topology Table for AS 10/ID(1.1.1.1)

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

P 2001:DB8:C34D:11::/64, 1 successors, FD is 2169856
via Connected, Serial0/0/0
P 2001:DB8:C34D:12::/64, 1 successors, FD is 2169856
via Connected, Serial0/0/1
P 2001:DB8:C34D:14::/64, 1 successors, FD is 2816 via Connected, GigabitEthernet0/1
P 2001:DB8:C34D:13::/64, 1 successors, FD is 2816 via Connected, GigabitEthernet0/0
P 2001:DB8:C34D:17::/64, 1 successors, FD is 2170112
via FE80::201:C9FF:FED0:3301 (2170112/2816), Serial0/0/0 P 2001:DB8:C34D:18::/64, 1 successors, FD is 2170112
via FE80::201:C9FF:FED0:3301 (2170112/2816), Serial0/0/0 P 2001:DB8:C34D:15::/64, 1 successors, FD is 2170112

via FE80::209:7CFF:FE51:B401 (2170112/2816), Serial0/0/1 P 2001:DB8:C34D:16::/64, 1 successors, FD is 2170112
via FE80::209:7CFF:FE51:B401 (2170112/2816), Serial0/0/1

Since we only have eight networks in our internetwork, we cn see all eight networks in the topology table, which clearly is as it should be. I’ve highlighted a couple of things I want to discuss, and the first is that you need to be able to read and understand a topology table. This includes understanding which routes are directly connected and which are being advertised via neighbors. The via Connected shows us our directly connected networks. The second item I want to show you is (2170112/2816), which is the FD/AD, and by the way, it’s no different than if you’re working with IPv4.
So let’s wrap up this chapter by taking a look at a routing table:
Corp#sh ipv6 route eigrp
IPv6 Routing Table - 13 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route, M - MIPv6
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS
summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
D - EIGRP, EX - EIGRP external C         2001:DB8:C34D:11::/64 [0/0]
via ::, Serial0/0/0
L       2001:DB8:C34D:11:230:A3FF:FE36:B101/128 [0/0]
via ::, Serial0/0/0
C       2001:DB8:C34D:12::/64 [0/0]
via ::, Serial0/0/1
L       2001:DB8:C34D:12:230:A3FF:FE36:B102/128 [0/0]
via ::, Serial0/0/1
C 2001:DB8:C34D:13::/64 [0/0]
via ::, GigabitEthernet0/0
L       2001:DB8:C34D:13:2E0:F7FF:FEDA:7501/128 [0/0]
via ::, GigabitEthernet0/0 C         2001:DB8:C34D:14::/64 [0/0]
via ::, GigabitEthernet0/1
L       2001:DB8:C34D:14:2E0:F7FF:FEDA:7502/128 [0/0]
via ::, GigabitEthernet0/1
D      2001:DB8:C34D:15::/64 [90/2170112]
via FE80::209:7CFF:FE51:B401, Serial0/0/1 D         2001:DB8:C34D:16::/64 [90/2170112]
via FE80::209:7CFF:FE51:B401, Serial0/0/1 D         2001:DB8:C34D:17::/64 [90/2170112]


via FE80::201:C9FF:FED0:3301, Serial0/0/0 D         2001:DB8:C34D:18::/64 [90/2170112]
via FE80::201:C9FF:FED0:3301, Serial0/0/0
L FF00::/8 [0/0]
via ::, Null0

I highlighted the EIGRPv6 injected routes that were injected into the routing table. It’s important to notice that in order for IPv6 to get to a remote network, the router uses the next-hop link-local address. Do you see that in the table? For example, via FE80::209:7CFF:FE51:B401, Serial0/0/1 is the link-local address of the NY router.
See? I told you it was easy!

Summary
It’s true that this chapter has been pretty extensive, so let’s briefly recap what we covered in it. EIGRP, the main focus of the chapter, is a hybrid of link-state routing and typically referred to as an advanced distance-vector protocol. It allows for unequal-cost load balancing, controlled routing updates, and formal neighbor adjacencies called relationships to be formed.
EIGRP uses the capabilities of the Reliable Transport Protocol (RTP) to communicate between neighbors and utilizes the Diffusing Update Algorithm (DUAL) to compute the best path to each remote network.
We also covered the configuration of EIGRP and explored a number of troubleshooting commands plus key ways and means to help solve some common networking issues.
Moving on, EIGRP facilitates unequal-cost load balancing, controlled routing updates, and formal neighbor adjacencies.
I also went over the configuration of EIGRP and explored a number of troubleshooting commands as well as taking you through a highly informative scenario that will not only help you to ace the exam, it will help you confront and overcome many troubleshooting issues common to today’s inter-networks!
Finally, I went over the easiest topic at the end of this long chapter: EIGRPv6. Easy to understand, configure, and verify!


Exam Essentials

Know EIGRP features. EIGRP is a classless, advanced distance-vector protocol that supports IP and now IPv6. EIGRP uses a unique algorithm, called DUAL, to maintain route information and uses RTP to communicate with other EIGRP routers reliably.
Know how to configure EIGRP. Be able to configure basic EIGRP. This is configured the same as RIP with classful addresses.
Know how to verify EIGRP operation. Know all of the EIGRP show commands and be familiar with their output and the interpretation of the main components of their output.
Be able to read an EIGRP topology table. Understand which are successors, which are feasible successors, and which routes will become successors if the main successor fails.
You must be able to troubleshoot EIGRP. Go through the EIGRP troubleshooting scenario and make sure you understand to look for the AS number, ACLs, passive interfaces, variance, and other factors.
Be able to read an EIGRP neighbor table. Understand the output of the show ip eigrp neighbor command.
Understand how to configure EIGRPv6. To configure EIGRPv6, first create the autonomous system from global configuration mode and perform a no shutdown. Then enable EIGRPv6 on each interface individually.

Written Lab 17

You can find the answers to this lab in Appendix A, “Answers to Written Labs.”
1. What is the command to enable EIGRPv6 from global configuration mode?
2. What is the EIGRPv6 multicast address?
3. True/False: Each router within an EIGRP domain must use different AS numbers.
4. If you have two routers with various K values assigned, what will this do to the link?
5. What type of EIGRP interface will neither send nor receive Hello packets?
6. Which type of EIGRP route entry describes a feasible successor?

Hands-on Labs

In this section, you will use the following network and add EIGRP and EIGRPv6 routing.

The first lab requires you to configure two routers for EIGRP and then view the configuration. In the last lab, you will be asked to enable EIGRPv6 routing on the same network. Note that the labs in this chapter were written to be used with real equipment—real cheap equipment, that is. I wrote these labs with the cheapest, oldest routers I had lying around so you can see that you don’t need expensive gear to get through some of the hardest labs in this book. However, you can use the free LammleSim IOS version simulator or Cisco’s Packet Tracer to run through these labs.

The labs in this chapter are as follows:
Lab 17.1: Configuring and Verifying EIGRP Lab 17.2: Configuring and Verifying EIGRPv6

Hands-on Lab 17.1: Configuring and Verifying EIGRP

This lab will assume you have configured the IP addresses on the interfaces as shown in the preceding diagram.
1.       Implement EIGRP on RouterA.
RouterA#conf t
Enter configuration commands, one per line.
End with CNTL/Z. RouterA(config)#router eigrp 100
RouterA(config-router)#network 192.168.1.0
RouterA(config-router)#network 10.0.0.0
RouterA(config-router)#^Z



RouterA#
2.       Implement EIGRP on RouterB.
RouterB#conf t
Enter configuration commands, one per line.
End with CNTL/Z. RouterB(config)#router eigrp 100
RouterB(config-router)#network 192.168.1.0
RouterA(config-router)#network 10.0.0.0
RouterB(config-router)#exit RouterB#
3.       Display the topology table for RouterA.
RouterA#show ip eigrp topology

4.       Display the routing table for RouterA.
RouterA #show ip route

5.       Display the neighbor table for RouterA.
RouterA show ip eigrp neighbor

6.       Type the command on each router to fix the routing problem. You did see a problem, didn’t you? Yes, the network is discontiguous.
RouterA#config t RouterA(config)#router eigrp 100 RouterA(config-router)#no auto-summary

RouterB#config t RouterA(config)#router eigrp 100 RouterA(config-router)#no auto-summary
7.       Verify your routes with the show ip route command.

Hands-on Lab 17.2: Configuring and Verifying EIGRPv6

This lab will assume you configured the IPv6 address as shown in the diagram preceding Lab 5.1.
1.       Implement EIGRPv6 on RouterA with AS 100.
RouterA#config t
RouterA (config)#ipv6 router eigrp 100
RouterA (config-rtr)#no shut
RouterA (config-rtr)#router-id 2.2.2.2
RouterA (config-rtr)#int s0/0 RouterA (config-if)#ipv6 eigrp 100 RouterA (config-if)#int g0/0 RouterA (config-if)#ipv6 eigrp 100
2.       Implement EIGRP on RouterB.
RouterA#config  t RouterB(config)#ipv6 router eigrp 100 RouterB(config-rtr)#no shut RouterB(config-rtr)#router-id 2.2.2.2 RouterB(config-rtr)#int s0/0 RouterB(config-if)#ipv6 eigrp 100 RouterB(config-if)#int g0/0 RouterB(config-if)#ipv6 eigrp 100
3.       Display the topology table RouterA.
RouterA#show ipv6 eigrp topology

4.       Display the routing table for RouterA.
RouterA #show ipv6 route

5.       Display the neighbor table for RouterA.
RouterA show ipv6 eigrp neighbor

Review Questions


You can find the answers to these questions in Appendix B, “Answers to Review Questions.”

1.       There are three possible routes for a router to reach a destination network. The first route is from OSPF with a metric of 782. The second route is from RIPv2 with a metric of 4. The third is from EIGRP with a composite metric of 20514560. Which route will be installed by the router in its routing table?



A.     RIPv2
B.     EIGRP
C.     OSPF
D.     All three

2.       Which EIGRP information is held in RAM and maintained through the use of Hello and update packets? (Choose two.)

A.     Neighbor table
B.     STP table
C.     Topology table
D.     DUAL table

3.       What will be the reported distance to a downstream neighbor router for the 10.10.30.0 network, with the neighbor adding the cost to find the true FD?
P 10.10.30.0/24, 1 successors, FD is 2297856
via 172.16.10.2 (2297856/128256), Serial0/0

A.     Four hops
B.  2297856
C.  128256
D. EIGRP doesn’t use reported distances.

4.       Where are EIGRP successor routes stored?

A.     In the routing table only
B.     In the neighbor table only
C.     In the topology table only
D.     In the routing table and the neighbor table
E.     In the routing table and the topology table
F.     In the topology table and the neighbor table

5.       Which command will display all the EIGRP feasible successor routes known to a router?

A.     show ip routes *
B.     show ip eigrp summary
C.     show ip eigrp topology
D.     show ip eigrp adjacencies
E.     show ip eigrp neighbors detail

6.       Which of the following commands are used when routing with EIGRP or EIGRPv6? (Choose three.)

A.     network 10.0.0.0
B.     eigrp router-id
C.     variance
D.     router eigrp
E.     maximum-paths

7.       Serial0/0 goes down. How will EIGRP send packets to the 10.1.1.0 network?
Corp#show ip eigrp topology
[output cut]
P 10.1.1.0/24, 2 successors, FD is 2681842
via 10.1.2.2 (2681842/2169856), Serial0/0 via 10.1.3.1 (2973467/2579243), Serial0/2 via 10.1.3.3 (2681842/2169856), Serial0/1

A.     EIGRP will put the 10.1.1.0 network into active mode.
B.     EIGRP will drop all packets destined for 10.1.1.0.
C.     EIGRP will just keep sending packets out s0/1.
D.     EIGRP will use s0/2 as the successor and keep routing to 10.1.1.0.

8.       What command do you use to enable EIGRPv6 on an interface?

A.     router eigrp as
B.     ip router eigrp as
C.     router eigrpv6 as
D.     ipv6 eigrp as

9.       What command was typed in to have these two paths to network
10.10.50.0 in the routing table?
D                10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:20,
Serial0/1
[90/6893568] via 172.16.10.2, 00:00:20,
Serial0/0

A.     maximum-paths 2
B.     variance 2
C.     variance 3
D.     maximum-hops 2

10.     A route to network 10.10.10.0 goes down. How does EIGRP respond in the local routing table? (Choose two.)

A.     It sends a poison reverse with a maximum hop of 16.
B.     If there is a feasible successor, that is copied and placed into the routing table.
C.     If a feasible successor is not found, a query will be sent to all neighbors asking            for a path to network 10.10.10.0.
D.     EIGRP will broadcast out all interfaces that the link to network
        10.10.10.0 is down and that it is looking for a feasible successor.

11.     You need the IP address of the devices with which the router has established an adjacency. Also, the retransmit interval and the queue counts for the adjacent routers need to be checked. What command will display the required information?

A.     show ip eigrp adjacency
B.     show ip eigrp topology
C.     show ip eigrp interfaces
D.     show ip eigrp neighbors

12.       For some reason, you cannot establish an adjacency relationship on a common Ethernet link between two routers. Looking at the output shown here, what are the causes of the problem? (Choose two.)

RouterA##show ip protocols
Routing Protocol is "eigrp 20"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

RouterB##show ip protocols
Routing Protocol is "eigrp 220"
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates
Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=1, K3=1, K4=0, K5=0

A.     EIGRP is running on RouterA and OSPF is running on RouterB.
B.     There is an ACL set on the routing protocol.
C.     The AS numbers don’t match.
D.     There is no default network accepted from incoming updates.
E.     The K values don’t match.
F.     There is a passive interface set.

13.       Which are true regarding EIGRP successor routes? (Choose two.)

A.     A successor route is used by EIGRP to forward traffic to a destination.
B.     Successor routes are saved in the topology table to be used if the primary route fails.
C.     Successor routes are flagged as “active” in the routing table.
D.     A successor route may be backed up by a feasible successor route.
E.     Successor routes are stored in the neighbor table following the discovery process.
14.       The remote RouterB router has a directly connected network of 10.255.255.64/27. Which two of the following EIGRP network statements could you use so this directly connected network will be advertised under the EIGRP process? (Choose two.)

A. network
10.255.255.64

B. network
10.255.255.64
0.0.0.31
C. network
10.255.255.64
0.0.0.0
D. network
10.255.255.64
0.0.0.15

15.       RouterA and RouterB are connected via their Serial 0/0 interfaces, but they have not formed an adjacency. Based on the following output, what could be the problem?

A.     The metric K values don’t match.
B.     The AS numbers don’t match.
C.     There is a passive interface on RouterB.
D.     There is an ACL set on RouterA.

16.       How many paths will EIGRPv6 load-balance by default?

A.     16
B.     32
C.     4
D.     None

17.       What would your configurations be on RouterB based on the illustration? (Choose two.)

A.     (config)#router eigrp 10
B.     (config)#ipv6 router eigrp 10
C.     (config)#ipv6 router 2001:db8:3c4d:15::/64
D.     (config-if)#ip eigrp 10
E.     (config-if)#ipv6 eigrp 10
F.     (config-if)#ipv6 router eigrp 10

18.       RouterA has a feasible successor not shown in the following output. Based on what you can learn from the output, which one of the following will be the successor for 2001:db8:c34d:18::/64 if the current successor fails?
via FE80::201:C9FF:FED0:3301 (29110112/33316), Serial0/0/0 via FE80::209:7CFF:FE51:B401 (4470112/42216), Serial0/0/1 via FE80::209:7CFF:FE51:B401 (2170112/2816), Serial0/0/2

A.     Serial0/0/0
B.     Serial0/0/1
C.     Serial0/0/2
D.     There is no feasible successor.

19.       You have router output as shown in the following illustrations with routers running IOS 12.4. However, the two networks are not sharing routing table route entries. What is the problem?

A.     The variances don’t match between routers.
B.     The metrics are not valid between neighbors.
C.     There is a discontiguous network.
D.     There is a passive interface on RouterB.
E.     An ACL is set on the router.

20.     Which should you look for when troubleshooting an adjacency? (Choose four.)

A.     Verify the AS numbers.
B.     Verify that you have the proper interfaces enabled for EIGRP.
C.     Make sure there are no mismatched K values.
D.     Check your passive interface settings.
E.     Make sure your remote routers are not connected to the Internet.
F.     If authentication is configured, make sure all routers use different passwords.

Comments

Popular posts from this blog

What if Analysis

What-If Analysis What-If Analysis in Excel allows you to try out different values (scenarios) for formulas. The following example helps you master what-if analysis quickly and easily.  Use scenarios to consider many different variables  A scenario is a set of values that Excel saves and can substitute automatically in cells on a worksheet. You can create and save different groups of values on a worksheet and then switch to any of these new scenarios to view different results. 
Create Different Scenarios 
Note: You can simply type in a different revenue and Cost into cell B2 and B3 respectively to see the corresponding result of a scenario in cell B4. However, what-if analysis enables you to easily compare the results of different scenarios.  
I. On the Data tab, click What-If Analysis and select Scenario Manager from the list. The Scenario Manager Dialog box appears  II. Add a scenario by clicking on Add.  III. Type a name (e.g. “First Case”), select cell B2 and B3 (represents “Revenue” and “…

PROFESSIONAL ENGLISH

Asking For and Giving Opinions on Likes and Dislikes

Words Meaning Sample Sentence Opinion A statement or judgment formed about some matter. Bhoomika gave her final opinion on the company’s matter. Dialogue A conversation between two or more people. Her dialogue stated her opinion about the company’s matter. Expression The action of making known one’s thought or feelings. Her expression was sad at the meeting. Frank An open, honest, and direct speech or writing Bhoomika is very frank with her friends. Recover Return to normal state of health, mind or strength. The company’s economic crisis will be recovered soon. Turmoil A state of great disturbance. The company is facing financial turmoil. Economics The branch of knowledge concerned with the production, consumption, and transfer of wealth. Bhoomika studied Economics at the State University. Betrayed Expose to danger by treacherously giving information to an enemy.

DAILY LIFE VOCABULARY

Apology Etiquette and Office Vocabulary 

Chapter Vocabulary

Word Meaning Sample Sentence Stressed A state of any mental or emotional tension. Ram seems much stressed after his poor exam. Launch An act of instance of starting something. The government launched a new scheme for the poor people. Error A mistake Ravi found a grammatical error in his new grammar book. Scold Blaming someone for any wrong doing Bhuvan scolded his employees for their poor performance. Accuse Claiming that someone has done something wrong. Bharati accuses her friend Chaya for stealing her necklace. Fair Good and honest Ravi got promoted for doing a fair job. Ashamed Embarrassed or guilty because of one’s action. <