This topic describes ports and port settings in SteelConnect. It includes these sections:

A SteelConnect port on an appliance is an Ethernet interface used either for WAN or LAN. The number of physical interfaces supported for each branch gateway model are:

The SDI-130 and SDI-330 gateways have two physical interfaces that can be used as uplink interfaces. There are also eight switch ports on the 130 and 330 that cannot be used as uplink interfaces, but only as zone or multizone interfaces.

On the SDI-1030 gateway, four of the 12 ports are Small Form-factor Pluggable (SFP+) ports. The SFP+ ports do not support 1GbE via SFP. The ports operate only in 10GbE mode.

SDI-VGW virtual gateways require a minimum of two ports: one LAN and one WAN.  The default configuration ships with three ports, but you can add more by modifying the VM configuration outside of SCM. Adding more WAN ports increases your uplink options.

The number of virtual gateway ports supported depends on how many the hypervisor allows. For example, ESXi 5.5 supports ten ports for the SDI-VGW virtual gateway.

The virtual gateway ports are labeled as LAN on the Ports page.

You can use the Ports page to:

For details on a SteelHead SD primary port configuration, see Overview of the SteelHead SD in the SteelHead SD User Guide.

For details on a configuring a management port on an SDI-5030 data center gateway, see Configuring ports.

The port mode determines how the port functions. The port can use singlezone or multizone mode.

You can also set the port mode to uplink for individual uplinks or mirrored uplink for branch gateway high-availability configurations.

These limitations apply to specific gateways and appliances:

On the Info/Mode tab for a USB port, the connection status displays whether the LTE modem is connected to the gateway. When the connection status reports that the modem is connected to the appliance, but the link status is down, it means that something went wrong when the modem tried to connect to the cellular network. For details, you can view the event log for the modem states during the connection process.

Selecting singlezone is the equivalent of setting the port as an Access port where the VLAN traffic or traffic is untagged. The port will drop the traffic should it ingress as tagged (or with a VLAN tag).

A multizone port is synonymous with a trunk port. A multizone port can carry traffic from multiple zones (VLANs); it expects to receive tagged traffic. The switching fabric will then strip the tag and forward that traffic to any other ports that are appropriate to that tag.

By default, a port is automatically configured for multizone when it’s connected to another SteelConnect appliance. For example, as soon as you connect a SteelConnect access point to a SteelConnect switch, they negotiate a trunk. The access point will have a trunk port configured with all zones configured for that site.

For each multizone port (trunk) a native VLAN can be configured to allow untagged frames to travel over a trunk along with other tagged frames. For details, see Native VLAN support.

This section describes how to configure native VLAN support for a Xirrus access point or other supported network device that requires native VLAN functionality. Native VLAN allows an appliance to accept both untagged and tagged traffic over a multizone port connection. By default, a multizone port expects to receive tagged traffic.

By default, without configuring native VLAN, a port configured for multizone drops any untagged traffic.

Figure: Xirrus access point and SDI gateway integration shows a deployment where clients on the access point are placed in the same VLAN with clients on the switch or the gateway. This deployment demonstrates how to configure a guest Wi-Fi network and an internal corporate network for full access, using VLAN 1001 for guests and VLAN 1002 for full access.

Typically when there is a wired connection for guests, they plug into the switch or gateway on ports with VLAN 1001, and employees plug into VLAN 1002 for full access. However, when employees need to access the internal network from a conference room using Wi-Fi, they must use VLAN 1002. To configure this, you create an internal Riverbed SSID (Wi-Fi) for VLAN 1002. Next, to grant guests access to the wireless network in VLAN 1001, you create another SSID for Riverbed guests.

Xirrus access points can accommodate this separation based on VLAN tag, but they require their management traffic to arrive untagged in order to connect to the internet. This means the tagged frames with VLAN 1001 and VLAN 1002 travel on the trunk connection between the access point and switch, but the VLAN 1003 management traffic needs to travel untagged. To achieve this, you need to set native VLAN 1003 for a multizone port.

To configure the Xirrus access point to receive both tagged traffic and untagged management traffic, you place the management traffic onto the native VLAN using a multizone port connection (configured on the switch in the deployment shown in Xirrus access point and SDI gateway integration). The native VLAN supports both the tagged SSID-associated client traffic and the untagged management traffic.

The port still works as a multizone port in that it sends and receives tagged traffic; however, if it receives untagged traffic, it will accept it and then tag it with the VLAN ID associated with the zone. The port sends a packet down to the access point or the switch that has the source VLAN ID associated with the zone.

The native VLAN settings allow an access point or other device to successfully decode the untagged frames in the management zone, obtain an IP address, and connect to the internet.

After completing these SCM configuration steps, when you log in to your XMS-Cloud account (also known as your tenant), the account will be in a read-only state to prevent edits outside of SCM.

To better protect a network from unauthorized systems and users, you can enforce access control on the gateways by enabling port-based authentication. Port-based network access control, or Layer 2 access control, protects the network from rogue and potentially malicious users by preventing access to network resources until a client is authorized using 802.1x.

SDI-130 and SDI-330 gateways can use 802.1x authentication between a client, known as a supplicant, and a RADIUS server using an Extensible Authentication Protocol (EAP) method. The RADIUS server is responsible for authenticating users. The gateway acts as an authenticator between the supplicant and the RADIUS server. The supplicant is a device that wants to connect to the network. Until the supplicant’s identity has been validated and authorized by the RADIUS server, the gateway prevents access to the network.

The gateway performs EAP over LAN (EAPoL) exchanges with the supplicant and converts these exchanges to RADIUS access-request messages. The access-request messages are sent to the RADIUS server’s IP address without changing anything. The RADIUS server verifies the supplicant’s credentials and transmits a response back to the gateway acting as the authenticator. After the gateway receives a RADIUS access-accept message from the RADIUS server, it allows the supplicant access to the network.

The gateway must be able to reach the RADIUS authentication server using one of these methods: