SoftGRE Tunnels

Ruckus SmartZone Configuration (12/11/2023)

Overview

The following steps will guide you through configuring a SoftGRE tunnel between a Rucks AP and a rXg.

Environment

This document was written and tested using the following components from the RG Nets and RUCKUS ecosystem.

Important Notes:

1. SoftGRE tunnels are a licensed feature with RUCKUS. A demo license or SoftGRE license is required for this application.
2. It is recommended to only use SoftGRE tunnels over the LAN as the traffic is currently unencrypted.

Prerequisites

This document assumes the following has already been configured: 1. IP Address for the SmartZone, AP, and rXg are all in the same subnet. 2. The subnet has been tied to an IP group and policy called Management. 3. The AP has already been discovered by the SmartZone 4. While not required, in the case of this lab, a functional eDPSK configuration has already been deployed and tested using config sync.

Configuration

SmartZone

All required configuration changes to the SmartZone will be applied using config sync from the rXg.

rXg WLAN Configuration

Network >> Wireless >> WLANs

The modifications in the WLAN profile are quite simple. On an existing WLAN, you can check the box for tunnel, set the tunnel type to SoftGRE, and then add the IP address for the interface on the rXg that will be the endpoint for the tunnel.

1. The Tunnel checkbox instructs access points to build a tunnel to the controller instead of locally bridging the client traffic. In the case of Ruckus, this checkbox will create a SoftGRE tunnel between the APs and the rXg. This capability does require that the Ruckus controller has an appropriate SoftGRE license.
2. The GRE Tunnel Type field allows you to select between RuckusGRE and SoftGRE. RuckusGRE is for use with the Ruckus virtual data plane. SoftGRE allows for tunnel creation to the rXg as the endpoint.
3. The GRE Tunnel GW IP should be the IP address of the interface on the rXg that the tunnel will connect to.

rXg Pseudo Interfaces

Network >> LAN >> Pseudo Interfaces

1. Name for the SoftGRE tunnel interface.
2. Select an interface type of SoftGRE.
3. Select the interface to be used for untagged traffic.
4. Select the VLANs that will be allowed over the SoftGRE tunnel.
5. Select the policy that contains the APs that will establish a tunnel.

Troubleshooting

Confirm the presence of interface bridges.

In the GUI this can be confirmed by browsing to Instruments >> System Info >> Interface Configurations and checking that there is a bridge for each VLAN that should be carried over the tunnel. The bridge number will be the same as the VLAN with an extra 1 at the beginning. For example if vlan2000 should be carried over the tunnel, you should also have a bridge12000.

This can also be seen via SSH with a command like ifconfig | grep bridge12000

Confirm the traffic is flowing over the bridge interface.

This can be done by using tcpdump to confirm that you see unicast traffic over the interface. For example, have a client connect and ping 4.2.2.2.

Continuing the use of bridge12000, I will use the following tcpdump statement tcpdump -ni bridge12000 and confirm that I can see unicast traffic from my client device.

SoftGRE Client Configuration on Linux Host

This section presents an example of softGRE client configuration on a generic Debian-based host. Ubuntu 22.04.5 variant was used to test these commands in detail.

All commands are executed as root or in sudo mode. Install vlan package and modprobe 8021q on the host:

apt install vlan
modprobe 8021q

The local host is assumed to be connected to the WAP via wireless interface and have an address assigned either via DHCP or static allocation. As an example, the local Linux host has the IP address of 10.0.47.3 (client) and the target server has the address of 10.0.48.2 (server) to demonstrate network traversal capability. VLAN 602 is used as an overlay in the softGRE tunnel, i.e., all customer traffic is tagged with VLAN 602 and then transported over the softGRE tunnel. To avoid routing problems, a static route is added for server address (10.0.48.2) as reachable via the underlay gateway (10.0.47.1).

A shell script can be prepared to simplify the provisioning process. The local address MUST correspond to the IP address of the underlay interface, otherwise the communication will not be properly established with the remote softGRE gateway (rXg system).

#!/usr/bin/bash
ip link add name gre1 type gretap local 10.0.47.3 remote 10.0.48.2 ttl 255
ip link add link gre1 name gre1.602 type vlan id 602
ip link set gre1 up
ip link set gre1.602 up

ip addr add 10.60.2.2/24 dev gre1.602

route add -net 10.0.48.2/32 gw 10.0.47.1 netmask 255.255.255.255

Before the softGRE tunnel is established, the interfaces on the server host look as follows:

and the routing table is as follows

Once the script is executed, the interfaces change as follows

and the routing table changes as follows

If the target VLAN (in this case, vlan602) is configured with a DHCP pool, the new gre1.602 interface can acquire address dynamically, using the following command

dhcpclient -v -i gre1.602

Additional Troubleshooting

Confirm the presence of interface bridges

The bridge number will be the same as the VLAN with an extra 1 at the beginning. For example if vlan2000 should be carried over the tunnel, you should also have a bridge12000. In our example, there will also be an additional 0 because the VLAN ID is only 3 digits. VLAN 777 becomes bridge10777.

This can be confirmed via SSH with the following command: ifconfig | grep bridge10777

Confirm the traffic is flowing over the bridge interface

This can be done by using tcpdump to confirm that you see unicast traffic over the interface. For example, have a client connect and ping 4.2.2.2.

Continuing the use of bridge10777, I will use the following tcpdump statement tcpdump -ni bridge10777 and confirm that I can see unicast traffic from my client device.