Understanding EIGRP – Part 5 (Static Neighbors)

ccie r/s ccna r/s ccnp r/s Feb 05, 2017

Typically, an EIGRP-speaking router dynamically discovers its neighbors, by sending multicast Hello messages. However, there is an option to statically configure those neighbors, and communicate with them via unicast messages. This is rarely done, but could on rare occasion be useful.

Consider for example a Frame Relay WAN. Imagine that router A has an interface configured with ten Frame Relay permanent virtual circuits (PVCs). At the other end of two of those PVCs resides EIGRP-speaking routers. However, the other eight PVCs do not have an EIGRP-speaking router at the far end. In such a topology, if router A’s WAN interface was participating in EIGRP, then router A would have to replicate its EIGRP Hello message and send a copy out all ten PVCs, resulting in an increased processor burden on router A and increased the bandwidth usage (unnecessarily) on the eight PVCs not connecting to an EIGRP router. This is the type of situation that would benefit from our statically configuring EIGRP neighbors, rather than using the multicast-based discovery process. Let's consider EIGRP's static neighbor configuration option in this blog post.

By the way, this is the fifth in a series of Understanding EIGRP blog postings I've done. If you missed one, here are the links to the previous postings:

Static Neighbor Configuration

The neighbor ip_address outgoing_interface command is issued in EIGRP router configuration mode to statically specify an EIGRP neighbor. Note that this static configuration needs to be performed on both neighbors. Also, keep in mind that the IP address specified in the neighbor command belongs to the same subnet as the specified outgoing interface. Based on the topology shown below, the following sample configurations show how routers R1 and R2 statically point to one another, as opposed to using dynamic discovery.

On router R1, the neighbor gig 0/1 command entered in EIGRP router configuration mode is instructing the EIGRP process to stop sending multicast messages out of interface Gig 0/1, and instead start using unicast messages. It also instructs the EIGRP routing process to attempt establishing a neighborship with an EIGRP-speaking router at an IP address of (that is, the IP address of router R2’s Gig 0/1 interface). Since static neighbor configuration must be performed on both ends of the link, router R2 is similarly configured to send EIGRP unicast messages out of its Gig 0/1 interface and to establish a neighborship with an EIGRP-speaking router with an IP address of (that is, the IP address of routerR1’s gig 0/1 interface).

Static Neighbor Verification

To determine which, if any, interfaces on a router are statically configured with an EIGRP neighbor, you can use the command show ip eigrp neighbors detail. The example below shows this command being issued on router R1. Notice that the output identifies as a statically configured neighbor.

Static Neighbor Caveat

Consider a router that needs to establish more than one EIGRP neighborship off of a single interface, such as router R2 in the figure below. In this topology, routers R1 and R2 had dynamically formed an EIGRP neighborship. Later, router R4 was added, and routers R2 and R4 were statically configured as EIGRP neighbors. However, after the static configuration was made, router R2 lost its neighborship with router R1. The reason is, router R2 is only sending unicast EIGRP messages out of its Gig 0/1 interface and only wants to receive unicast EIGRP messages coming into that interface. Router R1, however, is still configured (with default settings) to send and expect multicast EIGRP messages on its Gig 0/1 interface. So, the moral of the story is, if you’re configuring a router interface to statically establish an EIGRP neighborship, make sure that all EIGRP neighbors off of that interface are also configured for static neighborships. 


That will wrap it up for this installment in our Understanding EIGRP series. If you want to watch me teach EIGRP in-depth, please check out either of the following complete video courses I've created for Cisco Press:

Click HERE to learn more about the CCNA R/S 200-125 Complete Video Course.

Click HERE to learn more about the ROUTE 300-101 Complete Video Course.

Enjoy your studies!

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945