Welcome to SteelConnect 2.12.1

The following is an overview of the changes in this release.

New features in 2.12.0

SaaS Accelerator

SteelHeads and SteelHead Mobile clients can accelerate SaaS traffic by working with SteelConnect. Using SCM, you can configure SaaS applications for acceleration, and then register SteelHeads or Mobile Controllers with SCM to accelerate their SaaS traffic. SCM 2.12 supports acceleration of these applications: Box, Microsoft Office 365 (including Exchange, SharePoint, Office WebApps, and Authentication and Identify Services), Salesforce, ServiceNow, and Veeva.

Multisite Administrator RBAC

Multisite administrator role-based access control (RBAC) enables you to create multiple administrator roles to manage a subset of sites within the organization. Site tags comprised of one or more sites are created and associated with an administrator role. A common use case for this feature enables enterprises to create administrators that are responsible for sites in a certain geographic region. Administrators manage sites and all SteelConnect constructs (that is, appliances, uplinks, zones, routes, rules, and features) for the sites within the scope of the site tags defined by region and associated with that administrator role.

System Log Improvements

Improvements include new log messages, log messages that are intuitive and understandable, and a central location for logs. In addition, the logs now list interface names, IP addresses, and time stamps. A subset of the system logs can be exported to the remote system log server to conserve space.

Improved DHCP Options on SteelHead SD Appliances

The zone DHCP tab enables you to configure LAN clients with DNS servers located on internet (outside of the intranet) on guest zones. The zone DHCP tab also allows you to configure LAN clients with Preboot Execution Environment (PXE) boot using the Trivial File Transfer Protocol (TFTP), a Session Initiation Protocol (SIP) server, or an HTTP proxy. Zone DHCP options are supported on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances, and the SteelConnect SDI-2030 gateways located at the branch.

Zscaler and Cloudi-Fi Enhancements

SteelConnect 2.12 includes these Zscaler and Cloudi-Fi enhancements:

• REST API integration that provides quicker Zscaler integration from SCM using the Zscaler partner APIs. Zscaler REST API integration delivers the ability to import ZEN nodes within SCM (Zscaler only).
• Faster ZEN outage detection and quicker failover to backup ZEN nodes using enhanced monitoring of Zscaler or Cloudi-Fi tunnels. If the primary IPsec VPN tunnel or an intermediate connection goes down, all traffic is rerouted through the backup IPsec tunnel to a secondary ZEN in approximately 15 to 60 seconds, depending on the configuration and cause of failure.
• Internet Key Exchange (IKE) v2 support for enhanced security over all overlay tunnels including tunnels to Zscaler ZEN nodes.

Routing Features on SDI Gateways

These routing features are included in 2.12:

• You can now configure static routing on SDI gateways in addition to SteelHead SD appliances. Static routes support IPv4 destination networks. You can also configure the distance metric, which prioritizes the routing protocol when two routes have the same route destination.
• On SDI gateways, you can now use a default route for configurations that have OSPF enabled on the LAN, even when eBGP isn't enabled on the WAN.

LAN-side Internet Breakout on SteelHead SD Appliances

The LAN-side internet breakout capability enables redirection of backhauled internet traffic to break out from the LAN-side of the gateway. Previous releases only allowed internet breakout over the WAN uplinks. LAN-side internet breakout is supported on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances, and the SteelConnect SDI-2030 gateways located at the branch.

Firmware Upgrade Window Extension

The SCM firmware upgrade window has been extended to 60 days.

Underlay and routing enhancements on SteelHead SD appliances

SteelConnect 2.12 provides these underlay and routing enhancements on SteelHead SD 570-SD, 770-SD, and 3070-SD appliances, and the SDI-2030 gateway located at the branch):

• OSPF routing - With SteelConnect 2.12, you can distinguish between static and overlay routes for OSPF. This distinction enables you to configure redistribution policies separately for each type of route. For overlay OSPF routes, you can associate a site with the route redistribution policy which enables you to redistribute it based on the sites from which they were reported.
• Loop prevention in subnet autodiscovery - You can enable discovery of subnets based on the tag/community lists present in the route to prevent loops. All routes matching the tag/community lists are reported as local subnets of the configured site. Tag and community lists can be configured in inclusion or exclusion lists.
• Soft reset for BGP parameters - Soft refresh enables route updates without tearing down existing peering sessions. A soft reset uses stored update information to allow you to apply new BGP policy without disrupting the network.
• User-defined route maps for increased flexibility - Support for user-defined route maps enables you to create route maps that include all available match and set criteria options.
• Increased BGP route preference support - You can now set BGP local preference, Multi-Exit Discriminator (MED) options, the origin type in route maps, metric distance, and next-hop self.
• Differentiation between static and overlay BGP routes - You can differentiate between static and overlay routes when you configure the Overlay to BGP option. The policies applied on redistribution of other routes are also applicable on overlay routes.
• Routing table search - Ability to search the routing tables for an appliance by serial number or for appliances by site name.

Unified Tunnel Reports

Improved tunnel details and status in SCM with better clarity. Support for extensions to tunnel visibility and overlay tunnel status. Tunnel reports have been unified:

• Dashboard (duplex tunnel map view)
• Health Check > Overlay Routes (by Site)
• Health Check > Tunnel Health (by Tunnel)
• Health Check > Proxy Tunnels (by Tunnel)

SteelConnect Scale Enhancements

Support for SteelConnect scale enhancements in terms of the number of sites, tunnels, zones, rules and routes has been added to SteelConnect 2.12. For detailed scale design guidance, work with your Riverbed sales team.

Troubleshooting Through a New CLI Framework

Local troubleshooting access through a new CLI framework, including:

• "show" commands to aid in debugging issues and provide appliance information, including "show connections", "show tunnels", and "show flows".
• a "show path" command that displays the potential paths for a given destination prefix. It also shows the current connections on the appliance using the paths. The show path tool is also available in SCM.
• a "configuration network" command for static IP network uplinks for situations when DHCP is not an option. (The appliance must be offline from SCM. This command is only supported when connected via telnet.)
• a "configuration core" command for the core hostname when the appliance is offline from SCM.
• a "troubleshoot" command that provides for enhanced day zero troubleshooting that includes all interfaces reachable through the SCM. This command provides connectivity information about the core or SCM on all physical ports on the appliance. You can export the output as log files via a USB drive, create log files with a specific name, and list all log files.
• support for system dumps. By default, when you request a system dump, it is uploaded to riverbed.support.com. You can also specify an external server for uploads in SCM under the Organization > System Dump tab.
• support for the tcpdump utility.

Active-active HA Improvements on SteelHead SD Appliances

SteelConnect 2.12 provides these high-availability (HA) enhancements:

• You can configure a LAN link as a backup HA link in case the AUX port is disconnected. If the AUX link goes down, you can use LAN-side connectivity to run the HA heartbeat, configure replication, and perform additional synchronization functions to avoid a split-brain HA condition.
• There is a new configuration option to specify the SteelHead SD appliance as the master appliance.
• Support is now available for SteelHead SD mixed-mode HA, where one SteelHead SD appliance is licensed as SD-WAN-only and the peer SteelHead SD appliance is licensed for SD-WAN and WAN optimization.

Shared Services Hubs

The services multihub feature has been enhanced to support up to three shared services hubs. A shared services hub can be a regional data center or an AWS/Azure cloud site that hosts services and applications. Leaf sites connect to a services hub using point-to-point AutoVPN tunnels enabling users at these leaf sites to access services hosted at the services hub locations. Shared services hubs support bidirectional connectivity between services hubs and leaf sites. Unlike regular hubs, shared services hubs do not support transit functions or leaf-to-leaf connectivity.

Cold Standby Uplink Support

In SteelConnect 2.12, you can enable an uplink to act as a backup uplink that assumes the active role if no other uplinks are available. The local and remote backup uplink tunnels are not probed unless their corresponding active uplinks are down. The local and remote backup uplinks for overlay or underlay data traffic are not used unless their corresponding active uplinks are down. The cold standby uplink is supported on SDI-130, SDI-330, SDI-1030, and SDI-2030 gateways; the SDI-VGW virtual gateway; and the SteelHead SD 570-SD, 770-SD, and 3070-SD appliances. (The SDI-5030 data center uplinks are always active by design.)

Local IPFIX NetFlow Export

With SteelConnect 2.12, IP Flow Information Export (IPFIX) NetFlow records can be directly exported to NetProfiler or any third-party flow collectors. IPFIX NetFlow exports use standard UDP protocol format. NetFlow exports are supported on both LAN and WAN interfaces and reports both overlay and underlay traffic on the interface. In addition, you can configure NetFlow exports and SNMP integration on a collector for advanced visibility.

Smaller Additions, Improvements, and Bugfixes

2.12.1

• SCON-20246 - Symptom: The Health Check status for an appliance does not report the static assigned DNS server either at the site level or the static uplinks default dns servers.
  Condition: This issue occurs when the uplinks connected to the appliance are configured with static IP addresses. Or when there is a static server set for a site.
• SCON-17959 - Symptom: Hyperlinks to rules in an event log message go to the Edit rule page even after the rule has been deleted.
  Condition: An error occurs when trying to edit and save a deleted rule that still appears in the event log.
• SCON-28101 - Symptom: DHCP relay traffic is blackholed at the SteelHead SD appliance.
  Condition: This issue occurs when DHCP relay traffic is deployed in a branch behind an HA-enabled SteelHead SD appliance. On the SteelHead SD, VRRP is configured to support virtual IP for the LAN.
• SCON-34960 - Symptom: Inbound NAT is not working on SteelHead SD 2.0 appliances after upgrading to 2.11.4.
  Condition: This issue occurs when NAT is configured with a custom WAN IP.
  
• SCON-34462 - Symptom: Firewall or traffic rules are not applied in the SDI gateway.
  Condition: This issue occurs after an SDI gateway reboot or HA failover.
• SCON-34336 - Symptom: Firewall reject notifications are not being sent via remote syslog for SDI-130, SDI-330, SDI-1030, and SDI-vGW gateways.
  Condition: This issue occurs when remote syslog is enabled and there is at least one active "Deny" firewall rule.
• SCON-33613 - Symptom: On SteelHead SD 2.0 appliances and the SteelConnect SD-2030 gateway, the public IP detector cannot resolve the reflector IP address.
  Condition: This issue occurs when there is at least one DHCP uplink on the appliance and a DNS server is not configured at the site level.
• SCON-33574 - Symptom: IP packets containing a GREv1 payload (such as PPTP) are dropped when traversing an SDI-1030 gateway.
  Condition: All packets containing GREv1 payload are dropped.
• SCON-33408 - Symptom: The custom application is not classified correctly for a TCP connection with SteelHead probes.
  Condition: This issue occurs on a SteelConnect gateway with SteelHead compatibility enabled. The custom application classification is incorrect on a TCP connection with SteelHead proprietary probes in a SYN packet.
• SCON-33398 - Symptom: The hostname-based custom IP:port application is not matched on the first packet of the flow.
  Condition: Although the appliance sees the DNS request/response packets and has the IP to hostname mapping, when it receives the first packet of the flow, the flow is not matched to the hostname-based custom application.
• SCON-33372 - Symptom: Kernel crashes and reboots occur when the 5-GHz Wi-Fi spectrum is enabled on an SDI-130W gateway. Sometimes these kernel reboots generate crash dumps that are sent to SCM on the next power-up.
  Condition: This issue occurs when the SDI-130W gateway is located in a country that doesn't allow channel aggregation in the 5-GHz spectrum, including Bahrain, Costa Rica, Ecuador, El Salvador, Guam, Indonesia, North Korea, and Sri Lanka.
• SCON-33357 - Symptom: Application classification works inconsistently for a hostname-based custom application.
  Condition: This issue occurs when a custom IP:port application is defined using hostnames and the custom application is configured with multiple hostnames, any individual hostname resolves to multiple IP addresses, or the IP address of a configured hostname changes.
• SCON-33316 - Symptom: Traffic is blocked even though an outbound rule is allowing the device group.
  Condition: This issue occurs when an allow outbound rule is configured using a device group-based custom application.
• SCON-33149 - Symptom: Traffic is not distributed evenly across tunnels.
  Condition: Traffic is distributed across tunnels using a hashing algorithm based on the source and destination address of each connection. Due to the logic of the traffic distribution algorithm, certain patterns of source and destination address may direct many connections to the same tunnel.
• SCON-32915 - Symptom: Some Azure hosting sites are not represented correctly on the dashboard map.
  Condition: As new Azure locations are deployed for customer use, when the corresponding regional location is missing, the site appears in the ocean on the dashboard map.
• SCON-33773 - Symptom: System logs from an SDI-S48 switch include a "file not found" error message generated during the firmware upgrade process.
  Condition: The logged error does not impact the success of the upgrade, but it does prevent the upgrade process from logging the state of the firmware partitions at the end of the upgrade.
• SCON-33740 - Symptom: Under Health Check > Tunnel Health, destination networks do not appear after selecting a tunnel.
  Condition: The destination networks reporting has been intentionally disabled in 2.12.1.
• SCON-32719 - Symptom: SCM shows an alert about "No Zscaler tunnel: [site] does not have an uplink with internet breakout enabled."
  Condition: This alert occurs when a public IP address is not yet associated with the uplink. After the public IP address is associated with the uplink, the alert does not disappear, leading to a false notion that the Zscaler tunnels are not established.

2.12.0

• SCON-26904 - Symptom: Certain Azure sites do not have location data in SCM (Site > Location and Dashboard).
• SCON-26493 - Symptom: The TFTP boot, SIP server, and HTTP proxy DHCP options are missing.
  Condition: These options are missing from the Network Design > Zones > DHCP tab.
• SCON-26958 - Symptom: A custom rule matches when it shouldn't.
  Condition: This issue occur when there are multiple lines in an IP/ports rule, and one of them contains .0.0.0.0/32.
  
• SCON-26543 - Symptom: The DNS server doesn't change for a guest zone. Guests can incorrectly end up using internal DNS servers.
  Condition: This issue occurs when site-level DNS settings are changed to point to an internal (private) DNS server.
• SCON-26711 - Symptom: Discovered networks are not available when registering devices.
  Condition: Cannot register a device on a discovered network.
  
• SCON-26789 - Symptom: When attempting to override overlapping subnets while connecting a cloud subnet, you get a 400 response.
  Condition: This issue occurs when there is an existing subnet overlapping with the one you want to connect.
  
• SCON-26985 - Symptom: All AD users are not synced with SteelConnect Manager.
  Condition: This issue occurs when the number of AD users is more than the maximum configured AD users allowed for SteelConnect Manager.
• SCON-26565 - Symptom: After creating a traffic path rule, the rule doesn't appear in the rule list in SteelConnect Manager. Without being able to see the rule in the rule list, it cannot be enabled.
• SCON-19924 - Symptom: Outbound traffic is not getting blocked by a DENY ALL outbound rule.
  Condition: This issue affects outbound packets carrying unknown/proprietary IP protocol numbers.
• SCON-19876 - Symptom: The Health Check > Routing Tables page did not update automatically to display new data. This issue has now been fixed and the page will automatically refresh.
• SCON-20241 - Symptom: In rare situations, the output of the "show flows" command (or flows-ctl configure "show flows") may not accurately reflect the configuration of the data plane. This can result in the appliance forwarding frames or packets in ways that users do not expect.
  Condition: This issue can occur when the flows tables are full, in which case messages such as "flow_matches_add: cannot add another entry (nentries/max: 0x1fff/0x2000))" will appear in the journalctl (1) logs on the hypervisor.
• SCON-18354 - Symptom: SaaS acceleration delay occurs.
  Condition: This issue occurs when authorization (whitelisting) of a client-side SteelHead to send traffic to a SaaS Accelerator Service Cluster is reenabled after having previously been explicitly removed (blacklisted). This delay should not impact regular operations because client-side SteelHeads are typically not authorized for short periods of time. However, if a client-side SteelHead was inadvertently deauthorized and that error was quickly reversed, it could take up to one hour to see accelerated SaaS traffic and confirm the corrective action.
• SCON-18474 - Symptom: In Release 2.10.1, backup uplinks will be probed for aliveness.
  Condition: This helps in achieving faster failover times when the active uplink to the WAN goes down.
  
• SCON-17925 - Symptom: A user is able to create a split site group using two different models when split site group appliances must match. The first and second sites must deploy the same hardware to provide equal sizing capacity.
  Condition: This issue occurs when the site edge appliances in a split site group are not the same models. The site list only includes sites that have matching appliance models for the edge node.
• SCON-31001 - Symptom: The SDI HA master does not upgrade firmware when the SDI HA backup is offline.
  Condition: This issue occurs when trying to upgrade SCM while having an SDI HA setup with the SDI HA backup offline.
• SCON-30165 - Symptom: The On-Premise SCM upgrade to 2.11.1 indicates completion, but SCM is not available, and the Start, Stop, and Restart buttons are all dimmed.
  Condition: This issue may occur when upgrading On-Premise SCM to 2.11.1.
• SCON-30040 - Python 2.7 was upgraded to remediate security vulnerabilities.
• SCON-30041 - Python 3.6 was upgraded to remediate security vulnerabilities.
• SCON-29805 - Symptom: On disconnecting one of the WAN uplinks in an HA SDI-2030 configuration with two internet uplinks to the same internet carrier, the data plane incorrectly continues to use the uplink that was disconnected.
  Condition: This issue occurs when the two uplinks within the same WAN are connected to the same switch and then to the PE router. In this scenario, when one uplink is brought down, the switch sends the packets destined to the down uplink to the uplink that is still up. This behavior occurs because once the switch port goes down, the switch starts broadcasting the packets. This patch makes sure we only accept packets on an uplink for which it is meant.
• SCON-30033 - Perl was upgraded to remediate security vulnerabilities.
  
• SCON-30035 - TIFF was upgraded to remediate security vulnerabilities.
• SCON-30029 - cURL was upgraded to remediate security vulnerabilities.
  
• SCON-30030 - systemd was upgraded to remediate security vulnerabilities.
• SCON-29404 - Previous releases had a custom format of the syslog message, resembling but not quite conforming to RFC 3164. Starting with release 2.12, syslog messages adhere to the RFC 5424 syslog protocol, which obsoletes RFC 3164. Note that backward compatibility between these two protocols is not maintained.
• SCON-29086 - Symptom: Unable to take a packet capture on a gateway with a mirrored uplink.
  Condition: When the HA Master is configured with a mirrored uplink, no ports will show up when trying to take a packet capture.
• SCON-28965 - Symptom: SNMP responds to polling of all interfaces prior to being configured by SteelConnect Manager.
  Condition: To replicate this behavior, bring up any SDI gateway. Don't provide any SNMP configurations or don't switch SNMP on or off from SCM. Go to the gateway, and check for the SNMP agent.
• SCON-29305 - Symptom: The count of tunnels reported on different pages of the SCM UI were sometimes not consistent.
  Condition: This issue occurred when SCM used different sources for the tunnel count. This has been fixed by ensuring the UI always uses a single source.
• SCON-27706 - Symptom: On the Health Check > Overlay Routes page, the Reachability Status is marked red when only one tunnel is down.
  Condition: The threshold for a single tunnel down was incorrectly displaying the status as red. The fix is to mark the status as yellow instead. Now if a destination network is reachable over multiple tunnels and all tunnels are up, the network is marked green. If one or more tunnels are down and at least one tunnel is up, the network is marked yellow. If all tunnels to the network are down, then the network is marked red and is considered unreachable.
• SCON-27657 - Symptom: SCM shows this unexpected warning: "Site does not have an uplink with internet breakout enabled. As a result, no Zscaler tunnels are being established."
  Condition: Zscaler is enabled. The site only has an uplink to an internet breakout enabled WAN, but not to the internet WAN. The site's internet breakout preference is Zscaler only.
• SCON-27385 - Symptom: Read-only users are able to reload appliances.
  Condition: Read-only users shouldn't be allowed to reload appliances.
• SCON-27352 - Symptom: The FIB table in SCM for sites with SDI-2030 gateways is not displaying any routes. Other SteelConnect gateway models are displaying okay.
  Condition: This issue is caused by an unreliable SCM UI.
• SCON-27335 - Symptom: show_overlay_route is broken with traceback.
  Traceback (most recent call last):
  File "/usr/local/bin/show_overlay_route", line 184, in
  subnet_dict['local_uplink'])]['name']
  KeyError: 4
  Condition: This issue occurs when executing show_overlay_route.
• SCON-28913 - Symptom: Added or deleted HA tracked ports will not take effect on the appliance until the next network change is made for the appliance.
  Condition: Tracked ports are added or deleted, and the network configuration is written. The tracked ports are updated, but the modifications are not seen in the network configuration file.
• SCON-28046 - Symptom: Data is missing from the Traffic Timeline page for half of the sites in SCM.
  Condition: This issue occurs when sites sending flows to SCM are configured with third-party zones through a single zone uplink. Because the Traffic Timeline page cannot determine the correct VLAN ID for each site, it does not display the site data correctly.
• SCON-28166 - Symptom: Read-only admin users experience delays when logging in to SCM.
  Condition: This issue occurs when many organizations are present.
• SCON-28019 - Symptom: SteelHead SD doesn't identify its public IP address.
  Condition: This issue occurs when DNS domains are configured.
• SCON-27226 - Symptom: The SCM ping tool uses the wrong interface as the source interface for the ICMP packet when testing the connection for the PPPoE uplink.
  Condition: Ping fails when testing the source uplink to the destination IP.
• SCON-19455 - Symptom: SteelConnect Manager fails to create AutoVPN tunnels among sites with the same public IPv4 address.
  Condition: When multiple sites exist and those sites share the same public IPv4 address, and AutoVPN IPv4 target address settings for uplinks on those sites are heterogeneous (a mix of external and internal), then SteelConnect Manager will fail to properly create tunnels among those sites.
• SCON-19203 - Improved IKE tunnel negotiation by addressing several security flaws.
• SCON-19202 - Upgraded Open vSwitch to version 2.9.0.
  
• SCON-21048 - Symptom: The toggle button on the top-right corner of Network Design -> Clusters page was removed so users can only see the table view.
  Condition: The cluster map was removed because it did not add value.
• SCON-20544 - Symptom: Appliance overheating causes unexpected shutdown.
  Condition: Appliance reaches a critical temperature and shuts down.
  
• SCON-18565 - Symptom: The SDI-130 and SDI-330 gateways have already implemented the protected port feature supported by the hardware switch. The protected ports option prevents broadcasting storms because the STP is disabled when appliances run in HA.
  Condition: Protected ports should run on SDI-1030 and SDI-VGW gateways for preventing Layer 2 loops, which are more likely to occur when they are running in HA.
• SCON-14237 - Symptom: SCM can create zones with empty subnets, which cause SCM to go into an inconsistent configuration state.
  Condition: SCM allows creation of a site and its associated zones when the network pool is exhausted. Zones created in such a state do not have subnets. This results in an inconsistent configuration.
  
• SCON-26279 - Symptom: WAN optimized SMB traffic is taking an unexpected path and not following the expected traffic rule.
  Condition: This issue occurs when the uplinks in MPLS and internet WAN are configured with different AutoVPN priorities.
• SCON-26090 - Symptom: The gateway routes encrypted packets on the LAN side.
  Condition: This issue occurs when a third-party routed supernet on the zone is configured to include the uplink network address of the remote site (such as /16 as a third-party zone and /24 or /30 on the uplink).
• SCON-25970 - Symptom: The duplex setting is incorrectly reported for 10-G (DPDK) ports. For example, the port shows half duplex when it is actually using full duplex.
  Condition: Anytime the link is up for a 10-G port, its duplex setting will be reported incorrectly.
• SCON-25228 - Symptom: Sometimes LLDP does not add type 3 TLVs to LLDP packets on autotrunking-enabled ports after start-up. This leads to the autotrunking feature not becoming active.
  Condition: A potential start-up race condition during configuration can trigger this issue.
• SCON-23248 - Symptom: On enabling a port, the UI reports the port is up, but the functionality of that port might not work.
  Condition: Due to overflowing queues, we lose the event to provision the port.
  
• SCON-23033 - Symptom: Traffic intended to travel through a SteelHead optimized HTTPS connection is routed through an unexpected path.
  Condition: When WAN optimization is on and the application target of a traffic rule is set to SSL, the system does not correctly classify SSL traffic and the traffic will not travel across the SteelHead optimized path.
• SCON-22531 - Symptom: Access point LAN ports can be configured from the UI.
  Condition: This issue occurs when clicking on the LAN link for an access point on the DHCP Leases page.
• SCON-22524 - Symptom: The Classic VPN tunnel comes up but does not process traffic flows.
  Condition: This issue occurs when the remote host is specified as a hostname rather than an IP address.
• SCON-22299 - Symptom: The firmware upgrade fails on SteelHead SD appliances.
  Condition: Multiple DNS servers are configured (either through a site-level DNS or a DHCP lease file) and a different server resolves the download domain (download.riverbed.com) to different IP addresses.
• SCON-27479 - Symptom: Zscaler tunnels are not working. The remote IP address of the tunnel does not match the remote IP address of the interface.
  Condition: This issue occurs when the primary and secondary Zscaler nodes for a site are swapped. The swap can happen either through manual action by the user or through automatic node selection.
• SCON-31459 - Symptom: A full data path outage occurs on an SDI switch.
  Condition: In 2.11.1, a network configuration change in SCM results in an unreachable state of an SDI switch. In 2.12.0, a network configuration change that affects an SDI switch results in it going offline.
• SCON-22176 - Symptom: Under certain conditions, adding additional SDI-5030 appliances to an already existing cluster containing only one appliance can cause the cluster to go into an irrecoverable error state.
  Condition: An SDI-5030 cluster with only one appliance already exists and additional SDI-5030 appliances are added to the same cluster.
• SCON-21833 - Symptom: Tunnels fail when multiple sites are behind the same NAT.
  Condition: This issue occurs when multiple sites are NATed through the same public IP address. Only one of the sites is able to form tunnels with remote sites.
• SCON-6976 - For long-running flows, SCM always reports their start time stamps as the top of the minute. All flows are exported at the top of the minute as opposed to following the 60-second active timeout, where each flow is expected to be exported based on its own activity timeline. This behavior may impact the accuracy of Insights reporting especially when devices other than SCM that follow the 60-second active timeout also report to Insights.
  

Known Issues

• SCON-27088 - SteelConnect devices may forward traffic to incorrect VLANs or have a forwarding loop between the other virtual router.

Detailed Description: Symptom: SteelConnect devices may forward traffic to incorrect VLANs or have a forwarding loop between the other virtual router.
Condition: This issue occurs when employing zone HA on a segment that also has other VRRP device groups. The VRRP ID used by the SteelConnect devices is in conflict with the VRRP ID being used by the external devices.

Suggested Workaround: Change the conflicting vrrp session ID on non RVBD devices to a number greater than 50.

• SCON-16920 - SteelConnect Access Point 3 and Access Point 5 can occasionally lose link connectivity when directly connected to an SDI-1030 gateway.

Detailed Description: Symptom: SteelConnect Access Point 3 and Access Point 5 can occasionally lose link connectivity when directly connected to an SDI-1030 gateway.
Condition: Access Point 3 and Access Point 5 directly cabled to an SDI-1030 gateway can occasionally lose link connectivity.


Suggested Workaround: Connect the AP-3 and/or AP-5 to the SDI-1030 Gateway via a switch.

• SCON-30423 - SteelHead SD appliances and SteelConnect SDI-2030 gateways show latency spikes every 60 seconds.

Detailed Description: Symptom: Latency spikes are observed every 60 seconds.
Condition: The garbage collection logic runs every 60 seconds. On an appliance with a large number of flows, this process ends up causing a latency spike in the data plane.

Suggested Workaround: Increase flow reporting interval

• SCON-29836 - During power up or reboot, an SDI-130 or SDI-330 gateway can occasionally reboot multiple times in quick succession.

Detailed Description: Symptom: During power up or reboot, an SDI-130 or SDI-330 gateway can occasionally reboot multiple times in quick succession.
Condition: SDI-130 and SDI-330 gateways can sometimes fail to detect the on-board switch during boot. When this occurs, the gateway will reboot immediately and attempt to reconnect to the on-board switch during the next boot.

Suggested Workaround: None

• SCON-29694 - Internet breakout at the site level doesn't honor the organization level setting when enabled.

Detailed Description: Symptom: Internet breakout for a leaf site doesn't work when defined at the site level.
Condition: This issue occurs when breakout is defined at the site level.

Suggested Workaround: None

• SCON-26211 - The backup appliance in an SDI HA pair loses connectivity to SCM when local internet uplinks are down.

Detailed Description: Symptom: The backup appliance in an SDI HA pair loses connectivity to SCM when local internet uplinks are down.
Condition: This issue occurs when an SDI HA pair is configured in dedicated port mode, all local internet uplinks are down, and the only path to the internet is through an MPLS WAN with an internet breakout set to a remote site.

Suggested Workaround: None

• SCON-26056 - On the SDI-5030 gateway, higher latency is reported on a deployment with a large number of subnets.

Detailed Description: Symptom: Packets flowing through the SDI-5030 gateway experience higher latency.
Condition: This issue occurs when a large number of concurrent flows is received.

Suggested Workaround: None

• SCON-34686 - Azure instances get stuck in the Retrying Undeploy state without any clear reason.

Detailed Description: Symptom: Azure instances get stuck in the Retrying Undeploy state without any clear reason.
Condition: When undeploying Azure instances, they might get stuck if SteelConnect Manager fails to remove any of the deployment artifacts from Azure.

Suggested Workaround: None

• SCON-34657 - DNS-based custom IP:port applications are classified incorrectly on SteelHead SD appliances and SDI-2030 gateways.

Detailed Description: Symptom: DNS-based custom IP:port applications are classified incorrectly on SteelHead SD appliances and SDI-2030 gateways.
Condition: When a custom IP:port application is created with hostname:port, a corresponding Traffic rule or Outbound/Internal rule is created.
When traffic is started for the given hostname, it is not classified as the custom application. The custom application with IP:port for the same hostname works correctly.

Suggested Workaround: Define custom IP:port applications using IP address:port instead of hostname:port.

• SCON-34506 - SCM traffic timeline statistics are inconsistent with the Top Talkers report on the SteelHead.

Detailed Description: Symptom: SCM traffic timeline statistics are inconsistent with the Top Talkers report on the SteelHead.
Condition: This issue occurs when SCM is not able to process incoming flows in a timely manner. As a result, some flows are missing from the traffic timeline.

Suggested Workaround: None

• SCON-34461 - A default zone is not created during new site creation.

Detailed Description: Symptom: A default zone is not created during new site creation.
Condition: This issue occurs when all IP addresses from the numbering pool have already been allocated. After the pool is exhausted, SteelConnect is unable to create a default zone for the new site.

Suggested Workaround: None

• SCON-22223 - Internet breakout via the WAN breakout site doesn't work when WAN encryption is off.

Detailed Description: Symptom: The WAN breakout site is ignored, and traffic is routed onto the underlay.
Condition: This issue occurs on the WAN with an internet breakout site when encryption is disabled.


Suggested Workaround: None

• SCON-31501 - After a prolonged WAN outage, SteelHead-v cannot resolve ARP for the gateway LAN0_0 IP address.

Detailed Description: Symptom: The MAC address for the gateway is displayed as incomplete.
Condition: This issue occurs after a prolonged WAN outage.

Suggested Workaround: None

• SCON-33538 - An Active Directory user sync "Through appliance" on a SteelConnect SDI-5030 gateway gets stuck at "Waiting for callback from sync appliance."

Detailed Description: Symptom: An Active Directory sync fails with the message "Waiting for callback from sync appliance."
Condition: This issue occurs when a SteelConnect SDI-5030 gateway is configured as a bridge appliance. Active Directory user sync is not supported on a SteelConnect SDI-5030 gateway.

Suggested Workaround: None

• SCON-33446 - After creating an outbound rule to allow traffic to and from a local zone, the traffic does not return to the originating zone.

Detailed Description: Symptom: Traffic such as ICMP will fail when using echo requests between the local and remote zones specified in the outbound rule.
Condition: This issue occurs when you create an outbound rule to deny all traffic by default, and then allow specific traffic flows as needed. An outbound rule that allows any source traffic to any destination works in both directions. However, if you specify a specific source to a destination (such as an IP or zone), the flow is blocked upon return. Adding an additional firewall rule for the return traffic will resolve the issue.

Suggested Workaround: None

• SCON-33215 - The Wi-Fi planner occasionally takes a long time to load floor plan images and fails.

Detailed Description: Symptom: The Wi-Fi planner occasionally takes a long time to load floor plan images and fails.
Condition: This issue occurs occasionally. Retrying allows the image to load.

Suggested Workaround: None

• SCON-32431 - Zscaler endpoints with a "Do Not Provision" flag are not available in SCM.

Detailed Description: Symptom: Certain Zscaler endpoints are not available in SCM.
Condition: This issue occurs when endpoints have the "Do Not Provision" flag enabled.

Suggested Workaround: None

• SCON-33200 - In a dual-hub deployment, the flow table entries report an incorrect remote site ID.

Detailed Description: Symptom: In a dual-hub deployment with SteelHead SD 2.0 appliances, traffic reporting of the remote site ID may be inaccurate.
Condition: This issue occurs because the dual-hub configuration learns the same subnet from more than one site. Although the reported remote site ID is inaccurate, the traffic flows on the correct path.

Suggested Workaround: None

• SCON-33902 - During HA failover, route flaps occur on the LAN router.

Detailed Description: Symptom: During HA failover, routes on the LAN router momentarily flap and then recover.
Condition: This issue occurs in a SteelConnect HA appliance configuration where a backup node is configured with a lower router ID and the LAN routers are configured with the next-hop pointing to the backup node. If HA failover is triggered, the backup becomes the master. The routes in the LAN router flap momentarily even though there is no failure in the next-hop backup node.

Suggested Workaround: None

• SCON-33808 - Outbound firewall rules are not applied on short-lived connections.

Detailed Description: Symptom: Outbound firewall rules are not applied on short-lived connections. As a result, SteelHead SD 2.0 appliances do not block the traffic denied in the outbound rule.
Condition: This issue occurs on short-lived connections when application classification is incomplete.

Suggested Workaround: None

• SCON-33963 - The 5-GHz Wi-Fi radio goes offline when configuring "Default" or "40 MHz" bandwidth on an SDI-130 gateway.

Detailed Description: Symptom: On an SDI-130 gateway, selecting "Default" or "40 MHz" bandwidth for the 5-GHz Wi-Fi radio in certain countries will cause the 5-GHz radio to go offline.
Condition: This issue occurs in Wi-Fi sites located in countries that don't allow 40-MHz bandwidth (that is, channel aggregation) in the 5-GHz spectrum, including Bahrain, Costa Rica, Ecuador, El Salvador, Guam, Indonesia, North Korea, and Sri Lanka.

Suggested Workaround: None

• SCON-32544 - An SDI-5030 gateway in a gateway cluster may report incorrect cluster health status to SCM.

Detailed Description: Symptom: An SDI-5030 gateway in a gateway cluster may report incorrect cluster health status to SCM.
Condition: This issue occurs when the user creates or upgrades an SDI-5030 gateway cluster of three nodes with the data ports disabled on the SDI-5030 gateways.

Suggested Workaround: Enable data ports associated with appliances resided in cluster

• SCON-26251 - Xirrus access points stop forwarding DHCP packets to SteelConnect gateways.

Detailed Description: Symptom: After a period of time, clients stop getting DHCP replies. After troubleshooting, the client creates DHCP requests but the gateway doesn't receive the reply. TCP dumps indicate the client is sending the request but it doesn't make it past the Xirrus access point.
11:19:57.210175 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f0:18:98:24:e2:42, length 300
11:20:06.004887 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f0:18:98:24:e2:42, length 300
11:20:14.160589 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from f0:18:98:24:e2:42, length 300
Other times, the gateway receives DHCP packets and does not respond. Rebooting the gateway or access point fixes the issue.
Condition: This issue occurs with Xirrus access points on a SteelConnect network. Native VLAN is not enabled and there is a simple 1VLAN link from the switch to the Xirrus access point.

Suggested Workaround: Reboot the SDI Gateway or Xirrus Access Point.

• SCON-21653 - The Blocked Connections tab on the SteelHead SD 2.0, SteelConnect SDI-2030 gateway, and SteelConnect SDI-5030 gateway does not report firewalled connections in SCM.

Detailed Description: Symptom: The Blocked Connections tab on the SteelHead SD 2.0, SteelConnect SDI-2030 gateway, and SteelConnect SDI-5030 gateway does not report firewalled connections in SCM.
Condition: This issue occurs with connections that have been firewalled by the appliance.

Suggested Workaround: None

To view the release notes for previous versions, please visit SteelConnect support and select the version of interest.

If you have questions regarding this update, please contact Riverbed Support for assistance.