[Battlemesh] Network configuration and address plan for Battlemesh v9

Nemesis nemesis at ninux.org
Fri Apr 22 10:52:24 UTC 2016


From:
http://docs.battlemesh.org/v8/1-the-mesh-of-death-adversity.html#configuration

"All the configuration files for each router are available on github."

https://github.com/battlemesh/battlemesh-test-docs/tree/master/v8/testbed/config

We did not like that configuration though, what we did not like was the
fact that we had to configure static routes to let che iperf client and
servers to connect one another.

Henning wrote a proposal in the beginning of this thread.

Federico



On 04/22/2016 08:37 AM, guifipedro wrote:
> You know if all this work is in a git repository?
> I mean, what you did in that WBMv8 testbed, like configuration files,
> is available somewhere, prepared to be used?
> 
> On Tue, Dec 1, 2015 at 11:42 AM, Henning Rogge <hrogge at gmail.com> wrote:
>> Okay,
>>
>> lets wakeup this thread again...
>>
>> The core of the idea is that a node with an id between 1 and 99 is
>> configured in the following way:
>> - each node has 4 fixed addresses 172.17.<id>.x with x is { 1, 201, 202, 203 }
>> - each node distributes a fixed prefix with a LOCAL DHCP-server to LAN
>> for attaching testing/debugging devices
>> - ALL IPv4 addresses of the mesh are within a /16 prefix (so we don't
>> need to push default routes to attached devices and can keep their
>> Internet connection up)
>> - the whole configuration uses human-readable IPs and can be
>> calculated from the node-ID (automatic/scripted configuration
>> generation)
>>
>> This should make it easy to attach notebooks to each node for
>> debugging, gives us a fixes address schema and still has plenty of
>> "fixed addresses" for measurement devices connected to each node
>> (172.16.<id>.101 to 172.16.<id>.200).
>>
>>
>> Address schema for 4-interface routers
>> **************************************
>>
>> eth0.1 "lan" (4 port switch)
>> eth0.2 "wan" (1 ethernet)
>> wlan0  (2.4 GHz Wifi)
>> wlan1  (5   GHz Wifi)
>>
>>
>> Node id 1 to 99
>> ===============
>>
>> layer-3 protocols:
>> ------------------
>>
>> eth0.1 172.17.<id>.1/24
>>         DHCP-server
>>                 pool: 172.17.<id>.2 to 172.17.<id>.100
>>                 subnet mask: 172.17.<id>.0/24
>>                 route: 172.17.0.0/16 via 172.17.<id>.1
>> eth0.2 172.17.<id>.201/32  mesh-if 1
>> wlan0  172.17.<id>.202/32  mesh-if 2
>> wlan1  172.17.<id>.203/32  mesh-if 3
>>
>> routing protocol distributes:
>>         172.17.<id>.0/24
>>
>>
>> batman-adv:
>> -----------
>>
>> no addresses on:                eth0.1, eth0.2,  wlan0, wlan1, bat0
>> bat0 mesh interfaces:           eth0.2, wlan0, wlan1
>> bridged interfaces:             bat0, eth0.1
>>
>> bridge addresses:
>>        172.17.<id>.201/32, 172.17.<id>.202/32, 172.17.<id>.203/32
>>        172.17.<id>.1/16
>> bridge DHCP-server:
>>        pool: 172.17.<id>.2 to 172.17.<id>.100
>>        subnet mask: 172.17.0.0/16
>>
>> activate batman gateway feature (to prevent DHCP-server from
>> connecting over bat0)
>>
>>
>>
>> New comments about this configuration? I wonder if we can move the
>> DHCP-server for the layer-3 protocols just to export the same
>> 172.17.0.0/16 mask as we do with batman adv. This would make things
>> even easier.
>>
>> Henning Rogge
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20160422/98eb7ea2/attachment.pgp>


More information about the Battlemesh mailing list