Feature Overview: L2GRE/EoGRE Tunnel Concentrator on cnMaestro

This feature is no longer available in cnMaestro.

While deploying access points, ability to tunnel the wireless traffic from access points to a tunnel concentrator often plays a key role. Whether the objective is to avoid reconfiguration of switches and routers (for VLANs) or is to carry wireless clients traffic across network where the clients IP range is not routable, the tunnel feature use is inevitable.

Cambium Networks, access points already provides L2GRE tunnel feature support from release 3.1.1r16. Check out this post to read about L2GRE support on access points. Now, in the 1.3.2 release of cnMaestro NOC, it can accept tunnelled traffic from access points. With end to end tunnel solution from Cambium Networks, it is easy to get up the network fast and in reliable way.

Typical Deployment Model (Two Port Solution):

In this deployment model, cnMaestro is equipped with two ports. Primary Ethernet port (eth0) is configured with cnMaestro IP address and all the communication between APs & cnMaestro happens on this port. On the second port, also called aux/bridge port (eth1), all the wireless clients traffic received from APs will be transferred after removing tunnel headers. This port comes up as trunk port with allowed VLANs and other relevant parameters configurable from the cnMaestro Web UI. This model is recommended as it will give better results for throughput than the “Single Port Solution” discussed below.

Multicast / Broadcast Handling with Multiple APs on Tunnel Concentrator

In any deployment, multiple access points will create tunnel with the concentrator. In such scenario, there will be multicast/broadcast traffic (such as DHCP discovers, ARP Requests) generated by the wireless clients which needs to be forwarded to aux/bridged port of the concentrator as well as to all the access points connected to the concentrator. Similarly, when any multicast/broadcast traffic is received on the aux/bridged port of the concentrator it needs to be sent to all the connected access points. In many situations, this broadcast can impact the performance and is better to restrict such traffic to flow out to all the access points.

Tunnel Concentrator is equipped with ACL feature which allows to restrict such traffic. There are many different ways by which ACL can drop the traffic. Each restriction is defined by an ACL rule. Refer to ACL Configuration section for detailed information.

Note: Default rules in the ACL prevent unnecessary broadcast & multicast to go out towards access points. 

Inter AP Wireless Client Communication (through Concentrator)

Different wireless clients on different access points can be configured to use same or different VLANs. When clients on different access points but on same VLAN try to communicate with each other, then concentrator will bridge the traffic received from one access point to other(s) access point(s) (if not restricted  by ACL rules). However, when clients on different access points are using different VLANs (different subnets) then concentrator does not forward traffic from one access point to another access point.

 

L2GRE/EoGRE Tunnel Concentrator Configuration

Tunnel Configuration is available under “Services”->”Data Tunnel”. Below is the snap shot of the configuration UI.

Configurable items are:

  • Tunnel Status: Represents whether tunnel is enabled or not.
  • Bridged Port: Configures aux/bridged port. Using this configuration, tunnel concentrator is configured either for two port solution or single port solution.
  • Allowed VLANs: Represents list of VLANs allowed through the tunnel. This list is used for allowed VLANs on aux/bridge port and also serve as a filtering list for inter AP packet forwarding.

Logs & Statistics

  • Collecting Logs: Logs are useful for debugging purpose. All related tunnel specific logs can be found in “/var/log/aurora/tunnel.log”
  • Statistics: Tunnel statistics are available under “Services”->”Data Tunnel”->”Statistics”. Below is the snap shot of the Statistics tab.

Access Control List (ACL) Configuration

Access Control list provides mechanism to filter out the unwanted traffic passing through the tunnel as well as traffic going between the access points. ACL provides many options to deny or permit the traffic. Traffic can be denied / permitted based on MAC layer, IP layer, Protocol layer along with direction of flow. ACL is configured with the help of rules, each of them comes with a precedence. In these rules, IN direction refers to traffic coming from access points to the concentrator and OUT direction refers to the opposite.

ACL comes up with default rules that prevent unnecessary broadcast & multicast to go out towards access points. With these rules, Inter AP communication is blocked.

Here are the screenshots for the different ACL rule categories:

MAC Layer ACL:

IP Layer ACL:

Transport Layer ACL:

8 Likes

Dear all,

I’m not finding this feature in cnMaestro 4.1 (On Premise). I’ve looked into the documentation and found no mention as well. The Edge Controller does not seems to provide such funcionality.

Was it removed?

Hi Rodrigo,
The support for L2GRE/EoGRE is removed from cnMaestro on-premise version.

Regards
Anand

Dear Anandakrishnan, thanks for the information.

That is unfortunate - we were interested in replacing our Cisco infrastructure with Cambium, but no tunnel support for on-premise is a hard-no for us.

Kind regards,