``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: .. code-block:: lnc 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: .. code-block:: lnc 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. 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 :ref:`config-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: .. code-block:: lnc 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. 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. tcp_tunnel_host --------------- host where a tunnel entry point for this network is reachable. 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. tcp_tunnel_depends_on --------------------- optional process/state dependency list that must be available before the tunnel entry should be used. 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.