Document how IPv4 routing works in gluon

[mraerino]

This issue tries to untangle the mechanisms that exist in Gluon to make a reliable setup easier.

Gluon Config Docs

local node support (aka anycast)

This feature allows client to reach the node they are connected to using a stable layer 2 (mac) and layer 3 (IP) address. Gluon uses ebtables rules and ARP to realize this.

Example:

next_node = {
  ip4 = '10.23.42.1',
  ip6 = 'fdca:ffee:babe:1::1',
  mac = '16:41:95:40:f7:dc',
  -- DNS names to be statically configured for reaching the anycast IP (optional)
  name = { 'nextnode.location.community.example.org', 'nextnode', 'nn' },
}

batman gateway selection (aka DHCP filtering)

batman docs

the gateway feature of batman allows to ensure that DHCP requests will only be forwarded to a single DHCP server even if multiple exist on the mesh.

This means that it's possible to run a DHCP server on each gateway without the need to synchronize their state or do leader election to decide which is the designated server to reply to requests.

consequences for the supernode setup

• all supernodes can run their own DHCP server
• DHCP servers don't need to do leader election
• DHCP servers don't need to sync their state if their pools are disjoint sets
• no VRRP needed, the anycast IP can be announced in DHCP

Open questions:

• If the anycast address is used in DHCP, what default route do the gluon nodes use?

[dagofr01]

Prima, vllt wird ja dann klarer, wieso das nicht tut von Domain zu Domain