Cisco Support Community
Community Member

Eigrp 3rd party next-hop behaviour


i have 3 routers connected to a shared medium (net R1 (.1) and R2 (.2) are eigrp negihbors and i have a 2nd network, configured on R3(.3)'s Looback0 interface.

My purpose was to redistribute net on R2 into eigrp and to advertise it from here to R1 with R3 as next hop, without R1 and R3 becoming eigrp neighbors.  I have used the no ip next-ho-self eigrp command on R2's interface connected to the shared medium.

I have managed to redistribute as intended when i used eigrp (different process), ripv2 and ospf between R2 and R3 on the shared medium. Notheles,setting as next hop for the route failed when using iBGP (with bgp redistribute-internal) and when having a static route on R2 with (R3 shared medium ip) as next-hop ( ip route ).

----------------Successfull propagation of the route with R3 as next hop-----------------------


R1#sh ip route

D EX [170/79360] via, 00:01:09, FastEthernet0/0 is subnetted, 1 subnets

C is directly connected, FastEthernet0/0

R1#sh ip eig top

IP-EIGRP (AS 9): Topology entry for

   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 79360

   Routing Descriptor Blocks: (FastEthernet0/0), from, Send flag is 0x0

       Composite metric is (79360/76800), Route is External

       Vector metric:

         Minimum bandwidth is 100000 Kbit

         Total delay is 2100 microseconds

         Reliability is 255/255

         Load is 1/255

         Minimum MTU is 1500

         Hop count is 1

       External data:

         Originating router is 

         AS number of route is 7

         External protocol is OSPF, external metric is 2

         Administrator tag is 0 (0x00000000)


I have found only following as neccessary condition so that the nect hop may be changed in the advertised route:

"EIGRP fills in the next-hop field in the updates and sends them out on an interface connected to a shared medium if the source and destination of the update are also reachable  through the same interface. "

Could anybody please explain why eigrp fails to change the next-hop of a route when advertising it to a neoghbor if the route is originally learned via BGP or static routing ? And if possible, please advise a solution/workaround.

Thank you,



Re: Eigrp 3rd party next-hop behaviour

The initial coding of the next-hop-self feature didn't work with BGP due to an oversight. I fixed it a couple of years ago but don't remember the version.

Sent from Cisco Technical Support iPad App

Community Member

Eigrp 3rd party next-hop behaviour

Hi Donald,

thank you for your answer, I will also try the redistribution from BGP on machines with newer IOS to see how it works.

Nonetheless could you please advice if there is any reason this is not working when I try to redistribute a static route ? Is this behaviour caused by the fact that the redistributing router, R2 in this case, can't detect if the next-hop, R3, is alive on the shared medium and if that is the case might using BFD between the two change anything ?


Eigrp 3rd party next-hop behaviour

I just looked and the bgp fix was done in 2008 via CSCsm95129.  I don't see any signs of anyone reporting static not working for ipv4 (though there is an open bug for ipv6) and I don't see static routes in my original unit testing.  I'm not sure whether it will work or not.  If it just doesn't work, open a case and get a defect filed.

Community Member

Eigrp 3rd party next-hop behaviour

Hi Donald,

thank you once more for your reply. I will try to further test 3rd party next hop with static routes using newer versions of IOS and in case it wil stilll not work as expected i will open a case as you advised.

CreatePlease to create content