Eigrp 3rd party next-hop behaviour

cristivucu · ‎11-15-2011

Hi,

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

My purpose was to redistribute net 192.168.7.0 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 192.168.7.0 as intended when i used eigrp (different process), ripv2 and ospf between R2 and R3 on the shared medium. Notheles,setting 10.1.1.3 as next hop for the route failed when using iBGP (with bgp redistribute-internal) and when having a static route on R2 with 10.1.1.3 (R3 shared medium ip) as next-hop ( ip route 192.168.77.0 255.255.255.0 10.1.1.3 ).

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

-------------------------------------------------------------------------------------------------------------------------

R1#sh ip route

D EX 192.168.7.0/24 [170/79360] via 10.1.1.3, 00:01:09, FastEthernet0/0

10.0.0.0/24 is subnetted, 1 subnets

C 10.1.1.0 is directly connected, FastEthernet0/0

R1#sh ip eig top 192.168.7.0/24

IP-EIGRP (AS 9): Topology entry for 192.168.7.0/24

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

Routing Descriptor Blocks:

10.1.1.3 (FastEthernet0/0), from 10.1.1.2, 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 192.168.7.2

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,

Cristian

dslice · ‎11-15-2011

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

cristivucu · ‎11-17-2011

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 ?

dslice · ‎11-17-2011

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.

cristivucu · ‎11-22-2011

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.