12-25-2012 02:29 PM - edited 03-04-2019 06:30 PM
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
Solved! Go to Solution.
12-25-2012 04:12 PM
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
12-25-2012 02:50 PM
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
12-25-2012 03:14 PM
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?
12-25-2012 04:12 PM
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
12-25-2012 04:38 PM
Apparently correct. Thank you Peter!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide