Technical Description of Networking Component Operation

This document details the operation of networking components used to provide services to Conference Tool. As discussed in the document, several networking components must be deployed and configured at a venue to enable conference networks to be created using Conference Tool. Each networking component will be discussed, together with the functions used to provide conference networks at a venue.

There are slight variations in operation depending on the vendor equipment deployed. These will also be discussed in this document.  

TABLE OF CONTENTS

• Audience
• Network Deployment Overview
• Network Topology
  • Wireless Access Points
  • Network Switches
  • Wireless Controller
    • Access Methods
  • Connector
  • Mikrotik Gateway
    • LAN Interface
    • VLANs
    • Bridges
    • Network
    • DHCP Servers
    • Firewall
    • QoS Queues
    • WAN Interface
• Sample Scenario
  • Wired Network Connectivity
  • Mikrotik Gateway Network Connectivity
  • Wireless Controller Configuration
• Conference Tool Lite Mode Considerations

Audience

This document is primarily technical in nature and is intended for Airangel staff who may be deploying, configuring or troubleshooting the network components of Conference Tool.

Network Deployment Overview

There are several networking components that must be deployed at a venue to provide the Conference Tool service. In most instances, much of this infrastructure is already deployed at each venue as part of the guest service provided for general guest access via Airangel Captivnet. In summary, the following network components are used by Conference Tool:

• Wireless access points deployed around the venue to make conference wireless networks available over Wi-Fi

• Wired network data outlets for conferences that need one or more wired connections. These are provided via network switches deployed around the venue.

• A wireless controller to manage the configuration of the wireless access points. Note that some wireless solutions may provide this feature in the cloud rather than via on-site hardware.

• A Mikrotik gateway device which is responsible for functions such as bandwidth enforcement, network segmentation, NAT, hotspot, rate limiting and Quality of Service (QoS) functions.

• (Optionally) A “Connector” device which is required when Ruckus ZoneDirector or Aruba Instant wireless solutions are deployed. The Connector provides a proxy connectivity function to allow configuration of the wireless solution via CLI as no API is available.

Network Topology

A high level view of a typical network topology is provided above.  A more in-depth description of each component is provided below. The components are covered going from right to left in the diagram above:

Wireless Access Points

Wireless access points (APs) are provided around all areas of the venue where wireless networking coverage is required. They are typically deployed in a local switching mode, so that user traffic is dropped on to a local VLAN at the AP and trunked across the wired network to hit the gateway device. In addition to VLANs for user traffic, a management VLAN is provided to each AP for control & management traffic that is required between the AP & its controller.

Due to the requirement to support multiple AP VLANs, a trunked switch port is required to connect the AP to the wired network switch. The switch port must be configured to carry the VLANs for both user and management traffic. Note that this may include a mix of VLANs  for the guest network, conference networks and management traffic. The VLAN that will be used for each conference is not known ahead of time, as a pool of VLANs is assigned for use by conference tool.

APs will also typically be deployed in “AP groups”, though the terminology used will vary between AP vendors. In summary, APs that share a common trait (such as their location) may be grouped so that common configuration attributes may be applied to each group. In the case of Conference Tool, each AP group is used to identify a discrete area of the venue. Note that an AP group may be a single AP, or could contain several APs in an particular area. This area may be a meeting room, a conference hall or some other limited coverage area where a conference network may need to be provisioned. Obviously the smaller each AP group, the more granularity in providing targeted conference networks may be achieved. When using the configuration tool to deploy networks, AP groups are called “Locations”, as this is a more use-friendly name for non-technical personnel who may use the tool. (Note: In reality, Conference Tool locations are tied to wireless LAN groups that map to AP groups. But, the net result (and for ease of explanation) is that AP groups are tied to each location)

When a conference network is scheduled for deployment, one or more locations may be selected to broadcast that network. Under the hood, this means that the wireless SSID for that conference will be pushed out to the AP groups on the wireless controller that have been configured for the conference network. (Note: AP groups creation is not performed by Captivnet - they are static entities that are configured by the network provider when the network infrastructure is installed.)

Network Switches

Venues will have several network switches to provide the wired connectivity required to support the wireless network APs. They also connect other components such as gateway devices, the wireless controller, other venue hardware devices and data sockets that may be needed for conferences. They are also generally used to provide power over Ethernet (POE) to power APs across a venue.

As with the access points described above, Captivnet performs no configuration of the switches. Each network  switch is configured when the network is initially installed, with the required port configurations and switch VLANs all pre-configured for use by Conference Tool.

Each switch port that may be used for conferences needs to be assigned to its own unique VLAN. The port will generally be presented to end users as a wired data socket in a conference area or room. When the data port is required for a conference, its VLAN is joined on the gateway device to the bridge that is assigned to the conference. This splices both the wired and wireless network components together to form the complete conference network. More details on the VLANs and bridges used will be provided in a later discussion in this document around the gateway device.

Wireless Controller

The wireless controller is responsible for distributing the management and configuration data require by access points across the venue. This will include data such as radio channels, power levels, wireless networks and VLANs that should be used by APs in the venue. Note that the example shown in the diagram shown above  shows a controller deployed physically at the venue. However, there are also solutions that now allow the deployment of the controller function as a cloud-based (virtual machine) option, or as a pure cloud service with no single instance of a wireless controller entity.

The configuration of the wireless controller is again performed by the network service provider at the time that the solution is deployed.  However, Captivnet does perform a small number of configuration actions on the controller when the start time for the conference time arrives. The required wireless network (SSID) will be created using the details specified in the Conference Tool UI. It will then be deployed to the AP groups that correspond to the locations selected in Conference Tool - this provides the capability to provide the conference SSID only in the areas where it is required. 

Captivnet uses a variety of different management methods to perform the required configuration steps to make a conference network available. Many solutions provide a REST API for access, but some rely on CLI scripting where no API option exists. Some wireless solutions use an on-site controller, while other uses a cloud-based controller or service. Note that where no API exists, as “connector” device is required (discussed later).

Each wireless solution has its own terminology in terms of the grouping and mapping methods it uses to associate a conference SSID with a network VLAN. Each vendor solution will be detailed separately in later documents.

Access Methods

Here is a summary of the current access methods used to stand up networks on each supported wireless solution:

Connector

For on-site, hardware-based wireless solutions that have no REST API to allow configuration of the wireless controller, a Connector instance is required.

In summary, this is an instance of a Linux image created by Airangel that may be run on a VM on-site, or (more typically) on a small Linux appliance that is installed as part of the Captivnet solution.

The Connector acts as a proxy device for Captivnet, transforming API calls from Captivnet in to CLI commands that are sent to the wireless controller over an SSH session between the Connector and the on-site wireless controller. The connector obviously requires login credentials to the wireless controller CLI, with sufficient rights to make configuration updates to create conference networks.

Captivnet requires access to the Connector via a public IP address to send its API calls. It must also hit port 443 on the connector for HTTPS access. In practice, this will require a network port to be opened on the venue firewall, together with port and network address translation to provide the required access to the on-site Connector. Note that although port 8443 is shown on the public side of the firewall, any port may be used to translate to 443 inside the network. 

Mikrotik Gateway

The Mikrotik gateway is the core hardware component used by Captivnet to provided conference networks. It is generally already provisioned as part of an existing guest solution. The gateway sits inline with the traffic from the venue wired network and the outside network connection(s) that provide access to the Internet. 

All configuration of the gateway is performed from Captivnet. The Mikrotik runs a regular polling script that calls in to the Captivnet service every 30-60 seconds. If any configuration changes are made on Captivnet for the gateway, then an updated configuration file will be downloaded and applied to the gateway during the next poll cycle to provide the new features or services required.

Much of the required configuration required for conference tool will be added to the gateway when it initially installed. This static, pre-provisioned configuration remains on the gateway, ready to be used when a conference is required. This includes configuration elements such as bridges, VLANs, layer 3 networks and DHCP scopes.

When a conference event starts, additional configuration is dynamically added to the gateway from Captivnet to add features such as bandwidth limitations for the conference and the internal hotspot service used to redirect users to the Captivnet portal for login.

The main networking elements used within the gateway to provide conference connectivity are discussed below. There is also a diagram provided below that provides an example logical connectivity that may be useful for reference when reviewing the elements discussed next.

LAN Interface

The LAN (Local Area Network) interface on the Mikrotik gateway an Ethernet port on the device that is designated for use as the connectivity point to the venue wired network. It provides the “inside” zone of connectivity in the gateways inline connectivity path. Any physical Ethernet port may be used as the LAN port. Once the LAN port is chosen, all other configuration associated with the traffic flows for the conference tool will be tied to this port.

The choice of which port to designate as the LAN port is made at the time of installation of the gateway. Although we are considering the conference tool in this document, note that other venue services may also flow across this physical interface. 

VLANs

The venue network is segmented in to several virtual VLANs to provide isolation of networks created for different purposes. In the case of the networking tool, a number of VLANs are created to provide a dedicated network for each conference. At the time that a conference commences, an SSID is created on the wireless APs via the wireless controller and that SSID is assigned to one of the conference VLANs that are available.

An important point here is that the VLANs for the conference are all pre-provisioned at the time of network installation so that a pool of VLANs are available for the conference tool to use. VLANs are not dynamically created, a VLAN is chosen from the pool available and the SSID that is created is assigned to the chosen VLAN (in reality it is a bridge that is chosen on the Mikrotik, but as each bridge is mapped to a VLAN, the next effect is that a VLAN is chosen - see next section for more details). The number of VLANs created for the conference tool must therefore be at least as many as the expected number of concurrent conferences at the venue.

On the Mikrotik gateway, a VLAN instance is created for each conference VLAN that has been created on the venue wired network. The VLAN identifiers (e.g. VLAN 100) must match the VLANs configured on the wired network,

The VLAN instances created on the Mikrotik for conferences are assigned to the chosen physical port that has been designated as the LAN port.   

Bridges

The Mikrotik gateway supports the concept of layer 2 bridges that may be used to join various interfaces to perform traditional bridging/switching functions.

A bridge is required for each conference network to hook together the VLANs for that conference at layer 2. In many instances there is only one VLAN for a conference, so there is a one to one mapping of conference VLANs to bridges. This VLAN is for the wireless network that is provided for the conference.

However, if one or more wired (switch) ports are required for the conference, each of these ports is assigned own dedicated VLAN and can be dynamically grafted on to the conference network by hooking it in to the conference bridge within the Mikrotik. 

Just to re-iterate, the VLANs created for conference wireless networks are statically assigned to a bridge at the time of installation of the Mikrotik - one conference VLAN is assigned to one conference bridge. This does not change, even as conferences start and end. If a wired port is required for a conference, its VLAN is dynamically assigned to the conference bridge through a configuration update applied by Captivnet. When the conference ends the wired port VLAN is removed from the bridge.

Network

Each of the conference networks created for Conference Tool requires a layer 3 interface, for the purposes of routing and NAT translation. In Mikrotik terminology, these are referred to as “Networks”. To avoid confusion, these will be referred to as a “layer 3 interface” from this point forward, as “Network” has many other meanings in the networking world.. A layer 3 interface is required for each conference bridge that has been created. An IP address is assigned to the interface, which acts as the default gateway for devices on that conference network.

As with previous configuration components, the details of the layer 3 interface are chosen at installation time. The IP subnet details that are assigned must take account of the number of devices that may be used on the conference network. For instance, if many hundreds of devices may be connected, then a appropriately sized subnet mask for the network should be chosen. 

(Note: it is possible to run a conference network with a “dark” VLAN with services such as IP routing provided by other devices if required, though this is a rare scenario.)

DHCP Servers

The Mikrotik gateway (generally) acts as the DHCP server for all conference networks. A DHCP server instance is created for each conference network and is tied to the layer 3 interface on the gateway for the conference. DHCP request broadcasts from devices on the conference networks with flow across the venue network VLAN, through the Mikrotik VLAN and bridge instances and hit the DHCP service that is tied to the layer 3 interface. 

(Note: it is possible to run a conference network with a “dark” VLAN with services such as DHCP provided by other devices if required, though this is a rare scenario.)

Firewall

As the conference networks reside in private address space on the venue network, they need to have network address translation (NAT) applied so that user traffic can sit behind a public IP address and access the Internet. The Mikrotik firewall provides this feature. Each of the conference networks is subject to NAT. Again this is another feature that uses static configuration applied at install time to the Mikrotik.

(Note: Other advanced features provided by the Mikrotik gateway such as rate limiting and QoS features have not been included in this discussion. These will be covered in an advanced topics document which will look at features that are concerned more with traffic management, rather than network connectivity.) 

QoS Queues

Each conference that is created may have its bandwidth limited via QoS queue settings on the MikroTik. The required queues are created automatically via the M3 process when a conference is started.

Note that the Queue Tree queue-type is used on the MikroTik to enforce the rate limits per conference (not Simple Queues):

The example above shows a conference network called “ArdasTest2” that is configured to use a maximum of 10mbps of bandwidth. 

NOTE: If no queues are seen, check that a conference bandwidth limit has been set for the conference via the bandwidth slider in the Conference Builder Network section.

WAN Interface

The “WAN” interface on the Mikrotik is a physical Ethernet port that connects to an upstream device such as the venue firewall or WAN service connection that provides access to the Internet.

The chosen WAN interface has a static IP to which the NAT process is tied, hence allowing the conference networks to hit the NAT process and be translated to the static IP of the WAN interface on the gateway.

(Note that if a firewall exists upstream of the gateway then conference traffic may be double NAT’ed so that traffic arriving at Captivnet is sourced from a different address than the WAN interface of the Mikrotik WAN.)

Sample Scenario

The previous sections discuss quite a number of concepts that describe the network connectivity used for the Conference Tool. To demonstrate these various concepts, we’ll consider a simple example for a Conference tool setup and discuss how the networking elements will be configured. The logical network layout and connections are shown in the diagram above.

Here are the sample scenario details:

• Venue has two conference rooms (Room 1 & Room 2)

• Room 1 is quite large and can be partitioned to form 2 separate, smaller rooms when required for smaller events. These are designated as Room 1A and 1B when the partition is in place.

• Up to 3 discrete conference areas are therefore available, if required.

To provision conference networks for these spaces, we would provision the following network architecture (please refer to the diagram above for a visualization of the setup):

• Four access points to provide connectivity across the two conference rooms, with each room having 2 APs

• APs assigned to 3 AP groups that correspond to the 3 possible conference areas

• To support capacity of up to 3 concurrent conferences, 3 conference networks will be provisioned on the Mikrotik gateway

• A wired data port is available in conference room 1B for use by the conference organizer. This will also require a dedicated VLAN provisioned so that it may be joined to a conference network.

Wired Network Connectivity

To support the scenario described above, several VLANs will need to be created on the wired network to carry conference traffic from the wireless access points to the Mikrotik gateway. As there may be up to 3 concurrent conferences, 3 VLANs will be created on the wired network for conference use. 

There is also a management VLAN that will be present to allow management connectivity between APs and their wireless controller service. This is not created specifically for the Conference Tool, but is included to show how the required connectivity is achieved to allow conference SSIDs to be created on-the-fly as required.

As we have one wired port which may also be used for conferences, a VLAN will also be required for its switch port.

The conference VLANs that will be created are summarised below:

(Note that the naming convention employed will be useful when configuring the Mikrotik gateway, but is only a suggested convention.)

Each of these VLANs need to be trunked across to all APs so that the pool of VLANs is available for assignment when a conference is created. Conference Tool selects a random bridge (and hence VLAN) from the pool and then assigns the SSID created for the conference to that bridge’s VLAN. As the VLAN to be used for each conference cannot be known ahead of time, then all VLANs need to be available on the switch port (trunk) connected to the AP.

The conference VLAN needs to be trunked across the path end to end between all APs and the Mikrotik gateway. If an environment where VLAN pruning is employed on network switches, then this needs to be considered in the configuration of all switch port trunks to both APs and other network switches (e.g. edge to core uplinks).

As we also have a data outlet in conference area 1B, a VLAN is also required for its connectivity. The switch port for this outlet will be configured as an access port which is assigned to its own, dedicated VLAN (100 in this case).

Again, the VLAN needs to be trunked across the wired network to the Mikrotik gateway. This VLAN does not form part of the pool of conference VLANs, but is a dedicated wired port VLAN that can be grafted on to the conference bridge on the Mikrotik when the switch port is selected as part of the conference location setup in Conference Tool. 

Mikrotik Gateway Network Connectivity

With the required wired network VLANs in place, the Mikrotik Gateway is used to provide functions such as DHCP, routing and NAT to provide conference users with the Internet connectivity that they require. The logical network topology diagram above shows the main configuration elements required for conference connectivity. (Note: there are also configuration elements that provide features beyond basic network connectivity, such as peer-to-peer isolation and rate limiting. These will be discussed in a later advanced topics document.)

As can been seen in the diagram above, each of the VLANs provisioned on the wired network are presented to the Mikrotik gateway via a physical LAN Ethernet port. A VLAN interface is created on the gateway for each network VLAN and assigned to the LAN port. 

Each VLAN interface on the gateway is then assigned to a bridge interface - a bridge is created for each potential conference instance. In our example, we expect up to 3 conferences, so 3 conference bridges are created. Note that only the VLANs used for  wireless networks are statically assigned to each bridge. Any VLANs created for wired network ports (i.e. conference room wall ports) are not statically assigned to a bridge. If wall ports are required for a conference, they will be assigned dynamically to the relevant conference bridge when the conference starts. This dynamic allocation of data port VLANs to a conference bridge is initiated by API calls from Captivnet. It is worth re-iterating again that the mapping of wireless network VLANs to bridges is static and does not change when conferences are created or torn down - one of available conference bridges is chosen at random by Conference Tool and a wireless network assigned to its VLAN on the wireless controller.

To provide routing, a layer 3 interface (“Network”) is created for each conference network and assigned to the bridge. This provides the IP address for the default gateway of each conference network. A DHCP server is also created within the gateway and assigned to the layer 3 interface to provide IP addresses to conference attendees.  

Each of the networks is assigned to NAT on the firewall to place all conference attendees behind the public IP address of the site. The NAT process is tied to the existing network that has been created for the Ethernet interface that is designated as the WAN interface on the Mikrotik.

Wireless Controller Configuration

The configuration of the wireless controller is discussed in only general terms here, as the configuration methodology varies between wireless solutions.

For our sample configuration, the wireless controller will need to be provisioned with the following high-level groupings:

The purpose of this configuration is to ensure that the correct configuration is in place when a conference starts. As with the wired network VLANs, no changes are made to the AP or WLAN groups at the start time. However, an SSID will be created and assigned to an existing WLAN group to ensure that the conference network appears in the selected target area(s).

Conference Tool Lite Mode Considerations

The vast majority of the networking connectivity described in this document applies to the Conference Tool Advanced mode of operation.

In “lite” mode, no additional VLANs or SSIDs are required as an existing venue conference SSID and its networking path are used for connectivity. Similarly, the selection of zones and locations does not apply for targeted areas of wireless coverage, as an existing SSID is already in place and can only be used in the areas in which it has been provisioned.

One subtlety to note is that when a “lite” mode conference is created,  a conference bridge is still selected on the Mikrotik for use during the conference period. The purpose of this operation is to provide a bridge on to which a wired port may be attached if the conference requires a wired port connection. This will provide a wired port which has Internet connectivity for the duration of the conference. The wired port may be selected during conference scheduling in Conference Tool by selecting the port under the “Locations” port of the Conference Builder.