multidomain.rst

Multidomain Support

Preamble

There comes a time when a mesh network grows past sensible boundaries. As broadcast traffic grows, mesh networks experience scaling issues and using them becomes very unpleasant. An approach to solve this follows the well-known “divide and conquer” paradigm and splits a large network into multiple smaller networks. These smaller networks start with a dedicated layer 2 network each, which are interconnected via their gateways by layer 3 routing. Gluon is already field-tested handling a single domain and the multidomain feature allows for the reconfiguration of key parameters that decide which domain a node participates in, without the need of a distinct set of firmware images for each mesh domain.

Overview

Multidomain support allows to build a single firmware with multiple, switchable domain configurations. The nomenclature is as follows:

• site: an aggregate over multiple domains
• domain: mesh network with connectivity parameters that prevent accidental bridging with other domains
• domain code: unique domain identifier
• domain name: pretty name for a domain code

By default Gluon builds firmware with a single domain embedded into site.conf. To use multiple domains, enable it in site.mk:

GLUON_MULTIDOMAIN=1

In the site repository, create the domains/ directory, which will hold your domain configurations. Each domain configuration file is named after its primary domain_code, additional domain codes and names are supported.

site/
|-- site.conf
|-- site.mk
|-- i18n/
|-- domains/
  |-- alpha_centauri.conf
  |-- beta_centauri.conf
  |-- gamma_centauri.conf

The domain configuration alpha_centauri.conf could look like this.

{
  domain_names = {
    alpha_centauri = 'Alpha Centauri'
  },

  -- more domain specific config follows below
}

In this example “Alpha Centauri” is the user-visible domain_name for the domain_code alpha_centauri. Also note that the domain code alpha_centauri matches the filename alpha_centauri.conf.

Additional domain codes/names can be added to domain_names, which are treated as aliases for the their domain configuration. Aliases can be used to offer more fine-grained and well-recognizable domain choices to users. Having multiple aliases on a single domain is a helpful precursor to splitting the domain into even smaller blocks.

Furthermore you have to specify the default_domain in the site.conf. This domain is applied in following cases:

• When the config mode is skipped.
• When a domain is removed in a new firmware release, the default_domain will be chosen then.
• When a user selects a wrong domain code via uci.

Please note, that this value is saved to uci, so changing the default_domain value in the site.conf in a new firmware release only affects the actual domain of a router, if and only if one of the above conditions matches.

Switching the domain

via commandline:

uci set gluon.core.domain="newdomaincode"
gluon-reconfigure
reboot

via config mode:

To allow switching the domain via config mode, config-mode-domain-select has to be added to GLUON_FEATURES in the site.mk.

Allowed site variables

Internally the site variables are merged from the site.conf and the selected domain.conf, so the most variables are also allowed in site.conf and in domain.conf. But there are some exceptions, which do not make sense in a domain or site specific way. The following sections give an overview over variables that are only usable in either site or domain context.

site.conf only variables

• Used in as initial default values, when the firmware was just flashed and/or the config mode is skipped, so they do not make sense in a domain specific way:
  • authorized_keys
  • default_domain
  • poe_passthrough
  • mesh_on_wan
  • mesh_on_lan
  • single_as_lan
  • setup_mode.skip
  • autoupdater.branch
  • mesh_vpn.enabled
  • mesh_vpn.pubkey_privacy
  • mesh_vpn.bandwidth_limit
  • mesh_vpn.bandwidth_limit.enabled
  • mesh_vpn.bandwidth_limit.ingress
  • mesh_vpn.bandwidth_limit.egress
• Variables that influence the appearance of the config mode, domain-independent because they are relevant before a domain was selected.
  • config_mode.geo_location.show_altitude
  • config_mode.hostname.optional
  • config_mode.remote_login
  • config_mode.remote_login.show_password_form
  • config_mode.remote_login.min_password_length
  • hostname_prefix
  • mesh_vpn.fastd.configurable
  • roles.default
  • roles.list
• Specific to a firmware build itself:
  • site_code
  • site_name
  • autoupdater.branches.*.name
  • autoupdater.branches.*.good_signatures
  • autoupdater.branches.*.pubkeys
• We simply do not see any reason, why these variables could be helpful in a domain specific way:
  • mesh_vpn.fastd.syslog_level
  • wifi*.supported_rates
  • wifi*.basic_rates
  • timezone
  • regdom

domain.conf only variables

• Obviously:
  • domain_names
    • a table of domain codes to domain names domain_names = { foo = 'Foo Domain', bar = 'Bar Domain', baz = 'Baz Domain' }
  • hide_domain
    • prevents a domain name(s) from appearing in config mode, either boolean or array of domain codes
      • true, false
      • { 'foo', 'bar' }
• Because each domain is considered as an own layer 2 network, these values should be different in each domain:
  • next_node.ip4
  • next_node.ip6
  • next_node.name
  • prefix6
  • prefix4
  • extra_prefixes6
• To prevent accidential bridging of different domains, all meshing technologies should be seperated:
  • domain_seed (wired mesh)
    • must be a random value used to derive the vxlan id for wired meshing
  • wifi*.ibss.ssid
  • wifi*.ibss.bssid
  • wifi*.mesh.id
  • mesh_vpn.fastd.groups.*.peers.remotes
  • mesh_vpn.fastd.groups.*.peers.key
  • mesh_vpn.tunneldigger.brokers
• Clients consider WiFi networks sharing the same ESSID as if they were the same L2 network and try to reconfirm and reuse previous addressing. If multiple neighbouring domains shared the same ESSID, the roaming experience of clients would degrade.
  • wifi*.ap.ssid
• Some values should be only set in legacy domains and not in new domains.
  • mesh.vxlan
    • By default, this value is true. It should be only set to false for one legacy domain, since vxlan prevents accidental wired merges of domains. For old domains this value is still available to keep compatibility between all nodes in one domain.
  • next_node.mac
    • For new domains, the default value should be used, since there is no need for a special mac (or domain specific mac). For old domains this value is still available to keep compatibility between all nodes in one domain.

Example config

site.mk

site.conf

domains/alpha_centauri.conf

i18n/en.po

i18n/de.po

modules