OpenWiFi 2.0
Creating logical bridges may be done through association to named "interfaces". To associate a logical SSID interface directly to the WAN, place SSID configuration within the interface have a "role" of upstream.
OpenWiFi 2.0
Creating a NAT Gateway is easily done via association to an interface having a role of "downstream".
Based on the above Dual SSID NAT configuration, a unique 2GHz and 5GHz SSID are created and logically bound to the same NAT LAN side network.
The NAT service is inherited by the downstream role with DHCP addressing defined according to the range set within the downstream "ipv4" configuration.
OpenWiFi 2.0
OpenWiFi device features are configurable through understanding the uCentral device data model.
For integrators of commercial controllers, these feature examples may help guide development of device provisioning within a partner controller products.
Experimentation with device features often occurs initially through static configuration as JSON document sent to a device using the OpenWiFi Gateway.
Commercial products with OpenWiFi device provisioning will be using the northbound API to create, update, delete per device configurations. These APIs are then inter-worked southbound via the OpenWiFi Gateway to devices.
Some of the available device features are exposed in this same manner using the OpenWiFi Provisioning service. This provisioning service offers an additional way for commercial partners to consume OpenWiFi and integrate a controller or back office environment that may require device provisioning when that functionality is not present as part of a controller or other commercial product.
The following pages guide the user to understanding each of these features individually including example configuration information.
One of the benefits of the new data plane in OpenWiFi 2.0 is the flexibility of physical port to logical forwarding that is easily conveyed through configuration structures.
New protocol support is both easily added to the system as well as associated with interfaces by their role in the device.
The following sections offer feature configuration examples.
For complete reference to the device data model please refer
OpenWiFi 2.0
The most common use case for VLANs and Wi-Fi is likely the service provider, venue, enterprise where Wi-Fi traffic is not subject to address translation. This is the example that will be shown, however it is entirely possible to create multiple downstream VLANs with SSIDs as well. Simply replace the logic of upstream to downstream where desired.
In all cases the WAN port without VLAN id is using DHCP to obtain a management IP address. Each additional "upstream" role interface with an SSID associated have no IP configuration.