Configuration Management in 60 GHz cnWave

This article describes the configuration management system in 60 GHz cnWave.


CnWave implements a centralized configuration management architecture. The E2E controller serves as the point of truth for all node configurations, and is responsible for keeping all nodes’ local copies in sync with its own view. All config changes are applied using the controller.

Syncing Configuration

To keep config in sync, nodes send an MD5 hash of their local configuration to the controller in their periodic status reports. The controller periodically iterates over all received status reports and looks for mismatches with its computed configuration. For each mismatch, the controller will push a new node configuration to the minion (a process in all nodes), as described above. There is a fixed interval between consecutive pushes to the same node, as a protective measure in case the new configuration causes a fatal error on the node; this delay is reset when the controller receives a configuration change.

The automatic config sync can be disabled by “un-managing” the network or specific nodes via a special configuration field “E2E Managed Config” . This may be needed temporarily for testing purposes

Staged Rollout

The controller contains an optional scheduling algorithm, to roll out configuration changes that affect multiple nodes in batches (e.g. when changing network level settings). This protects against network-wide service disruption and network isolation, but will delay the propagation of configuration changes.

To enable this staging algorithm, set the config_staged_rollout_enabled flag on the controller; by default, all config updates to nodes are sent simultaneously.

Configuration fields


Settings under Network apply to all the nodes in the network. Some apply to the E2E Controller


Enable Layer 2 bridge

By default, cnWave is a IPv6 only network. By selecting this checkbox, you will be enabling Layer 2 network bridging (via automatically created tunnels) across all nodes connected to a PoP. This will facilitate bridging of IPv4 traffic across the wireless networks. Release 1.0 supports Layer 2 bridge in single PoP deployments only. Future releases will support in multi PoP deployments.

Prefix Allocation

CnWave networks are given an IPv6 “seed prefix” (e.g. face:b00c:cafe:ba00::/56 ) from which subnet prefixes are allocated to all DNs and CNs. There are two methods for allocating node prefixes with Open/R

Centralized (default) - Centralized prefix allocation is handled by the E2E controller. The controller performs all prefix allocations, which prevents collisions and enables more sophisticated allocation algorithms. This is recommended for single PoP networks

Deterministic - Deterministic prefix allocation is also handled by the E2E controller. The controller assigns prefixes to nodes based on the network topology to allow PoP nodes to take advantage of route summarization and help load balance ingress traffic. This is recommended for multi PoP networks

Seed Prefix

The prefix of the entire CnWave network, is given in CIDR notation.

Prefix Length

Specifies the bit-length of prefixes allocated to each node


Country for regulatory settings like EIRP limit, allowed channels

Enabled Channels

The comma separate list of channels given to the controller for auto configuration. Manual settings in Node->Radio page do not depend on this setting. This setting is useful especially for PTP and small meshes that use single channel for the entire network. In such cases, set the required channel here and do not override in the node->Radio page. For a channel change, changing this setting alone will do.


DNS Servers

Comma separated DNS server list using for

  • Resolution of NTP Sever host name. Can be IPv4 when Layer 2 bridge is enabled
  • Given to IPv6 CPE as part of Router advertisement

Time Zone

Time zone for all the nodes. System time in the dashboard, time field in the Events section, Log files use the timezone.

NTP Servers

Comma separated NTP Sever FQDN or IP Address. All nodes will use this NTP Sever to set the time. Node time is important when 802.1X Radius authentication is used as it requires certificate validation. The time is reflected in the dashboard, time field in the Events section, and Log files .

E2E Managed Config

Determine whether the controller manages the node’s configuration. Highly recommended to keep it enabled.



Wireless Security

  • Disabled. There will be no wireless security
  • PSK – WPA2 Pre shared key. Wireless security is enabled using the internal pre shared key. AES 128 bit encryption is used.
  • 802.1X – Nodes will be authenticated using Radius server. Uses EAP-TLS. Encryption is based on the negotiated scheme in EAP TLS.

Radius Server IP

IP address of Radius authentication server

Radius Server port

Radius authentication server port

Radius server shared secret

Shared secret of radius server



Enable SNMP

Statistics can be read from the nodes using SNMP. This setting enables SNMP

System Contact

Sets the contact name as the System.sysContact.0 MIB-II variable.

System Location

Sets the location name as the System.sysLocation.0 MIB-II variable.


SNMP Community string

Read only SNMP community string

Source address

When specified, SNMP queries are allowed from the hosts belonging to this IPv6 prefix.


SNMPV3 user settings are self explanatory

User Passwords


Password for the GUI users can be configured here. Monitor is a read only user.


These settings apply to individual nodes selected in the left side panel. For example a node named V3000_CN is selected in the below snippet



Maximum EIRP

The maximum EIRP transmitted by the radio. Range differs based on the platform and country selected (in Network page).

IBF Transmit power

Transmit power using during initial beam forming. When all the links are in short range, high transmit power can cause interference. Selecting short range optimized will prevent this. Post beam forming, automatic power control will make sure the radio transmits at optimal power

PTP Deployment Range


This configuration is applicable for V3000 and in PTP topology. Based on the range, wireless slot timings are optimized. Its important to first change the far end device.



Minimum and Maximum MCS used by the radio. To restrict to a particular MCS, set both as same.

Channel and Polarity


When link is created in topology, controller automatically sets the sector’s channel and Polarity. Its shown in the third column in the above picture. To manually override, click the check box and select the channel in the node config. Note that changing channel/polarity will break the link. Its important to change for leaf nodes first and then higher up on DNs

Golay codes


Golay codes help in avoiding inter sector interference. In rare scnerios, individual links might require separate golay codes. Most scenraios, all the link belonging to a sector are configured same golay. Controller automatically sets the golay code. To manually override, select the check box and set the golay from the drop down. ‘Override All’ button helps in setting the same goaly for all the links in one go.

Force GPS disable

In some scenarios like lab setups, it may be necessary to disable GPS.



IPv4 Address

Static IPV4 address of the individual node. Node’s GUI /CLI can be opened using this IP address when directly connected over ethernet. For Over the Air access, L2 Bridge should be enabled. Its predominantly used on PoP nodes with onboard controller.

Subnet Mask

Subnet mask for the IPv4 address

Gateway IP Address

IPv4 Gateway address


Management VLAN

Click the check box to enable Management VLAN. Device Management traffic can be assigned a separate VLAN to separate it from user traffic. Management traffic includes web access, RADIUS , NTP etc. All the traffic generated by the node.

Management VLAN ID

Specify the VLAN ID. It can be one of the values from 1 to 4094. Incoming management traffic should contain the tag and outgoing traffic will be tagged.


POP Routing

PoP nodes connects to the upstream IPv6 router in one of the two ways

  • BGP – PoP acts as a BGP Peer
  • Static Routing – IP gateway address should be specified on the PoP and static route should be added on the upstream router.

When the system is targeted for L2 traffic (Layer 2 bridge enabled) and onboard controller is used, this configuration is of not much significance, recommended to set to static routing

POP Interface

Wired interface on which PoP communicates to upstream router or switch when L2 bridge enabled.

IPv6 Gateway Address

Gateway address. Can be left empty when L2 bridge is enabled and no IPV6 services like NTP /Radius are used.

E2E IPv6 Address


Address of E2E Controller. When using onboard controller on the same node, can be left empty and GUI automatically fills the POP IPv6 address.

E2E Network Prefix

Seed Prefix in the CIDR format followed by a comma and the prefix length. Should be specified when BGP is used. Otherwise, optional.

IPv6 CPE Interface

IPv6 SLAAC provides IP prefix to downstream CPE devices. Keep it disabled when L2 Bridge is active.

Ethernet Ports


Individual Ethernet ports can be turned off with this configuration


Enable Aux port power

Enable PoE out (25 W) on V5000/V3000 aux port. 802.3af and 802.3at compliant devices could be powered up, passive PoE devices cannot be powered up. Note that aux port cannot power another V5000.

Layer 2 Bridge

Note: Layer 2 config is present only on POP

Disable Broadcast Flood

When enabled, POP drops the downstream broadcast traffic. These broadcast packets could be generated from upstream or from other mesh nodes/downstream devices. This can be used for ‘Client isolation’ where subscribers cannot send packets to each other.

Disable IPv6

When enabled, IPv6 traffic is not transported in the Layer 2 tunnels

Relay port

Specify the Ethernet interfaces on which OpenR is run. Its needed in two cases

  • When DNs are connected back to back
  • When multiple POPs are in the network. This allows PoP nodes to forward traffic to other PoP nodes via a wired connection when the routing path of the other PoP node is closer to the traffic’s destination


Configuration options under Network-> Advanced and Node->Advanced are for advanced users who understand the cnWave configuration model well. In general, its recommended not to use these options

cnWave is based on Facebook’s Terragraph architecture. It follows a layered configuration model, with a node’s “full” configuration computed as the union of all layers in the following order:

  • Base configuration - The default configuration, which is tied to a specific software version and is included as part of the image. The controller finds the closest match for a node’s software version string, and falls back to the latest if no match was found.
  • Firmware-specific base configuration - The default configuration tied to a specific firmware version, which is also included as part of the image. Values are applied on top of the initial base configuration layer.
  • Hardware-specific base configuration - The default configuration tied to a specific hardware type, which is also included as part of the image. Each hardware type supplies configuration that changes with software versions. Values are applied on top of the firmware base configuration layer.
  • Automated node overrides - Contains any config parameters for specific nodes that were automatically set by the E2E controller.
  • Network overrides - Contains any config parameters that should be uniformly overridden across the entire network. This takes precedence over the base configuration and automatic overrides.
  • Node overrides - Contains any config parameters that should be overridden only on specific nodes (e.g. PoP nodes). This takes precedence over the network overrides.

The E2E controller manages and stores the separate config layers. cnWave nodes have no knowledge of these layers, except the base configuration on the image. The nodes will copy the latest base version (via natural sort order) if the configuration file on disk is missing or corrupt.


Network->Advanced tab shows the merged configuration from Base layer till Network override layer.

Lets us look at an example, ‘’. Its set to ‘Finland’ in the above screen and marked as modified with a star symbol. This means that this parameter is modified by the user and applies to all the nodes in the mesh network.

JSON view will show only the overrides.


Node->Advanced shows the merged configuration off all layers for a particular node

The above screen shows advanced config of PoP node. We can see that PoP params are marked as modified, meaning a node level override is set.

Note that most of parameters are repeated at Node and Network overrides. A parameter can be modified at Network level, meaning it applies to all nodes and the parameter can be modified at a specific node. Node override takes higher precedence.

Network overrides are also visible at this screen. Below screen shows country parameter, what can set at network, and not changed for this specific node.

The star symbol helps to distinguish it as a network override.