[Babel-users] About split horizon in Babel, and scaling the number of neighbours

[Baptiste Jonglez]

Hi,

As far as I know, split horizon is usually done by routing protocols in
order to prevent the most common cases of routing loops.

Babel also implements split horizon, but the goal doesn't seem to be loop
prevention — probably because it has more sophisticated ways of preventing
routing loops.  Instead, split horizon is an optimisation performed when
an interface is known to be transitive.  Quoting RFC 6126:

3.7.4.  Split Horizon

   When running over a transitive, symmetric link technology, e.g., a
   point-to-point link or a wired LAN technology such as Ethernet, a
   Babel node SHOULD use an optimisation known as split horizon.  When
   split horizon is used on a given interface, a routing update is not
   sent on this particular interface when the advertised route was
   learnt from a neighbour over the same interface.

   Split horizon SHOULD NOT be applied to an interface unless the
   interface is known to be symmetric and transitive; in particular,
   split horizon is not applicable to decentralised wireless link
   technologies (e.g., IEEE 802.11 in ad hoc mode).



Thus my question: how well does Babel perform when having many neighbours
on the same interface, with and without split horizon?

More specifically, I'm looking for data (either operational or
theoretical) regarding:

- control traffic as a function of the number of neighbouring nodes on the
  same interface (with and without split horizon).  I would expect it to
  be linear with split horizon and quadratic without split horizon, does
  that sound right?

- hard limit on the number of neighbours, with and without split horizon
  (what would be the bottleneck?  CPU usage?  network throughput?
  possible implementation limitations?)

Testing and measuring would not be so hard to do, but time-consuming.
If somebody already has experience with this, any input is highly welcome :)


The VPN topology I'm currently exploring (based on Tinc) has unusual
properties: it is "mostly" transitive, meaning that it will usually look
like a full mesh, but a number of edges will be missing.

I'm wondering whether this topology would scale if disabling split
horizon.  On the other hand, what could go wrong if split horizon is
enabled?  Will some routes fail to propagate?


Thanks,
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20140620/9dc4d2e8/attachment.sig>