3.7. `network` section

network sections describe which host interfaces belong to the same logical network.

Their main purpose is to let ln_manager understand connectivity between hosts, especially when some subnets are not routed globally. With that information, ln_manager can decide whether two participants can communicate directly or whether it must use an intermediate host / ln_daemon for forwarding.

syntax:

NETWORK_SECTION := "network " + NETWORK_NAME + "\n" + NETWORK_SETTING*

example:

network control_net
member_interfaces: 192.168.10.0/24, host_a/eth0, host_b/eth0
preferred_gateways: host_a

Another realistic example is a setup with two non-routed networks:

network rmc-network
member_interfaces: 129.247.189.0/24, 10.97.0.0/16, 192.168.8.0/24

network mobilnetz
member_interfaces: 192.168.128.0/23, 192.168.136.0/21

In such a setup ln_manager can detect that some hosts are only reachable via an intermediate machine that has interfaces in both networks.

3.7.1. member_interfaces

member_interfaces is the main setting of a network section. It defines which interfaces or IP subnets belong to that network.

Accepted forms include:

an explicit interface reference such as workstation01/eth0
a host/interface identifier that can be resolved by the parser
an IPv4 network mask written as IP/BITS such as 192.168.10.0/24
an excluded interface or unresolved spec prefixed with !

For simple and maintainable configurations, use the physical host names from the hosts section here. For example, if the hosts section contains workstation01: eth0:10.0.0.11, the network should normally refer to that interface as workstation01/eth0. Keep logical names such as nodeA or robot for node_map and process node: settings.

The most common form is a comma-separated list:

member_interfaces: 192.168.128.0/23, 192.168.136.0/21, rmc-ap0107/en0

As with other list settings, repeated add member_interfaces: ... lines are also supported.

Behavior details:

explicitly resolved interfaces are attached to the network
mask entries are stored as network masks and later matched against host interfaces by IP address
excluded entries are remembered and prevent those matches from being used
using multiple smaller masks is often preferable to one broad mask if the broader subnet would accidentally match unrelated local interfaces

This is exactly why configurations sometimes use multiple masks such as 192.168.128.0/23 and 192.168.136.0/21 instead of a single broader 192.168.128.0/20 network: it avoids matching nearby but unrelated local subnets.

3.7.2. preferred_gateways

preferred_gateways is an ordered list of host names. If present, interfaces belonging to those hosts are prioritized in that order when the network sorts its member interfaces.

This is mainly useful when more than one possible forwarding path exists and one gateway host should be preferred.

3.7.3. tcp_tunnel_host

host where a tunnel entry point for this network is reachable.

3.7.4. tcp_tunnel_entry

entry specification for the tunnel. If this is set without tcp_tunnel_host, the parser assumes 127.0.0.1 as the tunnel host.

3.7.5. tcp_tunnel_depends_on

optional process/state dependency list that must be available before the tunnel entry should be used.

3.7.6. Notes

If no networks are configured at all, ln_manager creates fallback networks automatically during config finalization. Explicit network sections are useful when you want precise control over interface grouping, forwarding decisions, or preferred gateway ordering.

3.7. network section