EIGRP Static Neighbor

Lessons Discussion
41

Hello Jorge

This is an interesting finding. The reason behind it has to do with the primary usage of Nexus devices.

For IOS and IOS-XE devices, the static neighbor command in EIGRP was primarily introduced for Non-Broadcast Multi-Access (NBMA) networks like Frame Relay or ATM. On these networks, broadcast and multicast traffic (like EIGRP Hellos on 224.0.0.10) are not forwarded by default to all endpoints. The neighbor command forced the router to send unicast EIGRP packets to a statically defined peer.

Nexus devices using NX-OS are purpose-built for data centers. The underlying transport in any modern data center is Ethernet. Frame Relay and other legacy NBMA technologies are not relevant in this context. The assumption in a data center fabric is that Layer 2 multicast and broadcast are fully supported on any given VLAN.

If you want a workaround for this, you can use a GRE tunnel:

A GRE tunnel creates a virtual point-to-point link between your two Nexus switches. You can then run EIGRP over this tunnel interface. The tunnel will encapsulate the multicast EIGRP packets within standard unicast IP packets, allowing them to traverse the underlying network that blocks multicast. Does that make sense?

I hope this has been helpful!

Laz

42

Hi Laz,
Thank you for the explanation. This makes sense.
When I tried it on NXOS, under address family ipv4 unicast, I received the message “Not supported yet”.
In my scenario, I had a hub/spoke topology where all L3 switches/routers were IOS XE, with the exception of one (NXOS). I endup installing another catalyst switch infront of it just to move this link and use unicast neighbor.
Thank you again

1 Like