[B.A.T.M.A.N.] dublicate HNAs
neumann at cgws.de
Thu Dec 11 10:54:31 UTC 2008
On Dienstag 09 Dezember 2008, Stephan Enderlein (Freifunk Dresden) wrote:
> Another question: in previous versions I have seen that if two batmand
> announce the same HNA ip (-a) one of the batmand are ignored and complete
> ignored any batmand traffic. As result the node was removed from any
> batmand list and was not reachable anymore.
And it should be also the current behavior of bmx. The background is:
BMX currently does NOT support anycast routing.
Therefore in practical terms, if two nodes are announcing the same IP it is
effectively an IP doubler. Such a scenario triggers the dublicate-address
detection which results in ignoring the younger of the two nodes announcing
With the batman routing algorithm it is indeed difficult to do a consistent
anycast routing. Therefore I've decided to protect against casual duplicate
address announcements with the described behavior.
Older versions (2007 and before) tended to have chaotic routing entries due to
duplicated entries or removals of HNA routing entries.
When dynamically adding an HNA (using e.g. bmxd -ca 188.8.131.52/32) the daemon
checks if other nodes are already announcing this specific HNA. If this is
the case the announcement is rejected and a warning should be given in
debuglevel 3. You can always inspect current announcements from other nodes
using debug-level 9.
This debug-level also differentiates between announced interfaces (e.g.
184.108.40.206/IF) and networks (e.g. 220.127.116.11/32). ( the idea for the future was,
that network announcements should become anycast announcements )
Indeed it is a problem when a daemon is started from the beginning with a
duplicate HNA announcement. In this situation the daemon can hardly check if
the network is already announced. Then, only his neighboring nodes are aware
of the IP doubler. They will ignore everything from this node and cause a
warning in debug level 0.
hope this clarifies a bit.
More information about the B.A.T.M.A.N