SCC Best Practices
This chapter describes the best practices for configuring SCC features. It includes these sections:
Best practices for SCC 9.9
Use these best practices with SCC 9.9. This section includes a quick introduction to the best practices and links to more detailed information.
Latency detection
When peer SteelHead appliances are geographically very close, which might occur in full-mesh topologies, the network latency between them can be very low. In cases were the latency between peers is low enough, simply passing traffic through would be faster than transmitting optimized traffic. Traditionally, you would need to configure in‑path rules for each connection you wanted peer appliances to pass through traffic—a daunting task for a large network.
Now, you can use latency detection policies to globally manage how peer SteelHead appliances determine whether to pass through traffic or to continue to optimize it. You can still disable the feature on specific connections by setting an in‑path rule and selecting the option to ignore latency detection. For more information, see these topics:
Peering mode for client authentication
Introduced in SCC 9.8 (CLI only), peering mode for client authentication can now be configured in the GUI. When using peering mode client authentication, the SteelHead acts as a trusted “man‑in-the-middle.” When a client certificate request arrives from the server:
1. The server-side SteelHead replies to server’s client certificate request with its own peering certificate.
2. The client-side SteelHead requests a client certificate in response to the client hello.
3. The client-side SteelHead authenticates the client certificate using the existing trusted CA repository.
This mode supports the Ephemeral Diffie-Hellman key exchange.
Note: When upgrading to SCC 9.9, the client authentication setting of any appliance managed by SCC will be overwritten.
For more information, see
Client authentication.Riverbed software image verification
Riverbed software images are now digitally signed, ensuring the integrity and authenticity of the image. Verifying an image is performed by comparing a public key, or image signing certificate, with the image signature. The public key for Riverbed images can be found at
https://support.riverbed.com.
Image verification is enabled by default. We strongly recommend that it remain enabled at all times. Disable this feature only when absolutely necessary.
Enhanced host proxy settings
In SCC 9.9 and later, you can configure proxy addresses for web or FTP proxy access to managed SteelHead appliances. Additionally, you can create a whitelist of domains to allow direct SteelHead to SCC communication. For more information, see
Configuring general host settings.Best practices for SCC 9.8
Use this best practice with SCC 9.8. This section includes a quick introduction to the best practice and links to more detailed information.
Security Assertion Markup Language
SCC 9.8 introduces support for Security Assertion Markup Language (SAML) 2.0. SAML is an XML standard that exchanges user authentication and authorization data in XML format between SCC and the IdP. Once SAML is enabled, SCC can use more than one factor of authentication such as common access card (CAC) or personal identity verification (PIV) to confirm the user’s identity.
SAML user authentication is performed by a third-party IdP server instead of the local, RADIUS, or TACACS+ servers, providing a single point of authentication. Also SAML requires that user accounts be stored in IdP. Access to these user accounts are not only asserted but can also be encrypted and/or signed, increasing security. SAML also enables users to log in to multiple SAML-enabled appliances without entering their credentials, once their identity has been authenticated with IdP.
SAML authentications are only available in the Management Console web interface; they are not available through the CLI. Users can log in to the Management Console of a SAML-enabled appliance, provided their user accounts have been set up in IdP. Users who have not been mapped to IdP can log in through the CLI but are authenticated using the local, RADIUS, or TACACS+ authentication methods.
For details, see
Configuring SAML.SCC 9.8 adds more new features listed in the SteelCentral Controller for SteelHead Installation Guide.
Best practices for SCC 9.7
Use these best practices with SCC 9.7. This section includes:
Restricted policy access for role-based management users
Administrators and system administrators can restrict editing and deleting of policies in groups for which role-based management (RBM) users don’t have access in the Administration >Security: User Permissions page. RBM users can still view and edit the policies associated with the groups for which they have access. RBM users with only read/write access to a group can view and edit the policies associated for that group. This feature is disabled by default.
• If RBM users create a new policy by copying an existing policy for which they have deny access to, they can still view the existing policy’s configurations in the new policy they created.
• RBM users with deny access to a group can’t view the policies associated with that group from the Manage > Policy page.
• RBM users with read-only access to a group can only view the policies associated with that group from the Manage > Policy page. Read-only users can’t edit policies.
• RBM users with read/write permissions to a group can view, modify, and delete the policies associated to that group.
• RBM users can’t edit or attach a policy to an accessible group if that policy is already attached to a group for which the user doesn’t have read/write permission.
Unmanaged Appliances report
The Unmanaged Appliances report provides an efficient way to assess the inventory of devices discovered by the SCC in large environments where only a select number of SteelHeads are managed by the SCC. It also enables you to separate the unmanaged devices that you might want to eventually manage from other devices that are owned by different groups, departments, or divisions within the enterprise so that you can assign them to a specific group in the SCC. The Unmanaged Appliance report:
• collects peer and neighbor information during maintenance windows.
• provides a list of all connected/HTTP and disconnected appliances.
If any peer is not found in the connected appliances list, it is added to the list of unmanaged appliances.
Best practices for SCC 9.6
Use these best practices with SCC 9.6. This section includes:
SCC scales to 2500 appliances
The SCC can manage up to 2500 appliances on models 1000, 8151, and 8152. The SCC-VE (virtual models 8151 and 8152) configuration must be equivalent, or better, to the model 1000 to support 2500 appliances. For details about scaling best practices, see
SCC scaling best practices.System administrator accounts on the SCC
With SCC 9.6, the administrator (admin) user can create system administrator accounts on the SCC. You can create system administrator accounts in the User Permissions page. For details, see
Managing user permissions. The first system administrator account must be created by the admin user. Role-based management (RBM) users are not allowed to create system administrator accounts. If you require additional system administrator accounts, they can be created by either the admin user or the already created system administrators.
System administrators have the same permissions and privileges as the admin user, thus they can perform all appliance operations, including creating RBM users. For managed appliances, there are no differences between the admin user and the system administrators.
System administrators can’t access the shell.
To create a system administrator account
1. Log in to SCC as the admin user.
2. Choose Administration > Security: User Permissions.
3. Click + Add a New Account to expand the page.
4. Specify the account name, password, confirm password.
5. Under Roles and Permissions, select Administrator and click Add. The system administrator account is created.
6. To check the account, log in as the new system administrator and choose Manage > Topology: Appliances. Make sure you can perform all operations on managed appliances.
Safety accounts on the SCC
With SCC 9.6, administrator users and system administrators (admin/sys admin) can create safety accounts to increase security and to conform to Defense Information Systems Agency (DISA) requirements. Safety accounts are applicable for these remote authentication method settings:
• RADIUS only
• TACACS+ only
• RADIUS, TACACS+
• TACACS+, RADIUS
If the login fails and the timeout limit is reached for each authentication server, then the safety account is activated. The safety user is authenticated using a local authentication server. The admin/system admin can only create one safety account for the user.
The safety account enables you to log in to the SCC even if remote authentication servers are unreachable.
Safety accounts can only be created by admin/system administrator users. You create safety accounts on the General Security Settings page. For details, see
Configuring general security settings. To create a safety account
1. Log in to the SCC as admin/system admin user.
2. Choose Administration > Security: General Settings page.
3. Select the remote authentication method from the drop-down list. (Make sure you have configured the RADIUS or TACACS+ server before you make these changes.)
4. Select Safety Account and select the safety account user from the drop-down list.
5. Click Apply.
6. To check the safety account, stop the remote authentication method, verify the RADIUS or TACACS+ isn’t reachable, and log in as the remote authentication user. This login will fail. Log in using the safety account user.
Web proxy on VCX models
With SCC 9.6, web proxy is supported on virtual SteelHeads VCX-10 to VCX-90 models. Web proxy is enabled on these virtual SteelHeads if:
• the VCX is properly licensed.
• the management disk is large enough to allocate at least 5 GB of space to the web proxy cache.
You can configure the total cache size in the SCC Web Proxy Settings page for the registered VCX appliance. If you make a change to the web proxy cache size and web proxy is running, the web proxy is automatically restarted. Disabling web proxy on VCX models will disable all web proxy alarms but it will not affect the existing cache.
Important: Any changes to an already configured web proxy cache size will purge the cache. We recommend that you make these changes cautiously.
To understand the web proxy cache for VCX, you must understand the difference between the:
• Configured cache size - This is the cache size that you configure in the SCC Web Proxy Settings page for the registered VCX appliance or using the CLI commands for web proxy cache. If the configured cache size is larger than what the disk can support, an alarm is raised.
• Actual cache size - Actual disk space available for the web proxy cache on the management disk. This value differs from if the cache size isn’t configured or if the disk doesn’t have enough disk space for the configured cache size. For example, let’s say you have configured a web proxy cache size of 15 GBs but the actual available space on the disk is 5 GBs, then the actual cache size is 5 GBs because this is what the disk can support.
Enlarging the cache size
You can enlarge the cache size up to your current license limit (licenses range from 200 GBs to 800 GBs). If the disk doesn’t have enough space, the SCC uses the minimum cache size value (that is, the disk size available and the configured cache size value). If you make a change to the web proxy cache size and web proxy is running, the web proxy is automatically restarted. Any changes to the web proxy cache size will purge the cache, thus we recommend that you make these changes cautiously.
Upgrading or downgrading your cache license
You can upgrade your VCX license to increase the web proxy cache size. Upgrading the license will increase the number of optimized connections and will also increase the cache size. However, if you have already configured a web proxy cache size and you increase the cache based on your license upgrade, the cache will be purged.
If you downgrade a cache license, the SCC will automatically reduce the cache size to the new maximum size and the cache will be purged.
To configure the web proxy cache size
1. Choose Manage > Appliances to display the Appliances page.
2. Click the VCX10-90 model that you want to configure to expand the page.
3. Click Appliance Pages and select Web Proxy Settings to display the Editing Appliance Configuration: <appliance name>, Web Proxy Settings page.
4. Under Cache Size, specify the size of the cache in GBs. If the configured cache size is larger than what the disk can support an alarm is raised.
5. Click Apply.
IPv6 connection forwarding support in Interceptor clusters
SCC 9.6 supports connection forwarding in clusters. This feature enables a deployment of appliances in a pure IPv6 environment where Interceptors, SteelHeads, and the SCC are deployed.
All appliances in the cluster must be using IPv6. In addition, the SteelHeads and the SCC must be running version 9.6 and the Interceptors must be running version 6.5. If connection forwarding IPv6 is disabled, appliances running SCC 9.6 continue to interoperate with appliances running older releases.
IPv6 connection forwarding isn’t supported:
• on virtual in-path Interceptors.
• when path selection is enabled.
• when multi-interface support is disabled.
• with IPV6 and WCCP.
To enable IPv6 connection forwarding in clusters
2. On the Connection Forwarding Settings page under Neighbor Table, specify the In-Path IP addresses, Additional IP addresses, and click Add. Once IPv6 connection forwarding is enabled, the neighbors table will accept only IPv6 IP addresses.
Temporary password on the SCC
To increase security and to conform to DISA requirements, a temporary password option has been added to the SCC Password Policy page. A temporary password can be enabled only if Account Password Control is enabled.
When you enable a temporary password, you will be prompted to change your password when you first log in or after the admin/system admin has reset the password and you log in. The feature ensures that the admin/sys admin are able to configure the SCC to allow the use of a temporary password for system log ins with an immediate change to a permanent password.
This feature applies only to local authentication servers.
To enable a temporary password
1. Choose Administration > Security: Password Policy.
2. Select Enable Account Password Control.
3. Select Strong Security Template or Basic Security Template to populate values for password management.
4. Select Enable Temporary Password Setting.
5. Log out of the system or inform the user of the password change and instruct them to log out of the system.
6. Log in to the system.
7. Specify your Current Password, New Password, Confirm Password and click Change Password.
Capturing TCP dumps for Interceptor clusters
With RiOS 9.6, the SCC customizes the display in the TCP Dumps page to guide you to specify the correct endpoints (that is, IP addresses) so that you can capture all relevant packets to debug Interceptor cluster configurations. This feature reduces the number of TCP dumps taken for debugging and cluster set up.
Previously you would have to create multiple TCP dumps, such as Interceptor—>SteelHead, Server—>Client, and so forth to obtain all the data you need to debug cluster configuration. With RiOS 9.6, you can capture all relevant packets in a single TCP dump.
TCP Dump capture supports IPv4 traffic with correct addressing and full-transparency mode. For IPv6 traffic, all relevant packets are captured as long as there are no IPv6 extended headers in the data packet originating on the client or server.
Best practices for SCC 9.5
Use these best practices with SCC 9.5:
SCC scaling guidelines
SCC 9.5 has an improved multithread statistical retrieval system and an enhanced appliance filter for managing up to 1500 appliances. Adhere to these guidelines for deployments with 1500 appliances:
• Legacy policy pushes must be limited to 200 appliance at a time. This process may take several minutes for a larger set of appliances.
• Hybrid network policy pushes are limited to 500 appliances at a time. This process may take several minutes for a larger set of appliances.
• If a legacy and hybrid networking policy push must be performed together, then the push is limited to 200 appliances at a time. This process may take several minutes for a larger set of appliances.
• When upgrading large deployments, the initial upgrade may take a several hours.
• If your deployment contains more than 1000 appliances, backups will take more than three hours.
Configuring SSL-signed proxy certificates
In customer deployments where there are multiple SteelHeads that need to communicate with each other over a secure channel, a proxy certificate is required for SSL optimization.
SCC 9.5 introduces a new workflow to automate CA signing for proxy certificate to SteelHeads. A new service on SCC queries the SteelHead once every six hours for the list of bypassed SSL servers. An SCC policy can then be used to issue a proxy certificate from the SCC CA for the bypassed SSL server (that is, those servers that are not optimized). Next, a push policy is used to push the SCC CA-issued proxy certificate to the SteelHead.
You generate proxy certificates using the Generate Proxy Certificates wizard. The wizard contains a list of bypassed servers that are not yet optimized with the server name, appliance name, and Covered By (that is, the proxy-certificate common name for that server) fields. If a wild card certificate is present then the Covered by field is the name of the wild-card certificate. The first fetch of bypassed servers starts 30 minutes after an SCC upgrade, reboot, or restart. After that, the SCC fetches the bypassed server information every six hours. You must push the policy to the server for it to be optimized. The changes will be reflected in the wizard after the next fetch operation (that is, 6 hours later).
Note: If you don’t want to wait until the next bypassed-servers fetch, you can perform a service restart using the CLI and wait 30 minutes.
Bypassed servers can be disabled for these reasons:
• A wild card certificate exists for the bypassed server.
• The certificates are generated and are yet to be pushed to the appliance.
• The certificates have recently been pushed and the next fetch operation has not yet occurred.
• If a signed certificate already exists for the server but has not been pushed.
Note: If the CA has an expiration of less than 60 days then the SCC can’t generate the proxy certificate.
To configure CA proxy certificates
1. Choose Manage > Policies to display the Policies page.
2. Click +Add Policy to expand the page.
3. Type a policy name and description and click Add to display Editing Policy page.
4. Click + Add/Remove Pages to display the Add/Remove Policy Pages pop-up window.
5. Under Optimization, select SSL Main Settings and click Apply to display the Editing Policy page.
6. In the Editing Policy page click SSL Main Settings to display Editing <policy name> page.
7. Click Include to include the policy in the policy push.
8. Select Enable SSL optimization and click Apply. You must enable SSL optimization before you generate the proxy certificate using the wizard.
9. To associate the appliance with the policy, choose Manage > Appliances.
10. Choose Manage > Policies to return to the Policies page.
11. Edit the SSL Main Settings page of the policy and select Generate Certs for Bypassed Servers.
12. Under SSL Server Certificates, click
+ Generate CA Signed Certs to display the Generate Proxy Certificates wizard. A list of servers that are not yet optimized are displayed. For details about disabled servers, see
Configuring SSL-signed proxy certificates. 13. Select the servers and click Generate Certs to generate the proxy certificates. A message appears stating that the certificates have been generated and the certificates appear in the Proxy Certificate list.
14. Choose Manage > Appliances to return to the Appliances page.
15. Click Appliance Operations to expand the page.
16. Select the appliance you want to push, select Push Policies from the drop-down list, and click Push.
17. Choose Manage > Operations: Operations History to verify that the operation was successful.
Note: After generating and pushing proxy certificates from the SCC, the bypassed servers list will still show the pushed servers with the message “Certificates are yet to be pushed.” The SSL discovery service fetches the bypassed servers list every six hours and stores it in the database. After the next fetch, the servers will not be listed. If you don’t want to wait until the next bypassed-servers fetch, you can perform a service restart using the CLI and wait 30 minutes.
Troubleshooting
Here are some tips for configuring proxy certificates:
• You must first enable the SSL service to generate proxy certificates.
• The server CA must have an expiration of greater than 60 days to generate a proxy certificate.
• You can view the discovered servers fetch operation in the SteelHead system logs:
Importing CAs into the SCC trusted store
SSL certificate verification requires a complete chain of certificates. Using the Trusted CA Store page you can import third-party signed certificates and certificate chains into the SCC CA service. You can also import root certificates separately or together as a chain.
The Trusted CA store displays a list of trusted CA stored in a secure vault that are used to verify end-user CAs that are imported into SCC.
Whether the SCC CA is used as the root CA or an intermediate CA depends on how the organization manages their private key infrastructure (PKI). Some organizations do not have a PKI; in this case, the SCC has to be the root CA. In other organizations, they might have a PKI in place and would like to manage this as a single entity. So, they will place the SCC under it, and SCC will be the intermediate CA. Often SteelHeads are managed by the network team and the PKI is managed by the security team. In this case, they might want a segregation so the SCC has to be a root CA.
You have these options for importing intermediate CAs:
• Add the CA’s public certificate to the Trusted CA Store page and import the end-user certificate from the SCC Certificate Authority page.
• Import the complete chain of the certificate from SCC Certificate Authorities page. The end-user certificate must be the first certificate in the chain.
• Import the missing chain from SCC Certificate Authorities page and:
– Add the certificates (intermediate or root CA) from the missing chain to the Trusted CA Store.
– Import the remaining certificate including the end-user certificate from SCC Certificate Authorities page. (The end-user certificate must be the first certificate in the chain.)
To import a CA into the Trusted CA Store
1. Choose Administration > Security: Trusted CA Store to display the Trusted CA Store page.
2. Click + Import New Certificate to expand the page.
3. Complete the configuration as described in this table.
Control | Description |
Optional Local Name | Optionally, specify the name of the trusted CA store. |
Local File | Select this option and browse to the local file. |
Cert text | Select this option to copy and paste the certificate authority. |
Add | Adds the certificate authority to the trusted CA store. |
4. The certificate appears in the CA list.
Web proxy improvements
The SCC 9.5 includes these web proxy improvements:
Configuring site and site type profiles
You can create more specific configurations for web proxies based on sites and site types. Each profile contains all the configurations displayed in the Global Profiles table on the Web Proxy page. A site or site type receives the settings from the Global profile of the Site profile—there is no mixing or matching between the two profiles.
To configure a site or site type profile
1. Under Site of Site Type Profile, click + Add Profile to display pop up window.
2. Complete the configuration as described in this table.
Control | Description |
Profile Name | Specify the name of the web proxy profile so that you can easily distinguish it from others. |
Duplicate Existing Profile | Select one of these options • Create Blank Profile - Creates a new profile. • Duplicate existing profile - Select and click the text box to display the existing profiles from which to choose from. |
Site | Select one of these options • Site - Select and click the text box to display the available sites. • Site Type - Select and click the text box to display the available sites. |
Create Profiles | Creates the site or site type profile. |
Modifying web proxy profiles
You can modify Web Proxy profiles from the profiles list.
To modify site or site type details
1. Click Edit Profile for the profile that you want to view in the profiles list.
2. Click Edit, to display the Edit Web Proxy Profile pop up window.
3. Type a new profile name.
4. Select Site or Site Type, select the new value, and click Save.
5. Under Web Proxy, configuration modify your configuration settings and click Save.
6. Under HTTPS Whitelist, click + Add Domain to display the pop-up window.
7. Specify the domain name you want to include and click Save.
Configuring parent proxy chaining
Most enterprise customers have an existing proxy or cloud web security server for caching or security services. The parent proxy chaining feature provides interoperability with a transparent upstream parent proxy or an explicit parent proxy setting to provide a local cache to save bandwidth. Enabling parent proxy reduces additional round trips if content can be served from a cache.
This feature supports these parent proxy modes:
• Off - No parent proxy is configured. This is the default setting.
• Automatic (Explicit) - Clients/browsers are explicitly configured to connect to an upstream proxy. In automatic mode the client/browser has an explicit IP address defined in its advanced network settings that defines how the browser connects to the internet. You must import the Certificate Authority (CA) of the parent proxy on to the client-side SteelHead if the parent proxy is intercepting and decrypting HTTPS connections.
• Manual (Transparent) - Clients/browsers connect transparently to the HTTP/S server. Clients/browsers have no knowledge of the proxy. You must import the Certificate Authority (CA) of the parent proxy on to the client-side SteelHead if the parent proxy is intercepting and decrypting HTTPS connections.
You can only have one mode configured on the SCC.
DNS resolution must succeed on SteelHeads for parent proxy chaining to function properly.
Configuring Manual Mode
In manual mode the web proxy transparently redirects the connection to the selected parent proxy. You can exclude domains so that they are not proxied to the upstream parent.
The parent proxy is selected based on:
• Scheme - Depending on the type of traffic, the first parent proxy listed in the HTTP/HTTPS list is selected as the parent proxy. You can have the same parent proxy listed under HTTP and HTTPS. The same parent proxies can have multiple ports. You can have a maximum of 5 parent proxies listed. For HTTPS, you must import the CA for the parent proxy onto the client-side SteelHead.
• Mode - The default mode is failover. In failover mode if the first parent proxy listed is down the traffic is routed to the next parent proxy in the list and so forth. If none of the parent proxies are up the connection is black-holed. You can also configure load-balance mode using this CLI command:
web-proxy parent manual mode {[failover] | [load-balance]}
where load-balance selects the parent proxies in a round-robin fashion.
Local caching isn’t affected in manual mode.
When the system doesn’t detect a certificate and the packets are tunneled it will appear in the system logs. You can view top domains and top URLs in the Web Proxy report. For details, see
Viewing web proxy reports.To configure a manual parent proxy
1. Choose Manage > Optimization: Web Proxy to display the Web Proxy page.
2. Under Parent Proxy, click the > to expand the page.
3. Select Manual to transparently redirect connections to the listed parent proxies.
4. Under HTTP Servers and HTTPS Servers, specify a comma-separated list of parent proxy servers. You can have a maximum of five servers. You can have the same parent proxies in both HTTP and HTTPS. You can also have multiple ports listed for the same parent proxy.
5. Click Save to save your settings.
6. Optionally, to exclude domains from the parent proxy click + Add Domain to display the Parent Proxy Exceptions pop up window. This traffic will not go through the parent proxy.
7. Specify a domain name and click Save. The domain exceptions appear in the domain exception list.
8. For HTTPS, you must import the CA for the parent proxy onto the client-side SteelHead. For details, see the SteelHead User Guide.
9. Under Push to Appliances on the right-side of the window, specify the site or site types and appliances and click Push to push your settings.
Configuring automatic parent proxy chaining
Configure automatic mode for clients/browsers configured with a proxy auto-config (PAC) file or an explicit proxy defined on the browser. In automatic mode the client opens a connection to a proxy specified on the browser:
• If HTTP, it sends a GET request with the correct host header, for example wikipedia.com.
• IF HTTPS, it sends a CONNECT request followed by a handshake.
The client/browser opens a connection to a specific proxy and uses that particular connection to multiplex all of its requests.
Automatic mode doesn’t cache non SSL traffic. Also you can’t define exception domains in automatic mode.
No traffic is optimized if automatic mode is off and the client/browser has an explicit proxy defined.
To configure automatic parent proxy chaining
1. Choose Manage > Optimization: Web Proxy to display the Web Proxy page.
2. Under Parent Proxy, click the > to expand the page.
3. Select Manual to transparently redirect connections to the listed parent proxies.
4. Select Automatic and click Save. The traffic is transparently redirected to a proxy explicitly defined in the client/browser.
5. For HTTPS, you must import the CA for the parent proxy onto the client-side SteelHead. For details, see the SteelHead User Guide.
6. Under Push to Appliances on the right-side of the window, specify the site or site types and appliances and click Push to push your settings.
Viewing web proxy reports
The Web Proxy page provides these reports:
• Optimization Report - Lists LAN and WAN data transfer and cache-hit ratio for sites or site types. The cache-hit ratio is aggregated across all SteelHeads. The report displays hourly data points for the one month.
• Top 10 Report - Displays the top 10 domain requests, top 10 domains by size, and the top 10 URLs by size for sites or site types.
To view optimized web proxy sites or site types
1. Choose Reports > Optimization: Web Proxy to display the Web Proxy page.
2. Select All Sites to display all sites or select Site or Site Type and specify the site in the text box.
3. Click Optimization or Cache Hit Ratio to select the type of report.
4. Mouse over a specific data point to see the y values at that time stamp.
To view the top 10 domains for web proxy sites or site types
1. Choose Reports > Optimization: Web Proxy to display the Web Proxy page.
2. Select All Sites to display all sites or select Site, or Site Type and specify the site in the text box.
3. Click Domains by Requests, Domains by Size, or URL by Size to display the type of report.
4. Mouse to hover over a specific data point to see the y values at that time stamp.
IPv6 support
SCC 9.5 includes support for IPv6 in these areas:
• Communication Channels - The SCC can communicate with appliances using SSH and HTTPS (OCC) channels. IPv6 support has been added to both communication channels.
• Appliance Manageability - The SCC 9.5 supports IPv6 addresses for its base interfaces (that is, DNS, hosts, and web/FTP proxy), NTP servers, logging, SMTP trap receivers, RADIUS servers, and management interfaces for in-path interfaces.
• Policy Pages - SteelHead policy pages accept IPv6 addresses for host settings (that is, DNS, hosts, and web/FTP proxy), NTP servers, logging, SMTP trap receivers, and RADIUS servers. The peer IP address in the In-path Peering Rules page now accepts IPv6 addresses, and in addition, an Enable Enhanced IPv6 Auto Discovery option has been added.
• Interceptor Cluster Pages - IPv6 addresses are accepted on load-balancing and in-path rules for Interceptor clusters. In addition, an IPv6 routing table has been added for in-path interfaces.
Note: The SCC doesn’t support IPv6 addresses in SMTP. For sending email over IPv6, you should specify the hostname of the email server.
Changing the hostname from IPv4 to IPv6
The SCC uses SSH and HTTPS to communicate with appliances. The SSH connection is initiated from SCC, and merely changing the SCC hostname from the SteelHead will not disconnect and reinitiate the SSH connection. You must explicitly break the SSH and HTTPS channels on the SCC. You can break the channels in any one of these ways:
• The IPv4 channel can be broken by disabling the IPv4 address from the Interface.
• The IPv6 channel can be broken by disabling the IPv6 address from the Interface.
• Rebooting the SCC.
Alternatively, you can also break the SSH/HTTPS channels by either:
• running the CLI command no scc enable on the SteelHead.
• specifying the new IP address of SteelHead in the Manage > Appliances: Appliances Pages: Host Settings. For details about change the SteelHead appliance IP address in the SCC, see
Managing host settings. For detailed information about the possible IPv4 to IPv6 workflows, see
Changing the hostname from IPv4 to IPv6.Upgrading SCC to IPv6
The SCC can manage both IPv6 and IPv4 appliances. IPv6 configuration pushes to older appliances might fail if the appliances don’t support IPv6.
To upgrade the SCC to IPv6
1. To upgrade to SCC 9.5, Choose > Administration > Software Upgrade to display the Software Upgrade page. For details, see
Upgrading your software. 2. To assign an IPv6 address to the SCC, choose Administration > Host settings to display the host settings page. Make sure you add the IPv6 address to the DNS settings. For details, see
Changing the hostname from IPv4 to IPv6. 3. To assign IPv6 address to the appliance using SCC, choose Administration > Appliances: Base Interfaces and assign the IPv6 address to the appropriate interfaces and push configuration to appliance. For details, see
Configuring base interfaces. 4. To upgrade your managed appliances and assign IPv6 addresses to each, choose Manage > Policies to display the policies page. For details on managing appliances using policies, see
Managing policies. 5. After changing IPv6 addresses on both the SteelHead and the SCC, we recommend you restart the SCC.
Best practices for configuring hybrid networking 9.0 or later
Hybrid networks combine private assets such as MPLS-based WAN networks with public services such as the Internet. RiOS provides application-level Quality of Service (QoS) and WAN path selection to control network consumption and prioritize critical and latency sensitive applications, while minimizing use by noncritical applications.
RiOS 9.0 and later provide the ability to configure a network topology and define application policies based on business requirements. These features provide the reusable building blocks that form the basis for configuring the features in a hybrid network: QoS, path selection, secure transport, application statistics, and web proxy.
Network topology
You define your network topology and application policies once and then reuse them as needed. The topology provides the network point-of-view to all possible sites, including the network of the remote site and a remotely pingable IP address.
A network topology includes these WAN topology properties:
• Networks - The networks represent the WAN clouds that sites and site types use to communicate to each other using Primary MPLS, VSAT, or the Internet. Basically, a network connects two uplinks between two sites. The SCC creates two nonsecure networks: MPLS and Internet. You can create additional secure and nonsecured networks or rename the precreated networks based on your topology requirements. You can also configure the Max Backoff Interval for a network to improve path selection performance. If there is no traffic at a site, the Max Backoff Interval default value of 1800 seconds determines how often that uplink is probed. Networks are important for path selection and secure transport. For details, see
Defining networks. • Sites - Define the discrete physical locations of Riverbed devices such as SteelHeads in the network (for example, a branch office or data center) so that you can more easily configure and manage your network. A site is a logical grouping of subnets and represents the physical and logical topology of a site type. You classify traffic for each site using IP addresses. Sites are linked to one or more networks. The local sites use the WAN in the network definition to connect to the other sites. The default site is a catch-all site that’s the only site needed to backhaul traffic. Sites are used with the path selection, QoS, and secure transport features. For details, see
Defining sites. • Site Types - Groups one or more sites based on common attributes, such as business function and size. Riverbed automatically creates the basic site types: Data Center, Branch, and Headquarters. Site types are the building blocks for QoS profiles and pushing 9.0 and later features to SteelHeads. For details, see
Defining site types. • Uplinks - Define the last network segment connecting the local site to a network. You define carrier-assigned characteristics to an uplink: for example, the upload and download bandwidth and latency. An uplink must be directly (L2) reachable by at least one SteelHead or Interceptor in the local network. An uplink doesn’t need to be a physical in-path connection. Path selection uses only local uplinks. SteelHeads deployed in hybrid networks send ICMP probes on uplinks to establish contact with the appliances in the network. This uplink probing frequency can affect the scaling and performance of hybrid networks. Path selection rule-aware probing improves deployment scalability of hybrid networking. For details, see
Hybrid network path selection probing techniques and
Defining uplinks. • Uplink Types - An uplink type is a name for similar functioning uplinks. On the SCC, uplink types can be used across multiple sites and path selection rules can be created using these names. The name must be unique at a site (but it can be same across different sites) so that the system can detect which path selection rule uses which uplinks. Because path selection rules are global on the SCC, you’re restricted to eight uplink types. Uplink types are the building blocks for path selection. You select the path preference order using the uplink types created, and it is used in various sites. We recommend that you reuse the same uplink types at different sites in order to label uplinks based on the preference for path selection. For example, you can label uplink types as primary, secondary, and tertiary based on the path selection preference. The uplink type can be based on the type of interface or network resource, such as Verizon or global resource of uplink abstraction that’s tied to a network. On the SteelHead, this field is called the
Uplink Name; on the SCC it is the
Uplink Type. For details, see
Defining uplink types. • Regions - Groups of sites based on a geographic location, such as North America, Europe, and so on. Regions are particularly important in reporting. Regions help you to troubleshoot network issues. For details, see
Defining site regions. The Sites & Networks page is central to defining networks and sites, to viewing sites with which a network is associated, changing or deleting sites, and assigning uplinks to a site.
Application performance
The SCC provides visibility into how applications are performing and reporting metrics such as traffic levels, application throughput performance, and TCP session flow characteristics. These performance metrics provide visibility to help diagnose problems and maintain control over your application infrastructure.
Using the SCC, you can define application policies based on business requirements, enabling you to easily leverage and control hybrid networks for accelerated application delivery. The SCC is prepopulated with known applications, and provides application groups to easily enable business-intent policy definition. You can also add custom applications. Based on your defined application groups, the SCC quickly derives all possible paths based on path availability and enables you to prioritize, secure, and deliver critical applications over the faster networks and less-critical, recreational applications and bulk backups over the Internet.
Application policies simplify application and path management, ensure service-level delivery for business-critical applications, and increase end-user productivity. The SCC manages hundreds of applications, including policy configuration, reporting, and troubleshooting.
For detailed information, see
Managing application policies.Hybrid network path selection probing techniques
SteelHead in-path interfaces, with path selection enabled, send ICMP probes to other SteelHead in-path interface peers to determine path availability. The frequency and coverage of these probes can directly affect the responsiveness and accuracy of path selection in determining path failures to enact policy-based actions. RiOS 9.2 and SCC 9.2 and later balance path selection responsiveness and accuracy with probe frequency and coverage, ensuring optimal performance with minimal network impact and high scale. Some of the probing techniques have user configurable options to address a varying deployment scenarios. You can view the state of the individual probing techniques by running this CLI command on the SteelHead:
show path-selection settings internal probe status
Traffic Aware Backoff Status: Enabled
Rate Limit Status: Enabled
Subset Probing Status: Enabled
Traffic aware backoff probing
SteelHeads gradually reduce probing frequency to remote sites that have no traffic, from the default Timeout rate of every 2 seconds down to the default Max Backoff interval of every 1800 seconds. You configure the Max Backoff Interval when you define a network on the SCC.
When path selection is enabled, SteelHeads probe automatically at the configured Max Backoff Interval. When the first connection is seen by the SteelHead, the probing interval changes to the default configured value.
You can change the Max Backoff Interval and Timeout values on the SCC to whatever values are best suited for your hybrid network. On the SteelHead, you can view the back-off probe setting using the show path-selection debug networks CLI command.
For details about configuring the Max Backoff Interval in a network, see
Defining networks. For details about configuring the uplink’s Timeout interval in sites, see
Defining sites.Subset probing on SteelHeads
RiOS 9.2 and later avoids probe redundancy by probing only a subset of peers instead of probing all peers. For example, if there are four peers on a path that’s up and actively seeing traffic, the probe monitors two peers instead of four. On the SteelHead Path Selection page, peers that aren’t probed due to subset probing appear as Unknown. On the SteelHead, you can view your settings using the show path-selection debug paths CLI command.
Rate limited bandwidth probing
You can increase the efficiency of probing by limiting the number of probes that occur per second on an uplink. In the SCC, when you create an uplink you can enforce a bandwidth rate limit on all probes in the Probe Settings: Bandwidth field. The default bandwidth is 128 kbps. On the SteelHead, you can view your settings using the show path-selection debug uplinks CLI command.
We recommend that if you have a data center that’s loaded, that’s receiving traffic from all peers 100 per cent of the time, you should increase the Probing bandwidth on all SteelHeads to 512 kbps. This setting results in a path failover time of approximately 6 seconds.
Path selection rule aware probing
Another technique used by SteelHead path selection to reduce and manage probing overhead is rule-aware probing. If there are uplinks that aren’t referenced in any path selection rule, they’re not probed. This feature is useful when secure transport is enabled where you have secure uplinks and nonsecure uplinks, but the nonsecure uplinks aren’t referenced in a path selection rule. On the SteelHead Path Selection page, the uplink status displays Healthy and the peers appear as Unknown.
Hybrid networking workflow
Task | Notes | For detailed instructions |
1. Configure applications based on application groups. | Check if the applications are defined in the Application Flow Engine (AFE). If they aren’t already defined, you must configure them and assign them to an application. Application policies enable you to prioritize traffic with QoS and steer traffic down a particular path with path selection. | |
2. Configure your network topology. | The network topology creates the building blocks for QoS, path selection, secure transport, web proxy, and application statistics. For example, define the network and set up the local and remote sites for QoS. Configure the bandwidth to and from the sites. | |
3. Configure QoS Profiles. | Configure QoS profiles that contain the QoS classes and rules for traffic going to a site. You can assign a single QoS profile to many sites. Make sure you associate the QoS profile with a site. In your QoS rules you associate an application group to the class structure hierarchy. | |
4. Configure path selection. | You create path selection rules based on application groups. To improve performance for path selection deployments, make sure that you configure uplink probe scaling features on the SCC and SteelHead. For details, see Hybrid network path selection probing techniques. | |
5. Configure secure transport. | Specify a secure network when you define a network on the Sites & Networks page. | |
Best practices for SCC 9.1 and 9.2
Use these best practices with SCC 9.1 and 9.2:
Autonegotiation of Multi-Stream ICA
Autonegotiation of Multi-Stream ICA enables Citrix Multi-Stream ICA without the need to configure it on the Citrix server. This feature provides application class hints to QoS for the four priority connections when Citrix Multi-Stream ICA is negotiated. This feature also provides the ability to apply path selection to the individual Citrix priority groups.
Autonegotiation of Multi-Stream ICA allows you to configure of true network-based QoS policies to the individual priority groups for the virtual channel traffic that they carry. The SteelHead identifies the priority of each connection, allowing for finer-grained QoS shaping or marking of Citrix traffic. You enable autonegotiation of Multi-Stream ICA on the client-side SteelHead. The client-side SteelHead automatically verifies if the client and server support autonegotiation of Multi-Stream ICA, and then autonegotiates with the client to use it.
When disabled, Citrix clients use one TCP connection per Citrix session unless XenApp/Desktop server is used in conjunction with Outbound and Inbound QoS, on both the client-side and server-side SteelHead.
Autonegotiation of Multi-Stream ICA can also be used in conjunction with the path selection feature.
Both the client-side and server-side SteelHead must be running RiOS 9.1. The Citrix deployment must support Multi-Stream ICA.
You enable autonegotiation of Multi-Stream ICA for SteelHeads when you configure a Citrix policy on the SCC.
For detailed information, see
Citrix.To configure autonegotiation of Multi-Stream ICA
1. Choose Manage > Policies to display the Policies page.
2. Click the policy name that you want to modify in the policies list to expand the page.
3. Click + Add/Remove Pages to display the Add/Remove Policy pages pop-up window.
4. Under Optimization, select Citrix and click Apply to add Citrix to the policy pages list.
5. Select Citrix in the table to edit the Citrix policy page.
6. Under Settings, select Enable Auto-Negotiation of Multi-Stream ICA and click Apply.
HTTPS communication channel
In SCC 9.1 and later, if the HTTPS channel isn’t established, the Management Console displays:
Disconnected: No HTTPS Connection
You can also view the status of these channels on the SteelHead using this CLI command:
amnesiac > show scc
Auto-registration: Enabled
HTTPS connection (to the CMC):
Status: Connected
Hostname: 10.0.0.7
SSH connection (from the CMC):
Status: Connected
Hostname: bravo-321 (10.0.0.7)
When the host for the HTTPS and SSH connections are different or both the channels don’t have Connected status, the appliance can’t be fully managed by the SCC:
amnesiac > show scc
Auto-registration: Enabled
HTTPS connection (to the CMC):
Status: Auth_Failed <<Must show “Connected” to push hybrid features>>
Hostname: riverbedcmc
SSH connection (from the CMC):
Status: Connected
Hostname: bravo-321 (10.0.0.7)
To connect and establish connections between a SteelHead to the SCC, run this command while in configuration mode:
scc hostname <hostname> <<The hostname must be same as when you run the "show scc" command>>
If both connections show Connected to two different SCCs, remove the appliance from the Manage > Topology > Appliances page on the SCC that’s incorrect and update the appliance username and password on the correct SCC.
If the SCC hostname was never configured on the appliance, the appliance will try to connect to the host riverbedcmc. Make sure to update your DNS to point the hostname riverbedcmc to the correct SCC that’s managing the appliance.
If the HTTPS connection hasn’t been established on the SCC, contact Riverbed Support at
https://support.riverbed.com.
MAPI over HTTP optimization
SCC 9.1 and later provide bandwidth optimization for the MAPI over HTTP transport protocol. Microsoft implements the MAPI over HTTP transport protocol in Outlook 2010 update, Outlook 2013 SP1, and Exchange Server 2013 SP1.
You enable MAPI over HTTP optimization using the SCC when you configure a MAPI policy on the client-side SteelHead. You must also create an in-path rule using the Exchange Autodetect latency optimization policy to differentiate and optimize MAPI over HTTP traffic.
SSL optimization must be enabled and the server certificate must be installed on the server-side SteelHead.
Only Scalable Data Referencing (SDR) is supported. Both the client-side and server-side SteelHeads must be running RiOS 9.1 or later.
For detailed information, see
MAPI.To configure MAPI over HTTP optimization
1. Choose Manage > Policies to display the Policies page.
2. Click the policy name that you want to modify to expand the page.
3. Click + Add/Remove Pages to display the Add/Remove Policy Pages pop-up window.
4. Under Optimization, select MAPI and click Apply to add MAPI to the policy pages list.
5. Select MAPI in the list to edit the MAPI policy page.
6. Scroll down and select Enable MAPI over HTTP optimization and click Apply.
To enable Exchange Autodetect for latency optimization in an in-path rule
1. Choose Manage > Policies to display the Policies page.
2. Click the policy name that you want to modify to expand the page.
3. Click + Add/Remove Pages to display the Add/Remove Policy Pages pop-up window.
4. Under Optimization, select In-Path Rules and click Apply to add In-Path rules to the policy pages list.
5. Select In-Path Rules in the table to edit the In-Path Rules policy page.
6. Click the in-path rule you want to modify to expand the page or click + Add an New In-Path Rule if you’re creating one for the first time.
7. Under Latency Optimization Policy, select Exchange Autodetect and click Add.
Migrating appliances to sites
SCC 9.0 introduced the concept of sites, networks, and uplinks to organize appliances into a network topology. For detailed information about sites, see
Managing sites and networks.With defined sites, you can easily track user issues based on the location of the appliance and troubleshoot problems. Sites are required for path selection, QoS, and secure transport. The SCC includes a migration wizard with comma-separated values (CSV) import and export so that you can easily migrate appliances and appliance groups to sites. For detailed information for migrating appliances to sites, see
Migrating appliances to sites.You migrate the existing appliances or group of appliances to sites for hybrid networking features, such as path selection, QoS, or secure transport. There are two types of migrations provided for sites:
• Bulk Migration - Bulk migration allows you to migrate groups of appliances to more than one site in a single operation. It is a useful tool when you want to create many sites at once. The bulk migration wizard provides a custom CSV template with the list of appliances that aren’t part of any site and the format in which the sites must be entered in the CSV template. You edit the downloaded CSV template to specify the sites and other site-related information, and then upload the CSV. Upon uploading the CSV file, the SCC creates the sites according to the configuration in the CSV file. For details, see
Migrating appliances to sites. • Create Sites Individually - Alternatively, you can create individual sites manually using the basic site creation form in the Appliances page or the detailed form (for features such as secure transport) on the Sites & Networks page. Creating sites allows you to map your unassigned appliances to sites. For details, see
Managing sites and networks. Order of migration
You can upgrade from SCC a multistep upgrade ensures that automigration of statistics occurs correctly. Contact Riverbed Support at https://support.riverbed.com for detailed information about upgrade paths.
If you’re upgrading managed SteelHeads to 9.0 or later to use path selection, QoS, and secure transport, you must follow a particular migration order. These steps assume that you have upgraded your SteelHeads to RiOS 9.0 or later and that the HTTPS-based communication channel is running. These steps outline the order in which the migration of path selection, QoS, and secure transport should be performed.
To configure path selection only
2. Create any custom-defined applications that you needed in your network. For details, see
Defining applications. 3. Create the new set of path selection rules using application groups and applications that are needed for your SteelHeads running RiOS 9.0 and later. For details, see
Configuring path selection rules. To configure QoS only
3. Run the QoS migration wizard to migrate existing basic and advanced QoS policies to the global QoS profile. For details, see
Migrating legacy QoS policies. Alternatively, if you don’t want to run the migration wizard, you can create a new or copy an existing QoS profile using the newly migrated sites or site types.
To configure secure transport only
1. Make sure your SteelHeads have an SSL license. Due to export control of encryption, each SteelHead is required to have an SSL license before it can join the secure transport group. For detailed information about verifying SteelHead licenses, see the
SteelHead User Guide. If you don’t have a valid enhanced cryptography license key file, go to
https://sslcert.riverbed.com and follow the procedures documented there.
4. Create networks with secure uplinks. All appliances in the sites containing an uplink with a secure network will be a part of the secure transport group and are listed as secure transport peers. For details, see
Defining networks. 5. Migrate your existing appliances managed by the SCC to one or more sites containing one or more uplinks with the secure network. For details, see
Migrating appliances to sites. 7. Configure the path selection rules to use secure uplinks for required applications. Traffic will not be secured if path selection rules don’t use the secure uplinks.
If you want configure all of these features, you must create sites with uplinks containing secure networks; then you can do the migration in any order. If you’re performing a QoS migration, the legacy policies that need to be migrated must be included in the push and assigned to an appliance or group.
Pushing hybrid networking features
For a push to function correctly, the HTTPS-based communication channel must be set up and connected. We recommend that you select site types over sites if pushing to numerous sites in a single push operation.
After you configure hybrid networking you push the configuration to the appliances in your network. For the initial configuration the SCC pushes the entire configuration. For SteelHeads and an SCC running 9.2 and later, any changes made after the initial push, the SCC pushes only the modified settings to ensure adequate response times and improved throughput performance.
Note: When you perform a policy push, the SCC is the master configuration; any local changes made on SteelHeads are overwritten.
In SCC 9.0 and later, the new REST API-based push can be used from the path selection, QoS, and application statistic collection pages. In order to push the configuration, you can either select Sites or Site Types but not both. This restriction prevents overlapping push jobs. There are two types of pushes to choose from:
• Pushing all features (that is, the entire topology) - This pushes all the hybrid network features currently, including the sites topology and applications. Because the new features use legacy host labels and port labels that are assigned to the Global group, we recommend doing a legacy push as well. We recommend using this option when you’re pushing these features for the first time or if there is a change in sites or applications.
• Pushing individual features - This pushes either path selection rules, QoS profiles, application statistic collection settings (9.1), and web proxy settings (9.1). We recommend using this option when you have only modified these individual features.
After selecting Site or Site Types and any of the above push options, you push the configuration. The push job status can be viewed in the Operations table on the Operations History page. It displays detailed push status and any issues occurred during the push.
For detailed information about pushing path selection rules, QoS profiles, and application statistic settings, see
Pushing your settings and viewing push status.QoS migration
SCC 9.0 and later enable you to migrate your legacy QoS policies (basic and advanced) to QoS profiles using a migration wizard. You must perform these prerequisite steps before beginning the migration wizard:
• Include the basic and advanced legacy policies in the push.
The migration wizard uses the existing assigned QoS rules and they’re included in the legacy policy pushes to provide you with the choices for QoS profiles. You might need to wait for approximately five minutes before starting the migration if there are any changes made to the legacy policy. The migration is a bulk migration—migrating a legacy policy can result in the creation of more than one QoS profiles. The migration doesn’t affect the existing legacy QoS policy. These legacy policies continue to be applied to SteelHeads running RiOS earlier than 9.0.
A QoS profile in SCC 9.0 or later defines endpoints to which this profile will apply. Specifically it defines the source and destination sites or site types. A QoS profile is a container for QoS rules and QoS classes. When pushing QoS profiles, only the selected sites or site types in the push will be applied to the QoS profiles.
Since a QoS profile applies to source and destination sites, site types, or any site, the migration wizard gives you the choice to select these settings. Specifically, during the migration, you’re asked to specify the source and destination sites for sites or site types or any site. We recommend you select site types rather than sites. Selecting site types applies all sites in that type in the QoS profile and makes QoS profiles more manageable. Only select sites when you want the QoS profile to apply to that site. Also selecting sites as a source or destination choice for a QoS profile overrides the QoS profile containing the site type to which this site belongs.
QoS migration can result in QoS profiles that might already exist. The migration wizard doesn’t override these profiles. If you want to override these profiles, you must delete the QoS profiles and rerun the wizard. SCC 9.0 or later doesn’t allow overriding or deleting the Any Site to Any Site QoS profile during migration.
The source site selection is determined by the subnets in the legacy QoS policy that are now part of the site. Subnets in the legacy policy must map to sites. Destination site selection is determined by the service policies in the basic QoS policy or the class hierarchies in the advanced QoS policy. For advanced QoS policies, Riverbed doesn’t recommend that you select the All QoS Class Hierarchies option as this might cause the creation of many QoS profiles containing destination sites instead of site types. Selecting this option results in QoS profiles becoming unmanageable.
In QoS, you define uplinks for a QoS rule and DSCP values for a site. The DSCP values steer traffic based on policy-based routing (PBR) to an upstream router.
After migration has completed, you can’t revert your QoS settings in a legacy-basic outbound QoS policy to a basic outbound QoS mode. You’re encouraged to create a copy of the legacy policy before you migrate to advanced outbound QoS.
SteelCentral AppResponse support
You can use SCC 9.0 or later to configure the communication between SteelHeads running RiOS 9.0 or later and the SteelCentral AppResponse running 9.0 or later.
The SCC collects SteelFlow WTA data that can be sent (via REST API) to a SteelCentral AppResponse appliance. SteelFlow web transaction analysis (WTA) data includes the HTTP time stamp and payload data for web objects optimized by the SteelHead. SteelCentral AppResponse combines this data into page views and calculates detailed metrics for server and network busy times, HTTP request and response delays, slow pages, view rates, HTTP response codes, and so on.
You enable REST API access and add an authorization code on the SCC as part of a SteelHead policy. After you push the policy to the SteelHeads that you want SteelCentral AppResponse to monitor, you run a CLI command to email a CSV file that contains the configured SteelHeads and the authorization codes. You then import this CSV file onto the SteelCentral AppResponse appliance. After the SteelCentral AppResponse has the authorization codes, you can view data for the SteelHeads in the group.
For detailed information about configuring SteelCentral AppResponse support in as part of a SteelHead policy, see
HTTP.Web proxy
A single-ended web proxy transparently intercepts all traffic bound to the Internet. The web proxy improves performance by providing optimization services such as web object caching and SSL decryption to enable content caching and logging services. The efficient caching algorithm provides a significant advantage for video traffic. The benefit comes in the form of multiple users viewing the same video content, thereby saving significant WAN bandwidth and providing efficient network use. YouTube caching is handled as a special case given its growing popularity in the enterprise.
Web proxy improves HTTP performance and reduces congestion on Internet traffic. It also provides performance benefits when you access HTTP(S) servers on the Internet directly from a branch office. It provides visibility to all Internet activity at any given branch as long as that destined traffic passes through the web proxy.
The HTTP web proxy has these characteristics:
• The cache sizes range from 50 GB to 500 GB on SteelHeads.
• The cache content is persistent after reboots and service restarts.
• There isn’t individual object size limitation.
• The cache storage space has been expanded on SteelHeads.
• The request logging format has been expanded to improve visibility, debugging, and diagnostics.
• You can use the Web proxy with virtual in-path deployments such as WCCP and PBR.
For detailed information about web proxy, see
Managing web proxies.You can view web proxy connections in the SteelHead in the Current Connections report as a new connection type: web proxy.
You can also view the cache hits for all SteelHeads configured with web proxy in the Web Proxy reports page.
Configuring web proxy on the client-side SteelHead
Before you begin configuring web proxy on the SCC, you must perform these steps on the client-side SteelHead. Web proxy doesn’t require a server-side SteelHead to function.
The client-side SteelHead must have the ability to access Internet traffic from the in-path interface.
To configure web proxy on the client-side SteelHead
1. On the client-side SteelHead choose Networking > In-path Interfaces: In-Path Interface Settings, for the interface that’s configured to access the Internet.
2. Add the In-Path Gateway IP address and click Apply.
Configuring the certificate authority on the SCC
You must configure the Certificate Authority (CA) on the SCC to generate server certificates for decrypting whitelisted domains. A whitelist is a list of domains for which you want to decrypt traffic for HTTPS caching.
To configure the CAAS on the SCC
1. Choose Administration > Security: Certificate Authority to display the Certificate Authority page.
2. Select Enable/disable the certificate authority and click Apply.
3. Click Replace to display the controls for adding a CA.
4. If you have an existing private key and CA-Signed Public Certificate, select Import Existing Private Key and CA-Signed Public Certificate, and import an existing key and certificate pair.
or
If you don’t have a private key and CA-signed Public Certificate, select Generate New Private Key and Self-Signed Public Certificate, specify the self-explanatory Self-Signed Certificate fields, and click Generate Key and Certificate.
If HTTPS is enabled, the CA certificate must be trusted by the client browsers that are accessing the web proxy. Those domains defined in the domain whitelist will display a pop-up window stating that the certificate isn’t trusted. Make sure that all domains defined in the web proxy whitelist have the CA configured on the client browser.
To trust web clients with the SCC CA
1. Copy and paste the CA certificate in PEM format into a text file.
2. Install the certificate on the system as Trusted Root Certificates.
or
or
5. Double-click CA certificate (that is, the .crt extension) to install it.
Configuring web proxy on the SCC
You perform these steps to enable HTTP and HTTPS web proxy on the SCC.
To configure web proxy for HTTP and HTTPS
1. Choose Manage > Optimization: Web Proxy to display the Web Proxy page.
2. To perform HTTP caching, under Global Configuration, select Enable Web Proxy.
3. If you want to decrypt and cache HTTPS traffic, select Enable HTTPS Optimization.
4. Click Save to save your settings.
5. Under Global HTTP Whitelist, click + Add Exception to display the pop-up window.
6. Add a domain, either a hostname (for example, www.riverbed.com) or a wildcard domain (for example, *.riverbed.com) that you wish to decrypt in web proxy. The server certificate is generated against the specified hostname or wildcard domain. Repeat this process for any other domain names.
Important: For HTTPS web proxy, before adding domains, make sure that the SCC CA is trusted by all clients/browsers defined in the domain whitelist.
7. Click Add Domain to save your settings.
8. On the right-side of the page, under Policy Push Control, click Include in Push.
9. Under Push to Appliances, select Sites or Site Types that contain the client-side SteelHead to which this configuration should be pushed.
10. Click Push and wait for the Push Status to display Success.
In-path rule requirements for HTTP caching
The in-path rule table includes a default web proxy rule set to Auto. By default, all traffic not specified in user-configured rules is web proxied for Internet-bound traffic. This includes all traffic destined to public IP addresses not included in Request for Comments (RFC) 1918 on port 80 and 443. Only IPv4 is supported for web proxy.
If you need a more fine-grained rule for public IP addresses, then you must add a new in-path rule with these options:
• Type: Auto Discover
• Web Proxy: Auto
• Source Subnet: IPv4 address or subnet
• Destination Subnet: IPv4 address or subnet
• Port: No matter what port is specified, only port 80 and 443 traffic is directed to the web proxy
If you need an in-path rule for private or intranet IP addresses, specify these options:
• Type: Pass Through
• Web Proxy: Force
• Port: Any port or port-label specified is proxied. This value results in plain TCP proxying without optimizations if the traffic isn’t detected to be HTTP or HTTPS.
There is a default pass-through rule for all secure ports traffic above the default in-path rule that prevents all traffic to port 443 from being intercepted. If HTTPS proxying is required, then the pass-through rule (as described above) must be added above the secure ports rule, to direct SSL traffic to the web proxy.
After you configure your web proxy in-path rules policies in the SCC, you push the policy to the SteelHeads in the Appliance Operations page.
Configuring in-path rules on the SCC
You configure in-path rules on client-side SteelHeads when you create a policy. For detailed information about creating policies, see
Managing policies.To configure in-path rules policies on the SCC
1. Choose Manage > Policies to display the Policies page.
2. Click + Add Policy to expand the page.
3. In the Policy Name text box, type web proxy.
4. Click Add to add a new policy.
5. Under Edit Policy Web Proxy, click + Add/Remove Pages to display the pop-up window.
6. Scroll down to Optimization and select In-Path Rules, and click Apply.
7. Under Optimization, click In-Path Rules in the policies pages list to display the In-Path Rules page.
8. Click + Add a New In-Path Rule to expand the page.
9. Add the required in-path rules and click Add to save your settings.
10. Choose Manage > Appliances and select the SteelHead with web proxy.
11. Click Appliance Operations at the top of the Appliances page to display the Appliance Operations page.
12. From the drop-down list select Push Policies and click Push to push your policy to the appliance.