Cloudless Router Operation - Advanced Networking

Design

General

These are the feature purposes:

1. On loss of internet access for any length of period, the previously Ethernet-connected gateway node will continue to work on the LAN side. The node will try to keep the network in the same state which means any possible leaf connections will be kept.

2. On reboot or multiple reboots of a node with no internet access, the node will configure itself from a stored subset of OVSDB config (provisoned by the controller when node was previously connected) providing limited functionality by configuration which setups the default Home LAN so that the node will continue to work including the following:

   1. Continue with the previously enabled bridge/router configuration.

   2. Primary SSID & PSK.

   3. Existing static DHCP reservations and user-configured subnet.

   4. User-configured primary/secondary DNS servers.

Features that are not supported (including but not limited to):

• Port forwarding entries

• IPv6 LAN support

• Multi-PSK

• Onboarding or backhaul SSID

• OpenFlow rules besides default

• FSM configuration

• Steering configuration

• Third-party services

Implementation Details

When the feature is enabled and when a GW node is normally connected to the controller, the node monitors a subset of OpenSync OVSDB and actively stores this subset to persistent storage (if the node detects changes in the monitored subset of config). The OpenSync 2.0 osp_ps persistent storage API is used. For optimization purposes and to reduce the number of flash cycles, the actual saving to persistent storage is done only if the new config differs from the saved config. The config is saved in JSON format.

The feature is currently implemented within the Platform Manager (PM).

Triggering the gw_offline state is done by the Connectivity Manager (CM) manager because CM has information about the controller connection availability and stability. CM will only trigger gw_offline state when controller connectivity checks fail within certain timeouts. CM will trigger gw_offline in two cases:

• If the node was booted without controller connectivity: in this case, PM applies the stored config.

• If the node had normal controller connectivity (i.e., was configured by the controller) and connectivity is lost without a reboot. In this case, PM does not apply the stored config because the node already is in a configured state. However, PM still enters the gw_offline state. While in gw_offline state, the node continues to handle some additional offline tasks.

How to restore the saved configuration to OVSDB in gw_offline mode? Certain config OVSDB tables or rows can be simply replayed in OVSDB.

Northbound API

The gw_offline feature monitors a subset of OpenSync OVSDB config on a GW node. The feature also configures the OpenSync OVSDB config on a GW node when in gw_offline mode. The config is applied from the stored config.

Using the gw_offline state requires dedicated OVSDB interface fields in the Node_Config and Node_State tables with these purposes:

• To enable or disable the gw_offline feature.

• To enable or disable monitoring of OVSDB config.

• To enable communication between CM and PM.

OVSDB includes flags for:

• CM to trigger the gw_offline state in PM

• PM to report the gw_offline state (enabled/disabled)

• PM to tell if the config is available

• Signaling that PM has actively applied the config

Offline Service Availability