Chapter 4. Troubleshooting EIGRP for IPv4
This chapter covers the following topics:
Troubleshooting EIGRP for IPv4 Neighbor Adjacencies: This section covers the reasons EIGRP for IPv4 neighbor relationships might not be formed and how to identify them.
Troubleshooting EIGRP for IPv4 Routes: This section explores the reasons EIGRP for IPv4 routes might be missing from a router’s EIGRP table or routing table and how to determine why they are missing.
Troubleshooting Miscellaneous EIGRP for IPv4 Issues: This section identifies some additional issues you might face while using EIGRP, how to identify them, and how to solve them.
EIGRP for IPv4 Trouble Tickets: This section provides three trouble tickets that demonstrate how to use a structured troubleshooting process to solve a reported problem.
This chapter focuses on troubleshooting EIGRP for IPv4. Chapter 5, “EIGRPv6,” covers EIGRP for IPv6 and named EIGRP.
Before any routes can be exchanged between EIGRP routers on the same LAN or across a WAN, an EIGRP neighbor relationship must be formed. Neighbor relationships may not form for many reasons, and as a troubleshooter, you need to be aware of them. This chapter dives deep into these issues and gives you the tools needed to identify them and successfully solve neighbor issues.
Once neighbor relationships are formed, neighboring routers exchange EIGRP routes. In various cases, routes may end up missing, and you need to be able to determine why the routes are missing. This chapter discusses the various ways that routes could go missing and how you can identify them and solve route-related issues.
In this chapter, you will also learn how to troubleshoot issues related to load balancing, summarization, discontiguous networks, and feasible successors.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 4-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”
Table 4-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundation Topics Section |
Questions |
Troubleshooting EIGRP for IPv4 Neighbor Adjacencies |
1–4 |
Troubleshooting EIGRP for IPv4 Routes |
5, 6, 8 |
Troubleshooting Miscellaneous EIGRP for IPv4 Issues |
7, 9, 10 |
1. Which command enables you to verify the routers that have formed EIGRP adjacencies with the local router, how long they have been neighbors, and the current sequence numbers of EIGRP packets?
show ip eigrp interfaces
show ip eigrp neighbors
show ip route eigrp
show ip protocols
2. Which of the following are reasons EIGRP neighbor relationships might not form? (Choose three.)
Different autonomous system numbers
Different K values
Different timers
Different authentication parameters
3. Which command enables you to verify the configured EIGRP K values?
show ip protocols
show ip eigrp interfaces
show ip eigrp neighbor
show ip eigrp topology
4. Which command enables you to verify EIGRP authentication, split horizon, and configured EIGRP timers?
show ip interfaces
show ip protocols
show ip eigrp interfaces detail
show ip eigrp neighbor
5. Besides a neighbor relationship not being formed, which three of the following are reasons routes might be missing in an EIGRP autonomous system? (Choose three.)
Interface not participating in the EIGRP process
Filters
Incorrect stub configuration
Passive interface feature
6. Which command enables you to verify whether any route filters have been applied to an EIGRP-enabled interface?
show ip interface brief
show ip interface
show ip protocols
show ip eigrp interface
7. Which command enables you to verify the maximum paths configured for load balancing and whether unequal-path load balancing has been enabled?
show ip protocols
show ip eigrp interfaces
show ip eigrp neighbors
show ip interfaces
8. You have a DMVPN network that has a hub and three spokes. The spokes are not learning the routes of the other spokes. Of the following options, which is most likely the reason for this?
Split horizon is enabled on the GRE interfaces of the spokes
Split horizon is enabled on the hub’s mGRE interface
Split horizon is disabled on the hub’s mGRE interface
Split horizon is disabled on the GRE interfaces of the spokes
9. An EIGRP summary route is not showing up on the expected routes in the AS. Which of the following questions should you answer while troubleshooting? (Choose three.)
Did you enable route summarization on the correct interface?
Did you associate the summary route with the correct EIGRP autonomous system?
Did you create the appropriate summary route?
Did you create a route to NULL0?
10. The IP addressing scheme for your routing domain is discontiguous. What command should you use in EIGRP configuration mode to make sure that you do not have any routing issues in your EIGRP autonomous system?
no auto-summary
auto-summary
passive-interface
network ip_address wildcard_mask
Foundation Topics
Troubleshooting EIGRP for IPv4 Neighbor Adjacencies
EIGRP establishes neighbor relationships by sending hello packets to the multicast address 224.0.0.10, out interfaces participating in the EIGRP process. To enable the EIGRP process on an interface, you use the network ip_address wildcard_mask command in router EIGRP configuration mode. For example, the command network 10.1.1.0 0.0.0.255 enables EIGRP on all interfaces with an IP address from 10.1.1.0 through 10.1.1.255. The command network 10.1.1.65 0.0.0.0 enables the EIGRP process on only the interface with the IP address 10.1.1.65. It seems rather simple, and it is; however, for various reasons, neighbor relationships may not form, and you need to be aware of all of them if you plan on successfully troubleshooting EIGRP-related problems. This section focuses on the reasons EIGRP neighbor relationships might not form and how you can identify them during the troubleshooting process.
To verify EIGRP neighbors, you use the show ip eigrp neighbors command. Example 4-1 provides sample output of the show ip eigrp neighbors command. It lists the IPv4 address of the neighboring device’s interface that sent the hello packet, the local interface on the router used to reach that neighbor, how long the local router will consider the neighboring router to be a neighbor, how long the routers have been neighbors, the amount of time it takes for the neighbors to communicate, on average, the number of EIGRP packets in a queue waiting to be sent to a neighbor (which should always be zero since you want up-to-date routing information), and a sequence number to keep track of the EIGRP packets received from the neighbor to ensure that only newer packets are accepted and processed.
Example 4-1 Verifying EIGRP Neighbors with show ip eigrp neighbors
R2# show ip eigrp neighbors
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 10.1.23.3 Gi1/0 14 10:01:09 72 432 0 3
0 10.1.12.1 Gi0/0 11 10:32:14 75 450 08
EIGRP neighbor relationships might not form for a variety of reasons, including the following:
Interface is down: The interface must be up/up.
Mismatched autonomous system numbers: Both routers need to be using the same autonomous system number.
Incorrect network statement: The network statement must identify the IP address of the interface you want to include in the EIGRP process.
Mismatched K values: Both routers must be using exactly the same K values.
Passive interface: The passive interface feature suppresses the sending and receiving of hello packets while still allowing the interface’s network to be advertised.
Different subnets: The exchange of hello packets must be done on the same subnet; if it isn’t, the hello packets are ignored.
Authentication: If authentication is being used, the key ID and key string must match, and the key must be valid (if valid times have been configured).
ACLs: An access control list (ACL) may be denying packets to the EIGRP multicast address 224.0.0.10.
Timers: Timers do not have to match; however, if they are not configured correctly, neighbor adjacencies could flap.
When an EIGRP neighbor relationship does not form, the neighbor is not listed in the neighbor table. In such a case, you need the assistance of an accurate physical and logical network diagram and the show cdp neighbors command to verify who should be the neighbors.
When troubleshooting EIGRP, you need to be aware of how to verify the parameters associated with each of the reasons listed here. Let’s look at them individually.
Interface Is Down
The interface must be up if you plan on forming an EIGRP neighbor adjacency. You can verify the status of an interface with the show ip interface brief command. The status should be listed as up, and the protocol should be listed as up.
Mismatched Autonomous System Numbers
For an EIGRP neighbor relationship to be formed, both routers need to be in the same autonomous system. You specify the autonomous system number when you issue the router eigrp autonomous_system_number command in global configuration mode. If the two routers are in different autonomous systems, they will not form an EIGRP neighbor relationship. Most EIGRP show commands display the autonomous system number in the output. However, the best one is show ip protocols, which displays an incredible amount of information for troubleshooting, as shown in Example 4-2. In this example, you can see that R1 is participating in EIGRP autonomous system 100. Using the spot-the-difference troubleshooting method, you can compare the autonomous system value listed to the value on a neighboring router to determine whether they differ.
Example 4-2 Verifying the Autonomous System Number with show ip protocols
R1# show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "eigrp 100" 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(100) Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 NSF-aware route hold timer is 240 Router-ID: 10.1.12.1 Topology : 0 (base) Active Timer: 3 min Distance: internal 90 external 170 Maximum path: 4 Maximum hopcount 100 Maximum metric variance 1 Automatic Summarization: disabled Maximum path: 4 Routing for Networks: 10.1.1.1/32 10.1.12.1/32 Routing Information Sources: Gateway Distance Last Update 10.1.12.2 90 09:54:36 Distance: internal 90 external 170
The output of the debug eigrp packets command shown in Example 4-3 indicates that the router is not receiving any hello packets from the neighbors with the mismatched autonomous system number. In this example, R1 is sending hello packets out Gi0/0 and Gi1/0. However, it is not receiving any hello packets. This could be because of an autonomous system mismatch. The local router could have the wrong autonomous system number, or the remote routers could have the wrong autonomous system number.
Example 4-3 Sample Output of debug eigrp packets When an Autonomous System Mismatch Exists
R1# debug eigrp packets (UPDATE, REQUEST, QUERY, REPLY, HELLO, UNKNOWN, PROBE, ACK, STUB, SIAQUERY, SIAREPLY) EIGRP Packet debugging is on R1# EIGRP: Sending HELLO on Gi0/0 - paklen 20 AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 R1# EIGRP: Sending HELLO on Gi1/0 - paklen 20 AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 R1# EIGRP: Sending HELLO on Gi0/0 - paklen 20 AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 R1# l EIGRP: Sending HELLO on Gi1/0 - paklen 20 AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 R1# l EIGRP: Sending HELLO on Gi0/0 - paklen 20 AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 R1# u all All possible debugging has been turned off
Incorrect Network Statement
If the network command is misconfigured, EIGRP may not be enabled on the proper interfaces, and as a result, hello packets will not be sent and neighbor relationships will not be formed. You can determine which interfaces are participating in the EIGRP process with the command show ip eigrp interfaces. In Example 4-4, for instance, you can see that two interfaces are participating in the EIGRP process for autonomous system 100. Gi0/0 does not have an EIGRP peer, and Gi1/0 does have an EIGRP peer. This is expected because no other routers can be reached out Gi0/0 for this scenario. However, if you expect an EIGRP peer out the interface based on your documentation, you need to troubleshoot why the peering/neighbor relationship is not forming. Shift your attention to the Pending Routes column. Notice all interfaces are listed as 0. This is expected. Any other value in this column means that some issue on the network (such as congestion) is preventing the interface from sending the necessary updates to the neighbor.
Example 4-4 Verifying EIGRP Interfaces with show ip eigrp interfaces
R2# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 0 0/0 0 0/0 0 0
Gi1/0 1 0/0 78 0/0 300 0
The output of show ip protocols displays the interfaces that are running EIGRP as a result of the network commands. It is not obvious at first unless someone tells you. The reason it’s not obvious is that it’s not displayed properly. Focus on the highlighted text in Example 4-5. Notice that it states Routing for Networks. Those are not the networks you are routing for. Rather, you are routing for the networks associated with the interface on which EIGRP will be enabled, based on the network commands. In this case, 10.1.1.1/32 really means network 10.1.1.1 0.0.0.0, and 10.1.12.1/32 really means network 10.1.12.1 0.0.0.0. Therefore, a better option is to use the show run | section router eigrp command, as displayed in Example 4-6.
Example 4-5 Verifying Network Statements with show ip protocols
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
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(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.1.12.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.1.1.1/32
10.1.12.1/32
Routing Information Sources:
Gateway Distance Last Update
10.1.12.2 90 09:54:36
Distance: internal 90 external 170
Example 4-6 Verifying network Statements with show run | section router eigrp
R1# show run | section router eigrp router eigrp 100 network 10.1.1.1 0.0.0.0 network 10.1.12.1 0.0.0.0
Notice that the network statement is extremely important. If it is misconfigured, interfaces that should be participating in the EIGRP process might not be, and interfaces that should not be participating in the EIGRP process might be. So, you should be able to recognize issues related to the network statement.
When using the debug eigrp packets command on the router with the misconfigured or missing network statement, you will notice that hello packets are not being sent out the interface properly. For example, if you expect hello packets to be sent out Gig1/0, but the debug eigrp packets command is not indicating that this is happening, it is possible that the interface is not participating in the EIGRP process because of a bad network statement or the interface is passive and suppressing hello packets.
Mismatched K Values
The K values that are used for metric calculation must match between neighbors in order for an adjacency to form. You can verify whether K values match by using show ip protocols, as shown in Example 4-7. The default K values are highlighted in Example 4-7. Usually there is no need to change the K values. However, if they are changed, you need to make them match on every router in the autonomous system. You can use the spot-the-difference method when determining whether K values do not match between routers. In addition, if you are logging syslog messages with a severity level of 5, you receive a message similar to the following:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.12.2 (GigabitEthernet1/0) is down: K-value mismatch
Example 4-7 Verifying K Values with show ip protocols
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
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(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.1.12.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.1.1.1/32
10.1.12.1/32
Routing Information Sources:
Gateway Distance Last Update
10.1.12.2 90 09:54:36
Distance: internal 90 external 170
Passive Interface
The passive interface feature is a must have for all organizations. It does two things:
Reduces the EIGRP-related traffic on a network
Improves EIGRP security
The passive interface feature turns off the sending and receiving of EIGRP packets on an interface while still allowing the interface’s network ID to be injected into the EIGRP process and advertised to other EIGRP neighbors. This ensures that rogue routers attached to the LAN will not be able to form an adjacency with your legitimate router on that interface because it is not sending or receiving EIGRP packets on the interface. However, if you configure the wrong interface as passive, a legitimate EIGRP neighbor relationship will not be formed. As shown in the show ip protocols output in Example 4-8, Gigabit Ethernet 0/0 is a passive interface. If there are no passive interfaces, the passive interface section does not appear in the show ip protocols output.
Example 4-8 Verifying Passive Interfaces with show ip protocols
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
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(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.1.12.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.1.1.1/32
10.1.12.1/32
Passive Interface(s):
GigabitEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
10.1.12.2 90 11:00:14
Distance: internal 90 external 170
Remember that for EIGRP, passive interfaces do not appear in the EIGRP interface table. Therefore, before you jump to the conclusion that the wrong network command was used and the interface was not enabled for EIGRP, you need to check to see whether the interface is passive.
When using the debug eigrp packets command on the router with the passive interface, notice that hello packets are not being sent out that interface. For example, if you expect hello packets to be sent out Gig1/0 but the debug eigrp packets command is not indicating so, it is possible that the interface is participating in the EIGRP process but is configured as a passive interface.
Different Subnets
To form an EIGRP neighbor adjacency, the router interfaces must be on the same subnet. You can confirm this in many ways. The simplest way is to look at the interface configuration in the running configuration with the show run interface interface_type interface_number command. You can also use the show ip interface interface_type interface_number command or the show interface interface_type interface_number command. Example 4-9 shows the configuration of Gig1/0 on R1 and Gig0/0 on R2. Are they in the same subnet? Yes! Based on the IP address and the subnet mask, they are both in the 10.1.12.0/24 subnet. However, if they are not in the same subnet and you have syslog set up for a severity level of 6, you get a message similar to the following:
%DUAL-6-NBRINFO: EIGRP-IPv4 100: Neighbor 10.1.21.2 (GigabitEthernet1/0) is blocked: not on common subnet (10.1.12.1/24)
Example 4-9 Verifying IPv4 Addresses and Masks on Router Interfaces
R1# show running-config interface gigabitEthernet 1/0 Building configuration... Current configuration : 90 bytes ! interface GigabitEthernet1/0 ip address 10.1.12.1 255.255.255.0 negotiation auto end R2# show running-config interface gigabitEthernet 0/0 Building configuration... Current configuration : 132 bytes ! interface GigabitEthernet0/0 ip address 10.1.12.2 255.255.255.0 negotiation auto end
Authentication
Authentication is used to ensure that EIGRP routers form neighbor relationships only with legitimate routers and that they only accept EIGRP packets from legitimate routers. Therefore, if authentication is implemented, both routers must agree on the settings for a neighbor relationship to form. With authentication, you can use the spot-the-difference method. Example 4-10 shows the output of the commands show run interface interface_type interface_number and show ip eigrp interfaces detail interface_type interface_number, which identify whether EIGRP authentication is enabled on the interface. According to the highlighted text, it is. Note that the authentication must be configured on the correct interface and that it must be tied to the correct autonomous system number. If you put in the wrong autonomous system number, it will not be enabled for the correct autonomous system. In addition, make sure that you specify the correct keychain that will be used for the Message Digest 5 (MD5) authentication hash. You can verify the keychain with the command show key chain, as shown in Example 4-11. The keys in this example do not expire. However, if you have implemented rotating keys, the keys must be valid for authentication to be successful.
Example 4-10 Verifying EIGRP Authentication on an Interface
R1# show run interface gig 1/0 Building configuration... Current configuration : 178 bytes ! interface GigabitEthernet1/0 ip address 10.1.12.1 255.255.255.0 ip authentication mode eigrp 100 md5 ip authentication key-chain eigrp 100 EIGRP_AUTH negotiation auto end R1# show ip eigrp interfaces detail gigabitEthernet 1/0 EIGRP-IPv4 Interfaces for AS(100) Xmit Queue PeerQ Mean Pacing Time Multicast Pending Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes Gi1/0 1 0/0 0/0 87 0/0 376 0 Hello-interval is 5, Hold-time is 15 Split-horizon is enabled Next xmit serial <none> Packetized sent/expedited: 2/0 Hello's sent/expedited: 17/2 Un/reliable mcasts: 0/3 Un/reliable ucasts: 2/2 Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0 Retransmissions sent: 1 Out-of-sequence rcvd: 1 Topology-ids on interface - 0 Authentication mode is md5, key-chain is "EIGRP_AUTH"
Example 4-11 Verifying the Keychain Used for EIGRP Authentication
R1# show key chain Key-chain EIGRP_AUTH: key 1 -- text "ENARSI" accept lifetime (always valid) - (always valid) [valid now] send lifetime (always valid) - (always valid) [valid now]
Inside the keychain, you find the key ID (1 in this case) and the key string (ENARSI in this case). It is mandatory that the key ID in use and the key string in use between neighbors match. Therefore, if you have multiple keys and key strings in a chain, the same key and string must be used at the same time by both routers (meaning they must be valid and in use); otherwise, authentication will fail.
When using the debug eigrp packets command for troubleshooting authentication, you receive output based on the authentication issue. Example 4-12 shows the message that is generated when the neighbor is not configured for authentication. It ignores that packet and states (missing authentication). When the key IDs or the key strings do not match between the neighbors, the debug output states (invalid authentication), as shown in Example 4-13.
Example 4-12 Debug Output When Authentication Is Missing on the Neighbor
R1# debug eigrp packets
(UPDATE, REQUEST, QUERY, REPLY, HELLO, UNKNOWN, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on
R1#
EIGRP: Sending HELLO on Gi1/0 - paklen 60
AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
EIGRP: Gi1/0: ignored packet from 10.1.12.2, opcode = 5 (missing authentication)
EIGRP: Sending HELLO on Gi0/0 - paklen 20
AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
R1# u all
All possible debugging has been turned off
Example 4-13 Debug Output When Key IDs or Key Strings Do Not Match
R1# debug eigrp packets
(UPDATE, REQUEST, QUERY, REPLY, HELLO, UNKNOWN, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on
R1#
EIGRP: pkt authentication key id = 2, key not defined
EIGRP: Gi1/0: ignored packet from 10.1.12.2, opcode = 5 (invalid authentication)
EIGRP: Sending HELLO on Gi0/0 - paklen 20
AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
EIGRP: Sending HELLO on Gi1/0 - paklen 60
AS 100, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
R1# u all
All possible debugging has been turned off
ACLs
Access control lists (ACLs) are extremely powerful. How they are implemented determines what they are controlling in a network. If there is an ACL applied to an interface and the ACL is denying EIGRP packets, or if an EIGRP packet falls victim to the implicit deny all at the end of the ACL, a neighbor relationship does not form. To determine whether an ACL is applied to an interface, use the show ip interface interface_type interface_number command, as shown in Example 4-14. Notice that ACL 100 is applied inbound on interface Gig1/0. To verify the ACL 100 entries, issue the command show access-lists 100, as shown in Example 4-15. In this case, you can see that ACL 100 is denying EIGRP traffic; this prevents a neighbor relationship from forming. Note that outbound ACLs do not affect EIGRP packets; only inbound ACLs do. Therefore, any outbound ACLs that deny EIGRP packets have no effect on your EIGRP troubleshooting efforts.
Example 4-14 Verifying ACLs Applied to Interfaces
R1# show ip interface gig 1/0
GigabitEthernet1/0 is up, line protocol is up
Internet address is 10.1.12.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 100
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
Example 4-15 Verifying ACL Entries
R1# show access-lists 100
Extended IP access list 100
10 deny eigrp any any (62 matches)
20 permit ip any any
Timers
Although EIGRP timers do not have to match, if the timers are skewed enough, an adjacency will flap. For example, suppose that R1 is using the default timers of 5 and 15, while R2 is sending hello packets every 20 seconds. R1’s hold time will expire before it receives another hello packet from R2; this terminates the neighbor relationship. Five seconds later, the hello packet arrives, and the neighbor relationship is formed, but it is then terminated again 15 seconds later.
Although timers do not have to match, it is important that routers send hello packets at a rate that is faster than the hold timer. You verify the configured timers with the show ip eigrp interfaces detail command, as shown in Example 4-10.
Troubleshooting EIGRP for IPv4 Routes
After establishing a neighbor relationship, an EIGRP router performs a full exchange of routing information with the newly established neighbor. After the full exchange, only updates to route information are exchanged with that neighbor. Routing information learned from EIGRP neighbors is inserted into the EIGRP topology table. If the EIGRP information for a specific route happens to be the best source of information, it is installed in the routing table. There are various reasons EIGRP routes might be missing from either the topology table or the routing table, and you need to be aware of them if you plan on successfully troubleshooting EIGRP route-related problems. This section examines the reasons EIGRP routes might be missing and how to determine why they are missing.
EIGRP only learns from directly connected neighbors, which makes it easy to follow the path of routes when troubleshooting. For example, if R1 does not know about the route but its neighbor does, there is probably something wrong between the neighbors. However, if the neighbor does not know about it either, you can focus on the neighbor’s neighbor and so on.
As discussed earlier, neighbor relationships are the foundation of EIGRP information sharing. If there are no neighbors, you do not learn any routes. So, besides the lack of a neighbor, what would be reasons for missing routes in an EIGRP network? The following are some common reasons EIGRP routes might be missing either from the topology table or the routing table:
Bad or missing network command: The network command enables the EIGRP process on an interface and injects the prefix of the network the interface is part of into the EIGRP process.
Better source of information: If exactly the same network prefix is learned from a more reliable source, it is used instead of the EIGRP learned information.
Route filtering: A filter might be preventing a network prefix from being advertised or learned.
Stub configuration: If the wrong setting is chosen during the stub router configuration, or if the wrong router is chosen as the stub router, it might prevent a network prefix from being advertised.
Interface is shut down: The EIGRP-enabled interface must be up/up for the network associated with the interface to be advertised.
Split horizon: Split horizon is a loop-prevention feature that prevents a router from advertising routes out the same interface on which they were learned.
This section looks at each of these reasons individually and explores how to recognize them during the troubleshooting process.
Bad or Missing network Command
When you use the network command, the EIGRP process is enabled on the interfaces that fall within the range of IP addresses identified by the command. EIGRP then takes the network/subnet the interface is part of and injects it into the topology table so that it can be advertised to other routers in the autonomous system. Therefore, even interfaces that do not form neighbor relationships with other routers need a valid network statement that enables EIGRP on those interfaces so the networks the interfaces belong to are injected into the EIGRP process and advertised. If the network statement is missing or configured incorrectly, EIGRP is not enabled on the interface, and the network the interface belongs to is never advertised and is therefore unreachable by other routers.
As discussed earlier in this chapter, the output of show ip protocols displays the network statements in a nonintuitive way. Focus on the highlighted text in Example 4-16. Notice that it states Routing for Networks. Those are not the networks you are routing for. You are routing for the networks associated with the interface on which EIGRP will be enabled, based on the network statement. In this case, 10.1.1.1/32 really means network 10.1.1.1 0.0.0.0, and 10.1.12.1/32 really means network 10.1.12.1 0.0.0.0.
Example 4-16 Verifying network Statements with show ip protocols
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
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(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.1.12.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.1.1.1/32
10.1.12.1/32
Routing Information Sources:
Gateway Distance Last Update
10.1.12.2 90 09:54:36
Distance: internal 90 external 170
So what networks are you actually routing for then? You are routing for the networks associated with the interfaces that are now enabled for EIGRP. In Example 4-17, you can see the output of the show ip interface command on R1 for Gig0/0 and Gig1/0, which was piped to include only the Internet address. Notice that that these two interfaces are in a /24 network. As a result, the network IDs would be 10.1.1.0/24 and 10.1.12.0/24. Those are the networks you are routing for.
Example 4-17 Verifying Network IDs with show ip interface
R1# show ip interface gi0/0 | i Internet Internet address is 10.1.1.1/24 R1# show ip interface gi1/0 | i Internet Internet address is 10.1.12.1/24
Therefore, if you expect to route for the network 10.1.1.0/24 or 10.1.12.0/24, as in this case, you better have a network statement that enables the EIGRP process on the router interfaces in those networks.
You can confirm which interfaces are participating in the EIGRP process by using the show ip eigrp interfaces command, as shown earlier in Example 4-4.
Better Source of Information
For an EIGRP-learned route to be installed in the routing table, it must be the most trusted routing source. Recall that the trustworthiness of a source is based on administrative distance (AD). EIGRP’s AD is 90 for internally learned routes (networks inside the autonomous system) and 170 for externally learned routes (networks outside the autonomous system). Therefore, if there is another source that is educating the same router about exactly the same network and that source has a better AD, the source with the better AD wins, and its information is installed in the routing table. Compare Example 4-18, which is an EIGRP topology table, and Example 4-19, which is the routing table displaying only the EIGRP installed routes on the router. Focus on the highlighted networks of the topology table. Do you see them listed as EIGRP routes in the routing table?
Example 4-18 Sample show ip eigrp topology Command Output
Router# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(192.4.4.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 172.16.33.8/30, 2 successors, FD is 2681856
via 172.16.33.6 (2681856/2169856), Serial1/0
via 172.16.33.18 (2681856/2169856), Serial1/2
P 10.1.34.0/24, 1 successors, FD is 2816
via Connected, GigabitEthernet2/0
P 192.7.7.7/32, 1 successors, FD is 2300416
via 172.16.33.5 (2300416/156160), Serial1/0
via 172.16.33.6 (2809856/2297856), Serial1/0
via 172.16.33.18 (2809856/2297856), Serial1/2
P 192.4.4.4/32, 1 successors, FD is 128256
via Connected, Loopback0
P 172.16.33.16/30, 1 successors, FD is 2169856
via Connected, Serial1/2
P 172.16.32.0/25, 2 successors, FD is 2172416
via 172.16.33.6 (2172416/28160), Serial1/0
via 172.16.33.18 (2172416/28160), Serial1/2
P 10.1.23.0/24, 1 successors, FD is 3072
via 10.1.34.3 (3072/2816), GigabitEthernet2/0
P 203.0.113.0/30, 1 successors, FD is 28160
via Connected, FastEthernet3/0
P 192.5.5.5/32, 1 successors, FD is 2297856
via 172.16.33.5 (2297856/128256), Serial1/0
P 192.3.3.3/32, 1 successors, FD is 130816
via 10.1.34.3 (130816/128256), GigabitEthernet2/0
P 192.2.2.2/32, 1 successors, FD is 131072
via 10.1.34.3 (131072/130816), GigabitEthernet2/0
P 10.1.13.0/24, 1 successors, FD is 3072
via 10.1.34.3 (3072/2816), GigabitEthernet2/0
P 0.0.0.0/0, 1 successors, FD is 28160
via Rstatic (28160/0)
P 192.1.1.1/32, 1 successors, FD is 131072
via 10.1.34.3 (131072/130816), GigabitEthernet2/0
P 172.16.32.192/29, 1 successors, FD is 2174976
via 172.16.33.5 (2174976/30720), Serial1/0
via 172.16.33.6 (2684416/2172416), Serial1/0
via 172.16.33.18 (2684416/2172416), Serial1/2
P 198.51.100.0/30, 1 successors, FD is 28416
via 10.1.34.3 (28416/28160), GigabitEthernet2/0
P 172.16.33.12/30, 1 successors, FD is 2172416
via 172.16.33.5 (2172416/28160), Serial1/0
P 192.6.6.6/32, 2 successors, FD is 2297856
via 172.16.33.6 (2297856/128256), Serial1/0
via 172.16.33.18 (2297856/128256), Serial1/2
P 172.16.33.0/29, 1 successors, FD is 2169856
via Connected, Serial1/0
P 10.1.1.0/26, 1 successors, FD is 3328
via 10.1.34.3 (3328/3072), GigabitEthernet2/0
P 172.16.32.128/26, 1 successors, FD is 2172416
via 172.16.33.5 (2172416/28160), Serial1/0
Example 4-19 Sample show ip route eigrp Command Output
Router# show ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 203.0.113.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
D 10.1.1.0/26 [90/3328] via 10.1.34.3, 00:49:19, GigabitEthernet2/0
D 10.1.13.0/24 [90/3072] via 10.1.34.3, 00:49:22, GigabitEthernet2/0
D 10.1.23.0/24 [90/3072] via 10.1.34.3, 00:49:22, GigabitEthernet2/0
172.16.0.0/16 is variably subnetted, 9 subnets, 5 masks
D 172.16.32.0/25 [90/2172416] via 172.16.33.18, 00:49:22, Serial1/2
[90/2172416] via 172.16.33.6, 00:49:22, Serial1/0
D 172.16.32.128/26 [90/2172416] via 172.16.33.5, 00:49:23, Serial1/0
D 172.16.32.192/29 [90/2174976] via 172.16.33.5, 00:49:23, Serial1/0
D 172.16.33.8/30 [90/2681856] via 172.16.33.18, 00:49:22, Serial1/2
[90/2681856] via 172.16.33.6, 00:49:22, Serial1/0
D 172.16.33.12/30 [90/2172416] via 172.16.33.5, 00:49:23, Serial1/0
192.1.1.0/32 is subnetted, 1 subnets
D 192.1.1.1 [90/131072] via 10.1.34.3, 00:49:19, GigabitEthernet2/0
192.2.2.0/32 is subnetted, 1 subnets
D 192.2.2.2 [90/131072] via 10.1.34.3, 00:49:19, GigabitEthernet2/0
192.3.3.0/32 is subnetted, 1 subnets
D 192.3.3.3 [90/130816] via 10.1.34.3, 00:49:22, GigabitEthernet2/0
192.5.5.0/32 is subnetted, 1 subnets
D 192.5.5.5 [90/2297856] via 172.16.33.5, 00:49:23, Serial1/0
192.6.6.0/32 is subnetted, 1 subnets
D 192.6.6.6 [90/2297856] via 172.16.33.18, 00:49:22, Serial1/2
[90/2297856] via 172.16.33.6, 00:49:22, Serial1/0
192.7.7.0/32 is subnetted, 1 subnets
D 192.7.7.7 [90/2300416] via 172.16.33.5, 00:49:23, Serial1/0
198.51.100.0/30 is subnetted, 1 subnets
D 198.51.100.0 [90/28416] via 10.1.34.3, 00:49:22, GigabitEthernet2/0
None of the highlighted routes in Example 4-18 appear in the routing table as EIGRP routes. In this case, there is a better source for the same information. Example 4-20, which displays the output of the show ip route 172.16.33.16 255.255.255.252 command, identifies that this network is directly connected and has an AD of 0. Because a directly connected network has an AD of 0, and an internal EIGRP route has an AD of 90, the directly connected source is installed in the routing table. Refer to Example 4-18 and focus on the 0.0.0.0/0 route. Notice that it says Rstatic, which means that the route was redistributed from a static route on this router. Therefore, there is a static default route on the local router with a better AD than the EIGRP default route, which would have an AD of 170. As a result, the EIGRP 0.0.0.0/0 route would not be installed in the routing table, and the static default route would be.
Example 4-20 Sample show ip route 172.16.33.16 255.255.255.252 Command Output
Router# show ip route 172.16.33.16 255.255.255.252 Routing entry for 172.16.33.16/30 Known via "connected", distance 0, metric 0 (connected, via interface) ...output omitted...
Using a suboptimal source of routing information may not cause users to complain or submit a trouble ticket because they will probably still be able to access the resources they need. However, it may cause suboptimal routing in the network. Figure 4-1 shows a network running two different routing protocols. In this case, which path will be used to send traffic from PC1 to 10.1.1.0/24? If you said the longer EIGRP path, you are correct. Even though it is quicker to use the Open Shortest Path First (OSPF) path, EIGRP wins by default because it has the lower AD, and suboptimal routing occurs.
Figure 4-1 Using the Suboptimal EIGRP Path
Being able to recognize when a certain routing source should be used and when it should not be used is key to optimizing your network and reducing the number of troubleshooting instances related to the network being perceived as slow. In this case, you might want to consider increasing the AD of EIGRP or lowering the AD of OSPF to optimize routing.
Route Filtering
A distribute list applied to an EIGRP process controls which routes are advertised to neighbors and which routes are received from neighbors. The distribute list is applied in EIGRP configuration mode either inbound or outbound, and the routes sent or received are controlled by ACLs, prefix lists, or route maps. So, when troubleshooting route filtering, you need to consider the following:
Is the distribute list applied in the correct direction?
Is the distribute list applied to the correct interface?
If the distribute list is using an ACL, is the ACL correct?
If the distribute list is using a prefix list, is the prefix list correct?
If the distribute list is using a route map, is the route map correct?
The show ip protocols command identifies whether a distribute list is applied to all interfaces or to an individual interface, as shown in Example 4-21. This example indicates that there are no outbound filters and that there is an inbound filter on Gig1/0.
Example 4-21 Verifying Route Filters with show ip protocols
R1# show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "eigrp 100" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set GigabitEthernet1/0 filtered by 10 (per-user), default is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP-IPv4 Protocol for AS(100) Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 NSF-aware route hold timer is 240 Router-ID: 10.1.12.1 ...output omitted...
The inbound filter in Example 4-21 on Gig1/0 is filtering with ACL 10. To verify the entries in the ACL, you must issue the show access-lists 10 command. If a prefix list was applied, you issue the show ip prefix-list command. If a route map was applied, you issue the show route-map command.
As shown in Example 4-22, you verify the command that was used to apply the distribute list in the running configuration by reviewing the EIGRP configuration section.
Example 4-22 Verifying EIGRP distribute-list Command
R1# show run | section router eigrp
router eigrp 100
distribute-list 10 in GigabitEthernet1/0
network 10.1.1.1 0.0.0.0
network 10.1.12.1 0.0.0.0
passive-interface GigabitEthernet0/0
Stub Configuration
The EIGRP stub feature allows you to control the scope of EIGRP queries in the network. Figure 4-2 shows the failure of network 192.168.1.0/24 on R1 that causes a query to be sent to R2 and then a query from R2 to be sent to R3 and R4. However, the query to R3 is not needed because R3 will never have alternate information about the 192.168.1.0/24 network. The query wastes resources and slows convergence. As shown in Figure 4-3, configuring the EIGRP stub feature on R3 with the eigrp stub command ensures that R2 never sends a query to R3.
Figure 4-2 Query Scope Without the EIGRP Stub Feature
Figure 4-3 Query Scope with the EIGRP Stub Feature
This feature comes in handy over slow hub-and-spoke WAN links, as shown in Figure 4-4. The stub feature prevents the hub from querying the spokes, which reduces the amount of EIGRP traffic sent over the link. In addition, it reduces the chance of a route being stuck in active (SIA). SIA happens when a router does not receive a reply to a query that it sent. Over WANs, this can happen due to congestion, and it can result in the reestablishment of neighbor relationships, causing convergence and generating even more EIGRP traffic. Therefore, if you do not query the hubs, you do not have to worry about these issues.
Figure 4-4 EIGRP Stub Feature over WAN Links
When configuring the EIGRP stub feature, you can control what routes the stub router advertises to its neighbor. By default, it advertises connected and summary routes. However, you have the option of advertising connected, summary, redistributed, or static—or a combination of these. The other option is to send no routes (called receive only). If the wrong option is chosen, the stub routers do not advertise the correct routes to their neighbors, resulting in missing routes on the hub and other routers in the topology. In addition, if you configure the wrong router as the stub router (for example, R1 in Figure 4-4), R1 never fully shares all routes it knows about to R4, R2, and R3, resulting in missing routes in the topology. To verify whether a router is a stub router and determine the routes it will advertise, issue the show ip protocols command, as shown in Example 4-23.
Example 4-23 show ip protocols Command Output on R2
R2# show ip protocols
...output omitted...
EIGRP-IPv4 Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 192.1.1.1
Stub, connected, summary
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
...output omitted...
To determine whether a neighbor is a stub router and the types of routes it is advertising, issue the command show ip eigrp neighbors detail. Example 4-24 shows the output of show ip eigrp neighbors detail on R1, which indicates that the neighbor is a stub router advertising connected and summary routes and suppressing queries.
Example 4-24 Verifying Whether an EIGRP Neighbor Is a Stub Router
R1# show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.13.1 Se1/0 14 00:00:18 99 594 0 11
Version 11.0/2.0, Retrans: 0, Retries: 0, Prefixes: 2
Topology-ids from peer - 0
Stub Peer Advertising (CONNECTED SUMMARY ) Routes
Suppressing queries
...output omitted...
Interface Is Shut Down
As discussed earlier, the network command enables the routing process on an interface. Once the EIGRP process is enabled on the interface, the network the interface is part of (that is, the directly connected entry in the routing table) is injected into the EIGRP process. If the interface is shut down, there is no directly connected entry for the network in the routing table. Therefore, the network does not exist, and there is no network that can be injected into the EIGRP process. The interface must be up/up for routes to be advertised or for neighbor relationships to be formed.
Split Horizon
The EIGRP split-horizon rule states that any routes learned inbound on an interface will not be advertised out the same interface. This rule is designed to prevent routing loops. However, this rule presents an issue in certain topologies. Figure 4-5 shows a nonbroadcast multi-access (NBMA) Frame Relay hub-and-spoke topology or a Dynamic Multipoint Virtual Private Network (DMVPN) network, which both use multipoint interfaces on the hub. The multipoint interface (a single physical interface or a mGRE tunnel interface) provides connectivity to multiple routers in the same subnet out the single interface, as does Ethernet. In this figure, R2 is sending an EIGRP update to R1 on the permanent virtual circuit (PVC) or Generic Routing Encapsulation (GRE) tunnel. Because split horizon is enabled on the Se1/0 interface or the multipoint GRE tunnel interface on R1, R1 does not advertise the 10.1.2.0/24 network back out that interface. Therefore, R3 never learns about 10.1.2.0/24.
Figure 4-5 EIGRP Split Horizon Issue
To verify whether split horizon is enabled on an interface, issue the show ip interface interface_type interface_number command, as shown in Example 4-25. In this case, you can see that split horizon is enabled.
Example 4-25 Verifying Whether Split Horizon Is Enabled on an Interface
R1# show ip interface tunnel 0
Tunnel0 is up, line protocol is up
Internet address is 192.168.1.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1476 bytes
Helper address is not set
Directed broadcast forwarding is disabled
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
ICMP redirects are never sent
...output omitted...
To completely disable split horizon on an interface, issue the no ip split-horizon command in interface configuration mode. If you only want to disable it for the EIGRP process running on the interface, issue the command no ip split-horizon eigrp autonomous_system_number.
If you disable split horizon for the EIGRP process, it still shows as enabled in the output of show ip interface (refer to Example 4-25). To verify whether split horizon is enabled or disabled for the EIGRP process on an interface, issue the command show ip eigrp interfaces detail interface_type interface_number. Example 4-26 shows that it is disabled for EIGRP on interface tunnel 0.
Example 4-26 Verifying Whether Split Horizon Is Enabled for EIGRP on an Interface
R1# show ip eigrp interfaces detail tunnel 0
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Tu0 0 0/0 0 6/6 0 0
Hello-interval is 5, Hold-time is 15
Split-horizon is disabled
Next xmit serial <none>
Packetized sent/expedited: 0/0
Hello's sent/expedited: 17/1
Un/reliable mcasts: 0/0 Un/reliable ucasts: 0/0
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 0 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is not set
Troubleshooting Miscellaneous EIGRP for IPv4 Issues
So far in this chapter, the focus has been on troubleshooting EIGRP neighbor relationships and routes. In this section, the focus is on troubleshooting issues related to feasible successors, discontiguous networks and autosummarization, route summarization, and equal- and unequal-metric load balancing.
Feasible Successors
The best route (based on the lowest feasible distance [FD] metric) for a specific network in the EIGRP topology table becomes a candidate to be injected into the router’s routing table. (The term candidate is used because even though it is the best EIGRP route, a better source of the same information might be used instead.) If that route is indeed injected into the routing table, that route becomes known as the successor (best) route. This is the route that is then advertised to neighboring routers. Example 4-27 shows a sample EIGRP topology table, which you can view by issuing the show ip eigrp topology command. Focus on the entry for 172.16.32.192/29. Notice that there are three paths to reach that network. However, based on the fact that it states 1 successors, only one path is being used as the best path. It is the one with the lowest FD, 2174976, which is the path through 172.16.33.5, reachable out interface Serial 1/0.
Example 4-27 Sample show ip eigrp topology Command Output
R4# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(192.4.4.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
...output omitted...
P 10.1.13.0/24, 1 successors, FD is 3072
via 10.1.34.3 (3072/2816), GigabitEthernet2/0
P 0.0.0.0/0, 1 successors, FD is 28160
via Rstatic (28160/0)
P 192.1.1.1/32, 1 successors, FD is 131072
via 10.1.34.3 (131072/130816), GigabitEthernet2/0
P 172.16.32.192/29, 1 successors, FD is 2174976
via 172.16.33.5 (2174976/30720), Serial1/0
via 172.16.33.6 (2684416/2172416), Serial1/0
via 172.16.33.18 (2684416/2172416), Serial1/2
P 198.51.100.0/30, 1 successors, FD is 28416
via 10.1.34.3 (28416/28160), GigabitEthernet2/0
P 172.16.33.12/30, 1 successors, FD is 2172416
via 172.16.33.5 (2172416/28160), Serial1/0
...output omitted...
In the brackets after the next-hop IP address is the FD followed by the reported distance (RD):
Feasible distance: The RD plus the metric to reach the neighbor at the next-hop address that is advertising the RD
Reported distance: The distance from the neighbor at the next-hop address to the destination network
The successor is the path with the lowest FD. However, EIGRP also pre-calculates paths that could be used if the successor disappeared. These are known as the feasible successors. To be a feasible successor, the RD of the path to become a feasible successor must be less than the FD of the successor. Review Example 4-27. The path through 172.16.33.5 is the successor. However, are the paths using 172.16.33.6 and 172.16.33.18 feasible successors (backups)? To determine this, take the RD of these paths (in this case, it is the same [2172416]), and compare it to the FD of the successor (2174976). Is the RD less than the FD? Yes. Therefore, they are feasible successors.
For troubleshooting, it is important to note that the output of show ip eigrp topology only displays the successors and feasible successors. If you need to verify the FD or RD of other paths to the same destination that are not feasible successors, you can use the show ip eigrp topology all-links command. Example 4-28 displays the output of show ip eigrp topology and show ip eigrp topology all-links. Focus on the entry for 10.1.34.0/24. In the output of show ip eigrp topology, notice that there is only one path listed; in the output of show ip eigrp topology all-links, notice that there are two paths listed. This is because the next hop 172.16.33.13 has an RD greater than the FD of the successor and therefore cannot be a feasible successor.
Example 4-28 Sample show ip eigrp topology Comparison
Router# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(172.16.33.14)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 172.16.33.8/30, 1 successors, FD is 2169856
via Connected, Serial1/0
P 10.1.34.0/24, 1 successors, FD is 2682112
via 172.16.33.9 (2682112/2170112), Serial1/0
P 203.0.113.0/30, 1 successors, FD is 2684416
via 172.16.33.9 (2684416/2172416), Serial1/0
P 172.16.32.192/29, 1 successors, FD is 28160
via Connected, FastEthernet2/0
P 172.16.33.12/30, 1 successors, FD is 5511936
via Connected, Serial1/1
P 172.16.33.0/29, 1 successors, FD is 2681856
via 172.16.33.9 (2681856/2169856), Serial1/0
Router# show ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(100)/ID(172.16.33.14)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 172.16.33.8/30, 1 successors, FD is 2169856, serno 1
via Connected, Serial1/0
P 10.1.34.0/24, 1 successors, FD is 2682112, serno 8
via 172.16.33.9 (2682112/2170112), Serial1/0
via 172.16.33.13 (6024192/3072256), Serial1/1
P 203.0.113.0/30, 1 successors, FD is 2684416, serno 9
via 172.16.33.9 (2684416/2172416), Serial1/0
via 172.16.33.13 (6026496/3074560), Serial1/1
P 172.16.32.192/29, 1 successors, FD is 28160, serno 3
via Connected, FastEthernet2/0
P 172.16.33.12/30, 1 successors, FD is 5511936, serno 2
via Connected, Serial1/1
P 172.16.33.0/29, 1 successors, FD is 2681856, serno 5
via 172.16.33.9 (2681856/2169856), Serial1/0
via 172.16.33.13 (6023936/3072000), Serial1/1
The EIGRP topology table contains not only the routes learned from other routers but also routes that have been redistributed into the EIGRP process and the local connected networks whose interfaces are participating in the EIGRP process, as highlighted in Example 4-29.
Example 4-29 Verifying Connected and Redistributed Entries in the Topology Table
R4# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(192.4.4.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
...output omitted...
P 192.2.2.2/32, 1 successors, FD is 131072
via 10.1.34.3 (131072/130816), GigabitEthernet2/0
P 10.1.13.0/24, 1 successors, FD is 3072
via 10.1.34.3 (3072/2816), GigabitEthernet2/0
P 0.0.0.0/0, 1 successors, FD is 28160
via Rstatic (28160/0)
P 192.1.1.1/32, 1 successors, FD is 131072
via 10.1.34.3 (131072/130816), GigabitEthernet2/0
P 172.16.32.192/29, 1 successors, FD is 2174976
via 172.16.33.5 (2174976/30720), Serial1/0
via 172.16.33.6 (2684416/2172416), Serial1/0
via 172.16.33.18 (2684416/2172416), Serial1/2
P 198.51.100.0/30, 1 successors, FD is 28416
via 10.1.34.3 (28416/28160), GigabitEthernet2/0
P 172.16.33.12/30, 1 successors, FD is 2172416
via 172.16.33.5 (2172416/28160), Serial1/0
P 192.6.6.6/32, 2 successors, FD is 2297856
via 172.16.33.6 (2297856/128256), Serial1/0
via 172.16.33.18 (2297856/128256), Serial1/2
P 172.16.33.0/29, 1 successors, FD is 2169856
via Connected, Serial1/0
...output omitted...
Discontiguous Networks and Autosummarization
EIGRP supports variable-length subnet masking (VLSM). In earlier releases of Cisco IOS (before release 15.0), EIGRP automatically performed route summarization at classful network boundaries. This was an issue in networks containing discontiguous networks. As a result, it was necessary when configuring EIGRP to turn off automatic summarization by using the no auto-summary command in router configuration mode for an EIGRP autonomous system. However, from Cisco IOS 15.0 onward, automatic summarization is off by default for EIGRP. Therefore, you do not have to worry about issuing the no auto-summary command anymore. However, you should be able to recognize a discontiguous network when reviewing a network topology and understand that if someone manually enabled autosummarization in your EIGRP autonomous system, routing would be broken.
Figure 4-6 provides an example of a discontiguous network. The 172.16.0.0/16 Class B classful network is considered discontiguous because it is subnetted as 172.16.1.0/24 and 172.16.2.0/24, and the subnets are separated from each other by a different classful network, which is 10.0.0.0. With automatic summarization turned on, when R3 advertises the 172.16.2.0/24 network to R2, it is summarized to 172.16.0.0/16 because it is being sent out an interface in a different classful network. So, instead of 172.16.2.0/24 being sent, 172.16.0.0/16 is sent. Likewise, the same thing happens when R1 advertises the 172.16.1.0/24 network to R2; it is advertised as 172.16.0.0/16. If you reviewed R2’s routing table, you would see an entry for 172.16.0.0 with two next hops (if everything else is equal): one through R3 using Fa0/1 and the other through R1 using Fa0/0.
Figure 4-6 Discontiguous Network Example
Now picture a packet arriving at R2 from R4 with the destination IP address 172.16.2.5. Which way does R2 send it? You see the problem? It should send it out Fa0/1, but it could send it out Fa0/0. There is a 50/50 chance it gets it correct. The moral of this story is this: If you have a discontiguous network, autosummarization has to be off, and you must take care when performing manual summarization. To verify whether automatic summarization is enabled or disabled, use the show ip protocols command, as shown in Example 4-30.
Example 4-30 Verifying Route Summarization with show ip protocols
Router# show ip protocols ...output omitted... EIGRP-IPv4 Protocol for AS(100) Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 NSF-aware route hold timer is 240 Router-ID: 10.1.13.1 Topology : 0 (base) Active Timer: 3 min Distance: internal 90 external 170 Maximum path: 4 Maximum hopcount 100 Maximum metric variance 1 Automatic Summarization: disabled Address Summarization: 10.1.0.0/20 for Gi2/0 Summarizing 2 components with metric 2816 Maximum path: 4 Routing for Networks: ...output omitted...
Route Summarization
By default with IOS 15.0 and later, autosummary is off. Therefore, you can either turn it on (which is not recommended) or perform manual route summarization (which is recommended). With EIGRP, manual route summarization is enabled on an interface-by-interface basis. Therefore, when troubleshooting route summarization, keep in mind the following:
Did you enable route summarization on the correct interface?
Did you associate the summary route with the correct EIGRP autonomous system?
Did you create the appropriate summary route?
You determine answers to all these questions by using the show ip protocols command, as shown in Example 4-30. In this example, autosummarization is disabled, and manual summarization is enabled for EIGRP autonomous system 100 on interface Gi2/0 for 10.1.0.0/20.
It is important that you create accurate summary routes to ensure that your router is not advertising networks in the summary route that it does not truly know how to reach. If it does, it is possible that it might receive packets to destinations that fall within the summary that it really does not know how to reach. If this is the case, it means that packets will be dropped because of the route to null 0.
When a summary route is created on a router, so is a summary route to null 0, as shown in the following snippet:
Router# show ip route | include Null D 10.1.0.0/20 is a summary, 00:12:03, Null0
This route to null 0 is created to prevent routing loops. It is imperative that this route exists in the table. It ensures that when a packet is received by the router with a destination address that falls within the summary, the packet will be dropped. If the route to null 0 did not exist, and there was a default route on the router, the router would forward the packet using the default route. The next-hop router would then end up forwarding the packet back to this router because it is using the summary route. The local router would then forward it based on the default route again, and then it would come back. This is a routing loop.
The route to null 0 has an AD of 5, as shown in the following snippet, to ensure that it is more trustworthy than most of the other sources of routing information:
Router# show ip route 10.1.0.0
Routing entry for 10.1.0.0/20
Known via "eigrp 100", distance 5, metric 2816, type internal
Therefore, the only way this route would not be in the routing table is if you had a source with a lower AD (for example, if someone created a static route for the same summary network and pointed it to a next-hop IP address instead of null 0). This would cause a routing loop.
Load Balancing
By default, EIGRP load balances on four equal-metric paths. You can change this with the maximum-paths command in router configuration mode for EIGRP. However, EIGRP also supports load balancing across unequal-metric paths, using the variance feature. By default, the variance value for an EIGRP routing process is 1, which means the load balancing will occur only over equal-metric paths. You issue the variance multiplier command in router configuration mode to specify a range of metrics over which load balancing will occur. For example, suppose that a route has a metric of 200000, and you configure the variance 2 command for the EIGRP routing process. This causes load balancing to occur over any route with a metric in the range of 200000 through 400000 (that is, 2 × 200000). As you can see, a route could have a metric as high as 400000 (that is, the variance multiplier multiplied by the best metric) and still be used.
However, even with unequal-metric load balancing, you are still governed by the maximum-paths command. Therefore, if you have five unequal-metric paths that you want to use, and you configure the correct variance multiplier, but maximum-paths is set to 2, you use only two of the five paths. To use all five, you would also need to make sure that maximum-paths is set to 5.
Also, remember that the feasibility condition plays a huge role in unequal-path load balancing to prevent routing loops. If the path is not a feasible successor, it cannot be used for unequal-path load balancing. There is no exception to this rule. Recall the feasibility condition: To be a feasible successor, the RD must be less than the FD of the successor.
To verify the configured maximum paths and variance, you use the show ip protocols command, as shown in Example 4-31.
Example 4-31 Verifying Variance and Maximum Paths
Router# show ip protocols
Routing Protocol is "eigrp 100"
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(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.1.12.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
0.0.0.0
Routing Information Sources:
Gateway Distance Last Update
10.1.12.2 90 10:26:36
Distance: internal 90 external 170
EIGRP for IPv4 Trouble Tickets
This section presents various trouble tickets related to the topics discussed earlier in the chapter. The purpose of these trouble tickets is to show a process that you can follow when troubleshooting in the real world or in an exam environment. All trouble tickets in this section are based on the topology shown in Figure 4-7.
Figure 4-7 EIGRP for IPv4 Trouble Tickets Topology
Trouble Ticket 4-1
Problem: Users in the 10.1.1.0/24 network indicate that they are not able to access resources in the 10.1.3.0/24 network.
As always, the first item on the list for troubleshooting is to verify the problem. You access a PC in the 10.1.1.0/24 network and ping an IP address in the 10.1.3.0/24 network, and it is successful (0% loss), as shown in Example 4-32. However, notice that the reply is from the default gateway at 10.1.1.1, and it states Destination host unreachable. Therefore, it was technically not successful.
Example 4-32 Destination Unreachable Result from the ping Command on a PC
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data; Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
The result of this ping tells you two very important things: The PC can reach the default gateway, and the default gateway does not know how to get to the 10.1.3.0/24 network. Therefore, you can focus your attention on R1 and work from there.
On R1, you issue the same ping, but it fails, as shown in Example 4-33.
Example 4-33 Failed Ping from R1 to 10.1.3.10
R1# ping 10.1.3.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.3.10, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Next, you check R1’s routing table with the show ip route command and notice that there are only connected routes in the routing table, as shown in Example 4-34. You conclude that R1 is not learning any routes from R2.
Example 4-34 show ip route Output on R1
R1# show ip route
...output omitted...
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
According to Figure 4-7, EIGRP is the routing protocol in use. Therefore, you issue the show ip protocols command to verify that EIGRP is using the correct autonomous system number. Example 4-35 displays the show ip protocols output, which confirms that EIGRP 100 is in operation on R1.
Example 4-35 show ip protocols Output on R1
R1# show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "eigrp 100" 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(100) Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 NSF-aware route hold timer is 240 Router-ID: 10.1.12.1 Topology : 0 (base) Active Timer: 3 min Distance: internal 90 external 170 Maximum path: 4 Maximum hopcount 100 Maximum metric variance 1 Automatic Summarization: disabled Maximum path: 4 Routing for Networks: 10.1.1.1/32 10.1.12.1/32 Routing Information Sources: Gateway Distance Last Update 10.1.12.2 90 00:45:53 Distance: internal 90 external 170
Next, you check to see whether R1 has any EIGRP neighbors. According to the topology, R2 should be a neighbor. To verify EIGRP neighbors, you issue the show ip eigrp neighbors command on R1, as shown in the following snippet:
R1# show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(100)
According to the output, R1 has no neighbors.
Next, you verify whether there are any interfaces participating in the EIGRP process by using the show ip eigrp interfaces command. Example 4-36 indicates that there are two interfaces participating in the EIGRP process: Gi0/0 and Gi1/0.
Example 4-36 show ip eigrp interfaces Output on R1
R1# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 0 0/0 0 0/0 0 0
Gi1/0 0 0/0 0 0/0 304 0
The output of show cdp neighbors, as shown in Example 4-37, indicates that R1 is connected to R2 using Gig 1/0 and that R2 is using Gig 0/0. Therefore, you expect a peering between the two, using these interfaces.
Example 4-37 show cdp neighbors Output on R1
R1# show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, D - Remote, C - CVTA, M - Two-port Mac Relay Device ID Local Intrfce Holdtme Capability Platform Port ID R2 Gig 1/0 172 R 7206VXR Gig 0/0
Now is a great time to verify whether Gi0/0 on R2 is participating in the EIGRP process. On R2, you issue the show ip eigrp interfaces command, as shown in Example 4-38.
Example 4-38 show ip eigrp interfaces Output on R2
R2# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi1/0 0 0/0 0 0/0 4480
Example 4-38 confirms that R2’s interface Gi0/0 is not participating in the EIGRP process.
You review the output of show run | section router eigrp and show ip interface brief on R2, as shown in Example 4-39, and confirm that the wrong network statement was issued on R2. The network statement network 10.1.21.2 0.0.0.0 enables the EIGRP process on the interface with that IP address. According to the output of show ip interface brief, the network statement should be network 10.1.12.2 0.0.0.0, based on the IP address 10.1.12.2 of interface GigabitEthernet0/0.
Example 4-39 show run | section router eigrp Output on R2 and Verifying the Interface IP Address
R2# show run | section router eigrp router eigrp 100 network 10.1.21.2 0.0.0.0 network 10.1.23.2 0.0.0.0 R2# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 10.1.12.2 YES manual up up GigabitEthernet1/0 10.1.23.2 YES manual up up
To fix this issue, on R2 you execute the no network 10.1.21.2 0.0.0.0 command and enter the network 10.1.12.2 0.0.0.0 command in router EIGRP configuration mode instead. After you have done this, the neighbor relationship forms, as shown with the following syslog messages:
R1# %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.12.2 (GigabitEthernet1/0) is up: new adjacency R2# %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.12.1 (GigabitEthernet0/0) is up: new adjacency
You confirm the neighbor relationship on R1 with the show ip eigrp neighbors command, as shown in Example 4-40.
Example 4-40 Verifying Neighbors with the show ip eigrp neighbors Command
R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.12.2 Gi1/0 14 00:02:10 75 450 0 12
You go back to the PC and ping the same IP address to confirm that the problem is solved, and you receive the same result, as shown in Example 4-41. R1 still does not know about the 10.1.3.0/24 network.
Example 4-41 Destination Unreachable from the ping Command on a PC
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data; Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Back on R1, you issue the show ip route command, as shown in Example 4-42. R1 is receiving EIGRP routes because there is now an EIGRP route in the routing table (as indicated by D). However, R1 still does not know about the 10.1.3.0/24 network.
Example 4-42 show ip route Output After the Neighbor Relationship with R2 Is Established
R1# show ip route
...output omitted...
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
D 10.1.23.0/24 [90/3072] via 10.1.12.2, 00:07:40, GigabitEthernet1/0
Does R2 know about the 10.1.3.0/24 network? Example 4-43 shows R2’s routing table, which is missing 10.1.3.0/24 as well.
Example 4-43 show ip route Output on R2
R2# show ip route
...output omitted...
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/3072] via 10.1.12.1, 00:12:11, GigabitEthernet0/0
C 10.1.12.0/24 is directly connected, GigabitEthernet0/0
L 10.1.12.2/32 is directly connected, GigabitEthernet0/0
C 10.1.23.0/24 is directly connected, GigabitEthernet1/0
L 10.1.23.2/32 is directly connected, GigabitEthernet1/0
For R2 to learn about the network, it has to be neighbors with R3. The R2 output of show ip eigrp neighbors in Example 4-44 indicates that R3 is not a neighbor; only R1 is.
Example 4-44 show ip eigrp neighbors on R2
R2# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.12.1 Gi0/0 11 00:17:28 65 390 0 7
Previously, Example 4-38 indicated that Gig1/0 on R2 is participating in the EIGRP process. Therefore, you should look at the interfaces on R3. According to the output in Example 4-45, both interfaces on R3 are participating in the EIGRP process for autonomous system 10.
Example 4-45 show ip eigrp interfaces on R3
R3# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(10)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 0 0/0 0 0/0 0 0
Gi1/0 0 0/0 0 0/0 0 0
Can you see the issue? If not, look again at Example 4-45. If you need to compare it to Example 4-44, do so.
The autonomous system numbers do not match, and to form an EIGRP neighbor relationship, the autonomous system numbers must match. To solve this issue, you must enable EIGRP autonomous system 100 on R3 and then provide the correct network statements to enable EIGRP on the required interfaces for autonomous system 100. You should also remove any EIGRP configurations that are not needed, such as the EIGRP autonomous system 10 configurations. Example 4-46 shows the commands needed to accomplish this.
Example 4-46 R3 Configurations Required to Solve Issue
R3# config t Enter configuration commands, one per line. End with CNTL/Z. R3(config)# no router eigrp 10 R3(config)# router eigrp 100 R3(config-router)# network 10.1.3.3 0.0.0.0 R3(config-router)# network 10.1.23.3 0.0.0.0 %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.23.2 (GigabitEthernet1/0) is up: new adjacency R3(config-router)#
Notice in Example 4-46 that the neighbor relationship with R2 is now successful. Now it is time to verify that all the issues have been solved. On R2, you issue the show ip route command, as shown in Example 4-47, and notice that the 10.1.3.0/24 network is present. You also issue the same command on R1 and notice that 10.1.3.0/24 is present, as shown in Example 4-48. You then ping from the PC again, and the ping is truly successful, as shown in Example 4-49.
Example 4-47 show ip route Output on R2
R2# show ip route
...output omitted...
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
D 10.1.1.0/24 [90/3072] via 10.1.12.1, 00:37:21, GigabitEthernet0/0
D 10.1.3.0/24 [90/3072] via 10.1.23.3, 00:06:16, GigabitEthernet1/0
C 10.1.12.0/24 is directly connected, GigabitEthernet0/0
L 10.1.12.2/32 is directly connected, GigabitEthernet0/0
C 10.1.23.0/24 is directly connected, GigabitEthernet1/0
L 10.1.23.2/32 is directly connected, GigabitEthernet1/0
Example 4-48 show ip route Output on R1
R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
D 10.1.3.0/24 [90/3328] via 10.1.12.2, 00:07:08, GigabitEthernet1/0
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
D 10.1.23.0/24 [90/3072] via 10.1.12.2, 00:38:12, GigabitEthernet1/0
Example 4-49 A Successful Ping from the 10.1.1.0/24 Network to the 10.1.3.0/24 Network
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data: Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Trouble Ticket 4-2
Problem: Users in the 10.1.1.0/24 network have indicated that they are not able to access resources in 10.1.3.0/24.
To begin, you verify the problem by pinging from a PC in the 10.1.1.0/24 network to a PC in the 10.1.3.0/24 network, as shown in Example 4-50, and it fails. Notice that the reply is from the default gateway at 10.1.1.1 and it states Destination host unreachable. Therefore, it is technically not successful.
Example 4-50 Destination Unreachable Result from the ping Command on a PC
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data; Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
The result of this ping tells you two very important things: The PC can reach the default gateway, and the default gateway does not know how to get to the 10.1.3.0/24 network. Therefore, you can focus your attention on R1 and work from there.
On R1, you issue the same ping, but it fails, as shown in Example 4-51.
Example 4-51 Failed Ping from R1 to 10.1.3.10
R1# ping 10.1.3.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.3.10, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Next, you check the routing table on R1 with the show ip route 10.1.3.0 255.255.255.0 command, as shown in the following snippet:
R1# show ip route 10.1.3.0 255.255.255.0
This is the result:
% Subnet not in table
Does R2 know about it? You go to R2 and issue the same command, as shown in the following snippet:
R2# show ip route 10.1.3.0 255.255.255.0
The result is the same as on R1:
% Subnet not in table
Next, you go to R3 and issue the same command. Notice that 10.1.3.0/24 is in the routing table as a connected route, as shown in Example 4-52.
Example 4-52 Determining Whether a Route Is in R3’s Routing Table
R3# show ip route 10.1.3.0 255.255.255.0 Routing entry for 10.1.3.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 100 Routing Descriptor Blocks: * directly connected, via GigabitEthernet0/0 Route metric is 0, traffic share count is 1
What prevents a connected route from being advertised using EIGRP to a neighbor? As we learned earlier, the interface not participating in the EIGRP process. You can check the EIGRP interface table on R3 with the show ip eigrp interfaces command. Example 4-53 indicates that only Gi1/0 is participating in the EIGRP process.
Example 4-53 Determining Whether an Interface Is Participating in the EIGRP Process
R3# show ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(100)
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi1/0 1 0/0 821 0/0 4080 0
However, you should not jump to the conclusion that Gi0/0 is not participating in the EIGRP process. Remember that EIGRP passive interfaces do not appear in this output. Therefore, check the output of show ip protocols for passive interfaces. In Example 4-54, you can see that there are no passive interfaces.
Example 4-54 Determining Whether an Interface Is Passive
R3# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
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(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.1.23.3
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.1.3.0/32
10.1.23.3/32
Routing Information Sources:
Gateway Distance Last Update
10.1.23.2 90 00:19:11
Distance: internal 90 external 170
Next, you need to make sure that there is a network statement that will enable the EIGRP process on the interface connected to the 10.1.3.0/24 network. In Example 4-54, the output of show ip protocols indicates that R3 is routing for the network 10.1.3.0/32. Remember from earlier in this chapter that this really means network 10.1.3.0 0.0.0.0. As a result, EIGRP is enabled on the interface with the IP address 10.1.3.0. Example 4-55, which displays the output of show ip interface brief, shows that there are no interfaces with that IP address. Interface GigabitEthernet0/0 has the IP address 10.1.3.3. Therefore, the network statement is incorrect, as shown in the output of show run | section router eigrp in Example 4-56.
Example 4-55 Reviewing the Interface IP Addresses
R3# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.1.3.3 YES NVRAM up up
GigabitEthernet1/0 10.1.23.3 YES NVRAM up up
Example 4-56 Reviewing the network Statements in the Running Configuration
R3# show run | section router eigrp
router eigrp 100
network 10.1.3.0 0.0.0.0
network 10.1.23.3 0.0.0.0
After fixing the issue with the no network 10.1.3.0 0.0.0.0 command and the network 10.1.3.3 0.0.0.0 command, you check R1’s routing table with the command show ip route 10.1.3.0 255.255.255.0. As shown in Example 4-57, 10.1.3.0/24 is now in the routing table and can be reached using the next hop 10.1.12.2.
Example 4-57 Verifying That 10.1.3.0/24 Is in R1’s Routing Table
R1# show ip route 10.1.3.0 255.255.255.0 Routing entry for 10.1.3.0/24 Known via "eigrp 100", distance 90, metric 3328, type internal Redistributing via eigrp 100 Last update from 10.1.12.2 on GigabitEthernet1/0, 00:00:06 ago Routing Descriptor Blocks: * 10.1.12.2, from 10.1.12.2, 00:00:06 ago, via GigabitEthernet1/0 Route metric is 3328, traffic share count is 1 Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2
Finally, you ping from the PC again, and the ping is successful, as shown in Example 4-58.
Example 4-58 A Successful Ping from the 10.1.1.0/24 Network to the 10.1.3.0/24 Network
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data: Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Trouble Ticket 4-3
Problem: Users in the 10.1.1.0/24 network have indicated that they are not able to access resources in 10.1.3.0/24.
To begin, you verify the problem by pinging from a PC in the 10.1.1.0/24 network to a PC in the 10.1.3.0/24 network. As shown in Example 4-59, it fails. Notice that the reply is from the default gateway at 10.1.1.1, and it states Destination host unreachable.
Example 4-59 Destination Unreachable Result from the ping Command on a PC
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data; Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
The result of this ping tells you two very important things: The PC can reach the default gateway, and the default gateway does not know how to get to the 10.1.3.0/24 network. Therefore, you can focus your attention on R1 and work from there.
On R1, you issue the same ping, but it fails, as shown in Example 4-60.
Example 4-60 Failed Ping from R1 to 10.1.3.10
R1# ping 10.1.3.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.3.10, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Next, you check the routing table on R1 with the show ip route 10.1.3.0 255.255.255.0 command, as shown in the following configuration:
R1# show ip route 10.1.3.0 255.255.255.0 % Subnet not in table
Does R2 know about it? You go to R2 and issue the same command, as shown in Example 4-61. R2 does know about it.
Example 4-61 Determining Whether a Route Is in R2’s Routing Table
R2# show ip route 10.1.3.0 255.255.255.0 Routing entry for 10.1.3.0/24 Known via "eigrp 100", distance 90, metric 3072, type internal Redistributing via eigrp 100 Last update from 10.1.23.3 on GigabitEthernet1/0, 00:44:37 ago Routing Descriptor Blocks: * 10.1.23.3, from 10.1.23.3, 00:44:37 ago, via GigabitEthernet1/0 Route metric is 3072, traffic share count is 1 Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
Next, you go back to R1 and issue the show ip eigrp topology command to determine whether R1 is even learning about the 10.1.3.0/24 network. Example 4-62 indicates that it is not.
Example 4-62 Determining Whether R1 Is Learning About 10.1.3.0/24
R1# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(10.1.12.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.1.12.0/24, 1 successors, FD is 2816
via Connected, GigabitEthernet1/0
P 10.1.23.0/24, 1 successors, FD is 3072
via 10.1.12.2 (3072/2816), GigabitEthernet1/0
P 10.1.1.0/24, 1 successors, FD is 2816
via Connected, GigabitEthernet0/0
It’s time to hypothesize! Why would R2 know about 10.1.3.0/24 and R1 not know about it? Consider these possibilities:
R1 and R2 are not EIGRP neighbors.
A route filter on R2 prevents it from advertising 10.1.3.0/24 to R1.
A route filter on R1 prevents it from learning 10.1.3.0/24 in Gig1/0.
On R1, you issue the show ip eigrp neighbors command, as shown in Example 4-63, and it shows that R2 is a neighbor. However, if you look closely at the topology table of R1, you might notice that R1 is learning about 10.1.23.0/24 from R2, meaning that they are neighbors, and routes are being learned. Therefore, you hypothesize that there must be a filter in place.
Example 4-63 Determining Whether R2 Is a Neighbor
R1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.12.2 Gi1/0 12 01:20:27 72 432 0 18
Next, you issue the show ip protocols command, as shown in Example 4-64, to determine whether there are any route filters on R1. The output indicates that there is an inbound route filter on R1’s GigabitEthernet 1/0 interface. The route filter is filtering based on a prefix list called DENY_10.1.3.0/24.
Example 4-64 Determining Whether There Is a Route Filter on R1
R1# show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "eigrp 100" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set GigabitEthernet1/0 filtered by (prefix-list) DENY_10.1.3.0/24 (per-user), default is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP-IPv4 Protocol for AS(100) ...output omitted...
Next, you issue the show ip prefix-list command on R1, as shown in Example 4-65, and it indicates that 10.1.3.0/24 is being denied.
Example 4-65 Reviewing the Prefix List
R1# show ip prefix-list
ip prefix-list DENY_10.1.3.0/24: 2 entries
seq 5 deny 10.1.3.0/24
seq 10 permit 0.0.0.0/0 le 32
In this case, you can either modify the prefix list to allow 10.1.3.0/24, or you can remove the distribute list from the EIGRP process. The choice depends on the requirements of the organization or scenario. In this case, remove the distribute list from R1 with the command no distribute-list prefix DENY_10.1.3.0/24 in GigabitEthernet1/0. Because of this change, the neighbor relationship resets, as the following syslog message indicates:
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.12.2 (GigabitEthernet1/0) is resync: intf route configuration changed
After fixing the issue, you check R1’s routing table with the command show ip route 10.1.3.0 255.255.255.0. As shown in Example 4-66, 10.1.3.0/24 is now in the routing table and can be reached through the next hop 10.1.12.2.
Example 4-66 Verifying That 10.1.3.0/24 Is in R1’s Routing Table
R1# show ip route 10.1.3.0 255.255.255.0 Routing entry for 10.1.3.0/24 Known via "eigrp 100", distance 90, metric 3328, type internal Redistributing via eigrp 100 Last update from 10.1.12.2 on GigabitEthernet1/0, 00:00:06 ago Routing Descriptor Blocks: * 10.1.12.2, from 10.1.12.2, 00:00:06 ago, via GigabitEthernet1/0 Route metric is 3328, traffic share count is 1 Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2
Finally, you ping from the PC again, and the ping is successful, as shown in Example 4-67.
Example 4-67 A Successful ping from the 10.1.1.0/24 Network to the 10.1.3.0/24 Network
C:>ping 10.1.3.10 Pinging 10.1.3.10 with 32 bytes of data: Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Reply from 10.1.3.10: bytes=32 time 1ms TTL=128 Ping statistics for 10.1.3.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple choices for exam preparation: the exercises here, Chapter 24, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software. The questions that follow present a bigger challenge than the exam itself because they use an open-ended question format. By using this more difficult format, you can exercise your memory better and prove your conceptual and factual knowledge of this chapter. You can find the answers to these questions in the appendix.
Review All Key Topics
Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 4-2 lists these key topics and the page number on which each is found.
Table 4-2 Key Topics
Key Topic Element |
Description |
Page Number |
List |
Possible reasons an EIGRP neighbor relationship might not form |
|
Verifying the autonomous system number with show ip protocols |
||
Verifying EIGRP interfaces with show ip eigrp interfaces |
||
Verifying K values with show ip protocols |
||
Verifying passive interfaces with show ip protocols |
||
Section |
Authentication |
|
List |
Possible reasons EIGRP for IPv4 routes may be missing from the routing table |
|
Paragraph |
How a better source of routing information could cause suboptimal routing |
|
List |
Considerations when troubleshooting route filters |
|
Section |
Stub configuration |
|
Section |
Split horizon |
|
List |
Considerations when troubleshooting route summarization |
|
Verifying variance and maximum paths |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
Use the Command Reference to Check Your Memory
This section includes the most important commands covered in this chapter. It might not be necessary to memorize the complete syntax of every command, but you should be able to remember the basic keywords that are needed.
To test your memory of the commands in Table 4-3, go to the companion web site and download the Command Reference Exercises document. Fill in the missing command in the tables based on the command description. You can check your work by downloading the Command Reference Exercise Answer Key Appendix also on the companion website.
The ENARSI 300-410 exam focuses on practical, hands-on skills that are used by a networking professional. Therefore, you should be able to identify the commands needed to configure, verify, and troubleshoot the topics covered in this chapter.
Table 4-3 Command Reference
Task |
Command Syntax |
Display the IPv4 routing protocols enabled on the router; for EIGRP, display autonomous system number, outgoing and incoming filters, K values, router ID, maximum paths, variance, local stub configuration, routing for networks, routing information sources, administrative distance, and passive interfaces |
show ip protocols |
Show a router’s EIGRP neighbors |
show ip eigrp neighbors |
Show detailed information about a router’s EIGRP neighbors, including whether the neighbor is a stub router, along with the types of networks it is advertising as a stub |
show ip eigrp neighbors detail |
Display all of a router’s interfaces that are configured to participate in an EIGRP routing process (with the exception of passive interfaces) |
show ip eigrp interfaces |
Display the interfaces participating in the EIGRP for IPv4 routing process, along with EIGRP hello and hold timers, whether the split horizon rule is enabled, and whether authentication is being used |
show ip eigrp interfaces detail |
Display the EIGRP configuration in the running configuration |
show run | section router eigrp |
Display the configuration of a specific interface in the running configuration (This is valuable when you are trying to troubleshoot EIGRP interface commands.) |
show run interface interface_type interface_number |
Display the keychains and associated keys and key strings |
show key chain |
Display IPv4 interface parameters; for EIGRP, verify whether the interface has joined the correct multicast group (224.0.0.10) and whether any ACLs applied to the interface might be preventing an EIGRP adjacency from forming |
show ip interface interface_type interface_number |
Display routes known to a router’s EIGRP routing process, which are contained in the EIGRP topology table (The all-links keyword displays all routes learned for each network, and without the all-links keyword, only the successors and feasible successors are displayed for each network.) |
show ip eigrp topology [all-links] |
Show routes known to a router’s IP routing table that were injected by the router’s EIGRP routing process |
show ip route eigrp |
Display all EIGRP packets exchanged with a router’s EIGRP neighbors or display only specific EIGRP packet types (for example, EIGRP hello packets) |
debug eigrp packets |