This topic describes how to define and customize organizations in SteelConnect. It includes these sections:

An organization is a company representing an end customer. It contains the customer details, sites, devices, zones associated with the devices, the uplinks, and so on.

You can assign administrative rights to individual administrator accounts per organization. You can also manage appliances and licensing per organization.

SCM uses these terms to describe your company:

SCM ships with a default organization. This section explains the default settings and how to create a new site within an organization.

After adding the company name, you’ll add basic information. You can always change and customize this information later.

You can change settings associated with an organization using the tabs on the Organization page.

The Organization page contains important global settings for internet breakout, NTP, numbering for VLANs, and default subnet IPs, social media integration, firmware upgrade schedules, and more.

This tab sets the name referenced on various SCM pages and the reports. This tab also displays the global organization ID generated by SCM that uniquely identifies the organization system wide. You can also define the location and the contact information for the entire organization.

This tab sets important global preferences for an organization.

This setting determines how you want internet traffic to flow for each site that you deploy throughout the organization. When sending traffic to the internet, the default is to send internet bound traffic directly out the local connection. You can also use RouteVPN or WANs as alternative breakouts. When including RouteVPN in your preference list, specify the default site that will handle the breakout. For details, see Local internet breakout or backhaul.

This setting is global and affects the entire organization if you don’t override the settings by sites and zones.

Moving the internet breakout location to a central location forces all internet traffic to that location regardless of the presence of a local internet breakout.

When internal zones in different sites can exchange traffic using more than one WAN path, this is where you select the preferred path. For example, if you have two paths to reach your corporate headquarters, you can select an MPLS as the preferred path.

For the WAN paths, overlays are preferred and traffic is sent on the underlay (if there is reachability on the underlay for a given destination) only when no overlay paths are available.

You can overwrite the WAN usage preferences at the site level or by defining a traffic rule path rule. For details on traffic rules, see Directing traffic using traffic rules.

The Fall back to all available uplinks is where you provide uplink failover to route internet-bound traffic using all other available uplinks when a configured WAN uplink becomes unavailable and an internet breakout preference or path is not explicitly configured. However, we recommend that you configure specific internet breakout preferences, backup uplinks, WAN preferences, and so on according to your needs instead of enabling the Traffic fall back setting.

Consider a branch site deployment with two WANs (internet and MPLS) and two uplinks (internet and MPLS). When you configure the branch to use the internet WAN for internet traffic and enable Traffic fall back, the branch will use the MPLS uplink to fall back to the MPLS WAN when the internet uplink is not available and no alternate path or uplink has been configured.

By default, this setting is disabled.

When this setting is disabled and no alternate path, internet breakout, or backup uplink is configured, traffic is dropped when the internet is unavailable.

For details on traffic balancing decisions between WANs, see Intelligent traffic steering and traffic flow distribution.

For details on configuring a backup uplink, see Creating uplinks.

For details on the fall through option in traffic rules, see To create a traffic rule.

You can specify the local Network Time Protocol (NTP) servers of your choice, one per line. We recommend that you configure your own internal NTP servers; however, you can leave the field blank to use these default Riverbed-provided NTP servers:

This tab connects two sites in an organization to a transit hub. A transit hub configuration eases the migration to a SteelConnect SD-WAN by providing a communication method between branch sites for these use cases:

Transit hub routing shows two internet-only SteelConnect branch sites and an underlay-only SteelConnect site that would typically not be able to connect to the existing legacy sites without a common hub to act as a transit node between the branch sites. After configuring the data center (Transit Site 2 in Transit hub routing) as a transit hub, traffic can move between the SteelConnect branch sites and the legacy site through the common hub. For the sites that are internet-only connected, all of the remote zone prefixes on their networks will automatically be advertised through BGP at the main data center. Sites that are still on traditional routers and haven’t been migrated to SteelConnect receive the remote zone advertisements from the data center (Transit Site 2 in Transit hub routing) .

Before configuring a transit hub, check these requirements:

SteelConnect supports these gateway models configured as transit hub appliances:

While the SDI-130, SDI-330, and SDI-1030 gateways support the traditional transit for internet-only branches use case as edge devices, these models aren’t supported as transit hub appliances.

A transit hub site is configured at the organization level.

The transit sites start reporting all underlay routes learned through WAN uplinks to the SD-WAN controller.

All SteelConnect sites report their local sites to the SD-WAN controller.

The SD-WAN controller computes all legacy subnets from the local subnets reported by all SteelConnect sites and the remote subnets reported by the transit sites.

The transit sites inject the internet-only branch subnets with a cost and then stamp the subnets with the BGP community tag. The cost and the community order are determined based on the transit site order:

The SD-WAN controller programs a list of overlay routes, giving priority to the legacy sites based on the transit site preference for all internet-only sites.

The transit site retracts the internet-only branch subnets if the tunnel is down between the transit site and the internet-only SteelConnect site. The next transit site in the list takes over as a transit hub.

Because SDI-5030 gateways are deployed out of path, the CE router needs to perform the AS path prepending according to the transit site priority. The SDI-5030 gateway’s BGP peer is the MPLS router. The BGP peer does the AS path prepending count that corresponds to the priority of the transit site before redistributing the route into the MPLS PE BGP peer.

The SDI-5030 gateway’s BGP peer and the MPLS CE router has iBGP between them. The SDI-5030 gateway’s BGP peer redistributes routes with the transit community into the iBGP using the community tag that corresponds to the transit site community.

The MPLS router redistributes into the MPLS PE BGP peer all routes matching the tag with the AS tag prepend count that corresponds to the site priority.

This section illustrates the CE router configuration for a deployment with these requirements:

Here is the CE router configuration, assuming the router is an AS 200:

You can monitor the internet-only SteelConnect site prefixes injected by the transit hubs in SCM.

This tab configures guest access using a social media app. For details, see Registering guest devices using social media without XMS-Cloud.

This tab enables or disables the Xirrus Management System - Cloud (XMS-Cloud), for wireless access points. XMS-Cloud provides zero-touch activation and automated software upgrades for newly deployed access points. Advanced management includes features such as reporting, upgrades, configuration management, network status, guest and employee or student access, and control of application use at the network edge.

Each SCM organization needs to be mapped to an XMS-Cloud domain before you can manage the access points through SCM for an organization. A domain is the XMS-Cloud equivalent of an SCM organization. A dialog is presented after you log in to XMS-Cloud that provides a way to associate an XMS-Cloud domain with an SCM organization.

For more details on domains, see the XMS-Cloud online help.

Before accessing XMS-Cloud, you’ll need XMS account credentials to log in.

To return to XMS-Cloud, click Wi-Fi Manager. In XMS-Cloud, you can view a guided tour to get started and view online help.

When SCM creates new zones, it uses the default zone numbering specified on the Numbering Pools tab for VLANs, IPv4, and IPv6 addressing. These are global pool settings used as the base identifiers throughout the organization. Optionally, you can manually configure the numbering for each zone. A simple method is to assign a 10.x.0.0/16 network such as 10.1.0.0/16, which every zone created will then pull an IP address from.

The default numbers are:

This tab controls the firmware upgrade process for an organization. A Riverbed appliance simply needs to be connected and registered, and the upgrade happens automatically when a new version of the firmware is available (unless you reschedule the upgrade or an upgrade schedule is customized for an organization within the realm). For details, see Upgrade overview.

This tab specifies how long SCM retains its traffic data history and unregistered device information for an organization. The maximum number of days is 366. The default setting for traffic history is 14 days and the default setting for unregistered devices is 7 days.

This tab configures an SCM appliance to send SNMP data directly to a network management system (NMS) and export syslog messages to an external syslog server. When you configure these settings at the organization level, you override the global realm settings. For details on enabling SNMP and configuring direct reporting or remote logging at the realm level, see Enabling SNMP reporting and logging. For a list of SNMP events, see SNMP traps.

When direct SNMP reporting is enabled, all gateways in an organization send SNMP data directly to your network management system. You can also enable direct SNMP reporting for all gateways in a realm.

SCM forwards the configuration to the SteelConnect gateways, and the gateways use this configuration to set up the SNMP agent daemon. The SNMP agent services the GET and WALK requests from the NMS and also generates traps and sends them to the NMS.

To enable SNMP operations (such as SNMP GET and WALK requests or asynchronous traps) from a SteelConnect appliance, you need to provide the NMS interface IP address through which the appliance is reachable.

For mid to large enterprises that require log exporting to a central server while keeping security, compliance, and audit requirements intact, SCM provides remote logging. With remote logging, all system logs from different appliances can be aggregated and stored in a single remote server located within the same enterprise network.

After all logs are aggregated on one server, using third-party monitoring tools such as Splunk can make log analysis and reporting simpler. This log aggregation is also useful for archiving logs. You can also forward real-time system messages from appliances to the remote server.

SCM pushes the configuration data to the SteelConnect appliances, and the appliances use this configuration to transport syslog messages to the remote syslog server.

SteelConnect gateways, switches, and access points are zero touch configuration and don’t require console access; however, if you need to access the appliance console for troubleshooting, the controller can create an SSH tunnel. You enable SSH access to an appliance on the SSH tab. You must add a public SSH key.

This tab adds a predefined legal disclaimer that appears each time a user logs in to SCM. For example, “This computer system is the private property of its owner, whether individual, corporate, or government. It is for authorized use only.”

This tab sets thresholds to measure appliance health. For each appliance type, you can set a threshold limit for CPU usage, number of connections, available memory, transmitted (TX) and received (RX) traffic by port, and the time, in minutes, used to calculate measurements. The default threshold measurement is five minutes.

As long as the thresholds are not exceeded, the appliance is considered healthy. Appliances periodically send resource utilization data and use the threshold settings to generate and report events in the Health Check page whenever a threshold is exceeded. For details, see Getting a summary of system health.

This tab sets a login password required on all appliances in an organization for root access. We strongly recommend that you use an appliance console login password. The password must be a minimum of six characters. Leave the login password field blank and click Submit to generate a random console appliance password.

This tab applies to all sites with a SteelHead SD appliance. SteelHead SD provides the ability to discover all subnets at the organization or site level. For details, see the SteelHead SD User Guide.