EIGRP split-horizon on NBMA interfaces

From: Paresh Khatri (Paresh.Khatri@aapt.com.au)
Date: Tue Apr 19 2005 - 19:48:58 GMT-3


Hi all..

Pls correct me if I'm wrong but this is how I believe EIGRP split-horizon/poison reverse works:

- when a router determines a feasible successor for a route, by default, it will send a poisoned updated out of the interface to the feasible successor. If this is a multi-access interface, all neighbors on that interface will see the poison update
- if 'ip eigrp split-horizon' is disabled on an interface, a router will still send out a poison update to the successor. It will also send out regular (non-poison) updates to other neighbors on that multi-access interface

Ok, bearing the above in mind, I am trying to understand some statements in the 'EIGRP Frequently Asked Questions' CCO document regarding a hub-and-spoke arrangement where the spokes need to see routes from each other. This is achieved by setting 'no ip split-horizon eigrp' on the hub's multipoint interface. The document states that:
"Disabling split horizon on the spokes radically increases EIGRP memory consumption on the hub router, as well as the amount of traffic generated on the spoke routers."

I'm having trouble understanding how the disabling of split-horizon on the spoke routes would increase memory consumption on the hub router. Say we have a hub router, H and two spokes, A & B. Only the hub has split-horizon disabled. Router A announces network A to router H. Router H sends a poison update to Router A (the successor for the route). It also sends a regular update to router B for network A to advise it of its reachability thro0ugh router H. Router B will send a poison update to router H since router H is its successor.

Now if split-horizon is disabled on the spoke routers, I don't see how this behaviour would change (the spokes would still only send a poison update to the hub router for each network advertised by the hub router), unless the spoke routers had other PVCs terminating on their multipoint interfaces.

Appreciate all responses...

Cheers,
Paresh

This communication, including any attachments, is confidential. If
 you are not the intended recipient, you should not read it - please
 contact me immediately, destroy it, and do not copy or use any part of
 this communication or disclose anything about it.



This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:55:01 GMT-3