Troubleshooting EIGRP Neighbor Adjacency
EIGRP is an advanced distance vector routing protocol that has to establish a neighbor relationship before updates are sent. Because of this the first thing we’ll have to do is check if the neighbor adjacency is working properly. If this is the case we can continue by checking if networks are being advertised or not. In this lesson I’ll show you everything that can go wrong with EIGRP, how to fix it and in what order. Let’s get started with the neighbor adjacency!
There are a number of items that cause problems with EIGRP neighbor adjacencies:
- Uncommon subnet: EIGRP neighbors with IP addresses that are not in the same subnet.
- K value mismatch: By default bandwidth and delay are enabled for the metric calculation. We can enable load and reliability as well but we have to do it on all EIGRP routers.
- AS mismatch: The autonomous system number has to match on both EIGRP routers in order to form a neighbor adjacency.
- Layer 2 issues: EIGRP works on layer 3 of the OSI-model. If layer 1 and 2 are not working properly we’ll have issues with forming a neighbor adjacency.
- Access-list issues: It’s possible that someone created an access-list that filters out multicast traffic. EIGRP by default uses 224.0.0.10 to communicate with other EIGRP neighbors.
- NBMA: Non Broadcast Multi Access networks like frame-relay will not allow broadcast or multicast traffic by default. This can prevent EIGRP from forming EIGRP neighbor adjacencies.
Let’s take a look at these different issues…
EIGRP Uncommon Subnet
The first EIGRP issue is easy to spot, I’ll use the following two routers for this:
Here’s the configuration of these two routers:
R1(config)#interface FastEthernet 0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#router eigrp 12
R1(config-router)#network 192.168.12.0R2(config)#interface FastEthernet0/0
R2(config-if)#ip address 192.168.21.2 255.255.255.0
R2(config)#router eigrp 12
R2(config-router)#network 192.168.21.0The uncommon subnet error is easy to spot. In the example above we have 2 routers and you can see I configured a different subnet on each interface.
After enabling EIGRP the following errors pops up:
R1# IP-EIGRP(Default-IP-Routing-Table:12): Neighbor 192.168.21.2 not on common subnet for FastEthernet0/0R2# IP-EIGRP(Default-IP-Routing-Table:12): Neighbor 192.168.12.1 not on common subnet for FastEthernet0/0Both routers complain that they are not on the same subnet.
R2(config-router)#interface FastEthernet0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config)#router eigrp 12
R2(config-router)#no network 192.168.21.0
R2(config-router)#network 192.168.12.0I’ll change the IP address on R2 and make sure the correct network command is configured for EIGRP.
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacencyR2# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (FastEthernet0/0) is up: new adjacencyVoila! We now have an EIGRP neighbor adjacency.
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.2 Fa0/0 13 00:05:15 3 200 0 3R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.1 Fa0/0 11 00:05:32 1263 5000 0 3We can verify this by using the show ip eigrp neighbors command.
Lesson learned: Make sure both routers are on the same subnet.
EIGRP K-Values Mismatch
Another common EIGRP issue is K-values mismatch. Take a look below:
This time the IP addresses are correct but we are using different K values on both sides. R1 has enabled the K-values that use bandwidth, delay, load and reliability. R2 is only using the ones for bandwidth and delay. Here’s what you will see on the console:
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is down: K-value mismatchR1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is down: Interface Goodbye receivedThis error is easy to spot because your console will give you the “K-value mismatch” error on both routers. This is what the configuration of R1 looks like:
R1#show run | section eigrp
router eigrp 12
network 192.168.12.0
metric weights 0 1 1 1 1 0
auto-summaryWe can verify our configuration by looking at both routers. You can see the K values were changed on R1. Let’s change R2 so that we use the same K values:
R2(config)#router eigrp 12
R2(config-router)#metric weights 0 1 1 1 1 0This should help, this is what the console shows us:
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacencyR2# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (FastEthernet0/0) is up: new adjacencyAfter changing the K values we have an EIGRP neighbor adjacency. In case you missed the console messages you can also see it here:
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.2 Fa0/0 13 00:02:11 13 200 0 6R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.1 Fa0/0 13 00:02:42 19 200 0 6Another problem solved! Lesson learned: Make sure the K-values are the same on all EIGRP routers within the same autonomous system.
EIGRP AS Number Mismatch
This is a typical monday morning problem. EIGRP uses an AS number and it has to match on both EIGRP routers. Here’s the topology:
There’s a mismatch in the AS number. When we configure EIGRP we have to type in an AS number. Unlike OSPF (which uses a process ID) this number has to be the same on both routers. Let’s take a look:
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 21Unlike the other EIGRP configuration mistakes this one doesn’t produce an error message. We can use show ip eigrp neighbors and see that there are no neighbors. Use your eagle eyes to spot for differences and you’ll quickly see that we are not using the same AS number. Here’s the configuration:
R1#show run | section eigrp
router eigrp 12
network 192.168.12.0
auto-summaryR2#show run | section eigrp
router eigrp 21
network 192.168.12.0
auto-summaryLet’s fix this, I’ll change the configuration of R2:
R2(config)#no router eigrp 21
router eigrp 12
network 192.168.12.0
metric weights 0 1 1 1 1 0
auto-summaryAfter making the change, the neighbor adjacency will appear:
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacencyR2# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (FastEthernet0/0) is up: new adjacencyR1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.2 Fa0/0 11 00:01:44 13 200 0 3R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.1 Fa0/0 12 00:01:53 7 200 0 9After changing the AS number life is good. Lesson learned: Make sure the AS number is the same if you want an EIGRP neighbor adjacency.
EIGRP Passive Interface
if you checked the AS number, K values, IP addresses and you still don’t have a working EIGRP neighbor adjacency then you should think about security. Maybe an access-list is blocking EIGRP and/or multicast traffic. Here’s the topology:
Once again two EIGRP routers and no neighbor adjacency. What is going on?
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 12We see that there are no neighbors but the AS number matches. Let’s take a closer look:
R1#show ip protocols
Routing Protocol is "eigrp 12"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 12
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
192.168.12.0
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170R2#show ip protocols
Routing Protocol is "eigrp 12"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 12
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
192.168.12.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170If you look at the output of show ip protocols you can see that the network has been advertised correctly. If you look closely on R2 you can see that we have a passive interface. Let’s get rid of it!
R2(config)#router eigrp 12
R2(config-router)#no passive-interface fastEthernet 0/0Another misconfiguration bites the dust…do we have neighbors now?
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.2 Fa0/0 13 00:05:23 24 200 0 6R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 12
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.12.1 Fa0/0 14 00:05:39 20 200 0 6There we go! Problem solved! Lesson learned: Don’t enable passive interface if you want to establish an EIGRP neighbor adjacency.
EIGRP Multicast Traffic Filtered
If the EIGRP configuration is 100% OK then it’s possible that something else is blocking our traffic. Here’s an example:
In the example above I have the same 2 routers but this time someone decided it was a good idea to configure an access-list on R2 that blocks all incoming multicast traffic. Here’s what you will see on the console:
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacency
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is down: retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacencyThis is where things might become confusing. On R1 you can see that it believes it has established an EIGRP neighbor adjacency with R2. This happens because we are still receiving EIGRP packets from R2. Let me show you what is going on:
R1#debug eigrp neighbors
EIGRP Neighbors debugging is on
EIGRP: Retransmission retry limit exceeded
EIGRP: Holdtime expiredWe can do a debug eigrp neighbors to see what is going on. Apparently R1 is not getting a response back from its hello messages, the holdtime expires and it will drop the EIGRP neighbor adjacency. A quick method to test if multicast traffic is being filtered is to ping the multicast address that EIGRP uses:
R1#ping 224.0.0.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.10, timeout is 2 seconds:
.You can see we don’t get a response from this ping. It’s a good idea to check if there are access-lists in the network:
R2#show ip interface fa0/0 | include access list
Outgoing access list is not set
Inbound access list is BLOCKMULTICASTBingo! We found something, let’s check it out:
R2#show ip access-lists
Extended IP access list BLOCKMULTICAST
10 deny ip any 224.0.0.0 15.255.255.255 (536 matches)
20 permit ip any any (468 matches)This access-list is blocking all multicast traffic. Let’s punch a hole in it so EIGRP is allowed:
R2(config)#ip access-list extended BLOCKMULTICAST
R2(config-ext-nacl)#5 permit ip any host 224.0.0.10We can create a specific statement that will allow EIGRP traffic. Let’s see if this was helpful:
R2#show access-lists
Extended IP access list BLOCKMULTICAST
5 permit ip any host 224.0.0.10 (27 matches)
10 deny ip any 224.0.0.0 15.255.255.255 (569 matches)
20 permit ip any any (501 matches)You can see our EIGRP traffic matches the statement I just created.
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (FastEthernet0/0) is up: new adjacencyR2# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (FastEthernet0/0) is up: new adjacencyBoth routers now show a working EIGRP neighbor adjacency. If I ping the EIGRP multicast address again then I should get a reply:
R1#ping 224.0.0.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.10, timeout is 2 seconds:
Reply to request 0 from 192.168.12.2, 24 msThe ping that I just tried is now working. Lesson learned: Don’t block EIGRP packets!
Another possible solution for this problem is to use the neighbor command. This tells EIGRP to use unicast instead of multicast.
EIGRP Frame-Relay Map
There’s one more EIGRP neighbor adjacency issue I have for you, this time we have a different topology:
Here’s what the configuration looks like:
R1#
interface Serial0/0
ip address 192.168.12.1 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
frame-relay map ip 192.168.12.2 102
no frame-relay inverse-arp
router eigrp 12
network 192.168.12.0
auto-summaryR2#
interface Serial0/0
ip address 192.168.12.2 255.255.255.0
encapsulation frame-relay
serial restart-delay 0
frame-relay map ip 192.168.12.1 201
no frame-relay inverse-arp
router eigrp 12
network 192.168.12.0
auto-summaryBoth routers are configured for frame-relay and EIGRP has been configured. We don’t have a neighbor adjacency though:
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 12R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 12You can see that there are no neighbors…that’s not good! Can I ping the other side?
R1#ping 192.168.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/24 msSending a ping is no problem so we can assume the frame-relay PVC is working. EIGRP however uses multicast and frame-relay by default is NBMA. Can we ping the 224.0.0.10 EIGRP multicast address?
R1#ping 224.0.0.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 224.0.0.10, timeout is 2 seconds:
.No response here, at least we now know that unicast traffic is working and multicast doesn’t work. Frame-relay can be configured for point-
to-point or point-to-multipoint. A physical interface is always a frame-relay point-to-multipoint interface and those require frame-relay maps, let’s check it out:
R1#show frame-relay map
Serial0/0 (up): ip 192.168.12.2 dlci 102(0x66,0x1860), static,
CISCO, status defined, activeR2#show frame-relay map
Serial0/0 (up): ip 192.168.12.1 dlci 201(0xC9,0x3090), static,
CISCO, status defined, activeWe can see both routers have a DLCI-to-IP mapping so they know how to reach each other. I can see they keyword “static” which also reveals to me that this mapping was configured by someone and not learned through Inverse ARP (otherwise you see “dynamic”). I don’t see the “broadcast” keyword which is required to forward broadcast or multicast traffic. At this moment we have 2 options to fix this problem:
- Configure EIGRP to use unicast traffic instead of multicast.
- Check the frame-relay configuration and make sure multicast traffic can be forwarded.
Let’s try the EIGRP unicast configuration first:
R1(config)#router eigrp 12
R1(config-router)#neighbor 192.168.12.2 serial 0/0R2(config)#router eigrp 12
R2(config-router)#neighbor 192.168.12.1 serial 0/0We require the neighbor command for the EIGRP configuration. As soon as you type in these commands and hit enter you’ll see this:
R1#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (Serial0/0) is up: new adjacencyR2#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (Serial0/0) is up: new adjacencyProblem solved! Now let’s try the other method where we send multicast traffic down the frame-relay PVC:
R1(config)#router eigrp 12
R1(config-router)#no neighbor 192.168.12.2 serial 0/0R2(config)#router eigrp 12
R2(config-router)#no neighbor 192.168.12.1 serial 0/0If it ain’t broke…don’t fix it…not this time! Time to hammer down the EIGRP neighbor adjacency. Now let’s create the frame-relay maps:
R1(config)#interface serial 0/0
R1(config-if)#frame-relay map ip 192.168.12.2 102 broadcastR2(config)#interface serial 0/0
R2(config-if)#frame-relay map ip 192.168.12.1 201 broadcastBroadcast is the magic keyword here. This will allow broadcast and multicast traffic. This is what you’ll see on the console now:
R1#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (Serial0/0) is up: new adjacencyR2#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (Serial0/0) is up: new adjacencyAfter changing the frame-relay map configuration we have an EIGRP neighbor adjacency! That’s all there is to it.
Lesson learned: Check if your frame-relay network supports broadcast or not. Configure EIGRP to use unicast or change your frame-relay map configuration to support broadcast / multicast traffic.
Excellent! You have now seen the most common errors that can cause EIGRP not to form an EIGRP neighbor adjacency. With your adjacency up and running, you can continue troubleshooting EIGRP route advertisements.
If you have any questions, feel free to leave a comment.
Table of Contents
Unit 2: EIGRP Neighbor Adjacency
Unit 4: EIGRP Advanced Features