Wireshark Sniff [EIGRP Update Behaviour]

[cisco_geek]

Dear All,

I'm sniffing EIGRP packets using wireshark to get a close look about the DUAL operations in case of route failures, and noticed the following:

- When the router (R1) first initiate an adjacency with another router (R2 for example), R1 will tell R2 about its directly connected interfaces, so as R2 to R1.

- What I do not understand here is that, once R1 receive an update packet from R2, R1 will again send R2's route with an inifinite metric (Delay) as unreachable to the multicast address 224.0.0.10

Do anyone know why this is done?

Thanks

[Peter Paluch]

Hello,

What I do not understand here is that, once R1 receive an update packet  from R2, R1 will again send R2's route with an inifinite metric (Delay)  as unreachable to the multicast address 224.0.0.10

This is Split Horizon with Poisoned Reverse in action. For each network for which R2 is the next hop (the successor), R1 will announce that same network with the metric set to infinity. This will make sure R2 and possibly other routers on the segment will stop considering R1 as a possible next hop towards that destination.

Best regards,

Peter

[cisco_geek]

I have thought of this already, but it should apply to the multi-access networks such as Ethernet. I have updated the topology to be an HDLC link (point-to-point), so R1 shouldn't consider existence of other routers in the HDLC link and should never use the split-horizon rule in this case .. Am I right?

[Peter Paluch · Accepted solution]

Hello,

I have thought of this already, but it should apply to the multi-access  networks such as Ethernet. I have updated the topology to be an HDLC  link (point-to-point), so R1 shouldn't consider existence of other  routers in the HDLC link and should never use the split-horizon rule in  this case

I don't think so. I have never linked the usage of split horizon to multiaccess networks. A routing loop caused by not using split horizon can be created easily also on a point-to-point link. Using the split horizon or a split horizon with poisoned reverse is therefore prudent even on point-to-point links. After all, you may want to try using the no ip split-horizon eigrp as-number command on the respective interface to see if the EIGRP behavior changes here.

One could argue that with EIGRP's internal logic of choosing loop-free neighbors, the use of split horizon or split horizon with poisoned reverse is redundant. That may be true but still, these mechanisms add an additional layer of protection against routing loops which is easily implemented and requires only a moderate processing power.

Best regards,

Peter

[cisco_geek]

Apparently correct. Thank you Peter!