EIGRP by default uses multicast for neighbor discovery but it also allows you to configure EIGRP neighbors statically. Once you do this, EIGRP will only use unicast and disables EIGRP multicast on the selected interface.
This could be useful in certain scenarios where multicast is not supported or when you want to reduce the overhead of multicast traffic. Here’s an example:
Above we have a frame-relay hub and spoke network. The hub and spoke1 routers are the only two routers that are running EIGRP. When the hub router sends an EIGRP multicast packet, it will be replicated on all PVCs. All 4 spoke routers will receive this multicast traffic even though only spoke1 is interested in it.
In a scenario like this, it would make sense to configure the EIGRP neighbor statically so that multicast won’t be used.
Let’s see how we can configure EIGRP static neighbors…
For this demonstration I’ll use the following two routers:
R1 and R2 are connected through frame-relay. Here’s the configuration of the interfaces:
R1#show run | begin Serial0/0 interface Serial0/0 ip address 192.168.12.1 255.255.255.0 encapsulation frame-relay clock rate 2000000 frame-relay map ip 192.168.12.2 102 no frame-relay inverse-arp
R2#show run | begin Serial0/0 interface Serial0/0 ip address 192.168.12.2 255.255.255.0 encapsulation frame-relay clock rate 2000000 frame-relay map ip 192.168.12.1 201 no frame-relay inverse-arp
Above you can see that frame-relay Inverse ARP has been disabled, two static frame-relay maps are used for our mappings. This means that we are unable to send any broadcast or multicast traffic through this PVC. You can also verify this with the following command:
R1#show frame-relay map Serial0/0 (up): ip 192.168.12.2 dlci 102(0x66,0x1860), static, CISCO, status defined, active
R2#show frame-relay map Serial0/0 (up): ip 192.168.12.1 dlci 201(0xC9,0x3090), static, CISCO, status defined, active
As you can see the frame-relay mappings are there but the broadcast keyword is missing. Let’s configure EIGRP to use static neighbors:
R1(config)#router eigrp 12 R1(config-router)#network 192.168.12.0 R1(config-router)#neighbor 192.168.12.2 Serial 0/0
R2(config)#router eigrp 12 R2(config-router)#network 192.168.12.0 R2(config-router)#neighbor 192.168.12.1 Serial 0/0
You only have to use the neighbor command to specify the remote neighbor and the interface to reach it. After a few seconds the neighbor adjacency will appear:
R1# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.2 (Serial0/0) is up: new adjacency
R2# %DUAL-5-NBRCHANGE: IP-EIGRP(0) 12: Neighbor 192.168.12.1 (Serial0/0) is up: new adjacency
You you can also verify your static neighbors with the show ip eigrp neighbors command:
How do I inject one or two specific static routes (originating from a remote s2s/l2l tunnel) into my EIGRP domain without advertising the static default route?
Example: Internet->ASA-> R1-> R2 -> R3-> R4
ip route 192.168.2.0 255.255.255.0
ip route 192.168.3.0 255.255.255.0 (needs to be routed via EIGRP all the way to R4)
ip route 192.168.4.0 255.255.255.0
ip route 192.168.5.0 255.255.255.0 (needs to be routed via EIGRP all the way to R4)
ip route 0.0.0.0 0.0.0.0 18.104.22.168
I want to propagate these two specific static routes all the way to R4 so network... Continue reading in our forum
You mentioned these are static routes, and unless you say otherwise, I will assume they are on R1. Since they are static routes, we can assume they were not learned by EIGRP. Therefore, the easiest solution to your problem is advertise only those static routes in EIGRP like this (substitute the autonomous-system “1” below with whatever you are actually using for EIGRP):
The solution above assumes that you don’t want R2 or R3 to l... Continue reading in our forum
First off, Thank you for extending your help!
I want to accomplish this WITHOUT distributing or redistributing into EIGRP neighbors within the same AS. I actually tried your recommendation (below) last week in my lab, thinking it would work, but apparently it didn’t!
Here’s what R1 has in its RIB table as static:... Continue reading in our forum
The solution I gave you should work, so something else must be going on. Would you mind tells us what configuration you used for the other routers for EIGRP, and what is in the RIB for each of those?
Also, when you tested this in your lab, did you confirm your EIGRP neighbor relationship? For example, if you haven’t statically configured R1 and R2 as being neighbors, you must include the network segment they share as part of the network statement under the EIGRP process.
You can verify your routers have neighbors by doing the following:... Continue reading in our forum