[Commotion-dev] Commotion IP ranges for multiple mesh interfaces?

[Josh King]

Though we don't currently provide an interface for it, Commotion
supports generating random IPs in arbitrary ranges, not just the default
100.64.0.0/10. If you create profiles in /etc/commotion/profiles.d on
the router, just set the 'ip' parameter to an IP in the range you wish
(for instance, it's 100.64.0.0 by default) and 'ipgenmask' to the
netmask for the corresponding range in which you want to generate an IP
(255.192.0.0 by default). Then you would set assign that profile to the
corresponding mesh interface in /etc/config/network. As an example, you
could have a profile in /etc/commotion/profiles.d/commotion2ghz with the
parameters 'ip: 100.64.0.0' and 'ipgenmask: 255.192.0.0', and
/etc/commotion/profiles5ghz with parameters 'ip: 192.168.0.0' and
'ipgenmask: 255.255.0.0', and then in /etc/config/network set the
profile option for each interface to be 'commotion2ghz' or
'commotion5ghz'. On the next network reload, it will assign new IP
addresses in those ranges.

As for OLSRd, you can add more than one mesh interface. OLSRd, however,
by default adds everything to the kernel's main routing table, which
means that the node will try and forward traffic between your different
subnets. It might make sense in any event to try and achieve the
separation you're talking about (if I understand correctly) with
firewall rules rather than different OLSR instances. Because otherwise,
unless you set up OLSR to set things in different routing tables in the
kernel (and I'm not entirely sure what effect that will have on normally
routed traffic), it will try and all the routes to the default kernel
routing table whether or not you're running two instances.

On 05/30/2014 09:04 AM, Dan Staples wrote:
> On 05/29/2014 04:01 AM, miles wrote:
>> I may just be confusing myself about how to best use OLSR. 
>>
>> I ran into the problem while setting up a dual band router.  If I use the standard commotion setup, each radio thinks they are attached to the same 100.64 subnet, but they can't view the same hosts.  Olsr will eventually make this work. If I want to force traffic over the backbone, I need set the per interface weight accordingly. 
>> Right?  
>> I think this makes serval dependent on the olsrd routing table, which is unfortunate/redundant. 
> 
> For running multiple instances of olsrd, one for each separate network
> you're setting up, that will have to be done manually as the Commotion
> web interface doesn't support that. I haven't run multiple olsrd
> instances on a node before so I'm not sure how they will handle both
> updating the routing table. I imagine if each instance doesn't have
> overlapping HNA networks, and perhaps doesn't receive routes to the same
> subnets elsewhere, they won't clobber each other when updating the
> routing table. But again, I don't know as I haven't tried.
> 
> As far as Serval relying on the olsrd routes, that's just a thing we
> have to live with for now. We've been talking with the Serval folks
> about a way to decouple serval-dna's built-in routing from the MDP
> overlay network, but as of now there is no solution. They might be able
> to shed more light on that matter.
> 
>> How do you handle mixed 5ghz and 2 ghz devices today when bridged over Ethernet?  
> 
> How do you mean? Right now, using the OpenWRT built-in menus (under the
> Advanced tab in the new Commotion interface), you can use both radios
> and set up virtual interfaces on each as you need. And you could add an
> interface on the 2.4ghz radio and an interface on the 5ghz radio into a
> bridge with the ethernet interface if you like.
> 
>> I was also thinking about segmenting the backbone for security reasons - an open 2.4 ghz mesh, and a  signed & encrypted OLSR mesh for the backbone. That would allow for trusted services like NTP and "secure" routing among backbone nodes. 
>> So far, I haven't figured out how to partition olsr without quagga and a lot of pain in the middle.   
>>
>> If splitting the IP space does make sense, how about. 
>> 100.64.0/11 for stock commotion (32 Class Bs = thousands of nodes before collisions are likely. ) 
>> 100.96.0/11 for "backbone" with either a different frequency or different security zone. 
>> 100.127.127.0/17  broken into 8 /23s for point to point  links or very sparse networks (like long haul WAN repeaters). That's only  ~ 7 nodes before there is  a 1% chance of collisions, but 1/2048 is fair odds for an auto discovered private link. It may be  more efficient to require manual IP addressing .  Or even set aside one 10.x space ?
> 
> I suppose that could work, but again you'd need a new algorithm for
> auto-generating IPs in each of those ranges if you didn't want to set
> the IPs manually.
> 

-- 
Josh King
Lead Technologist
The Open Technology Institute
http://opentechinstitute.org
PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20140601/533bdfc3/attachment.sig>