This chapter describes the groups and policies that the SCC uses to facilitate centralized configuration and reporting of remote appliances. This chapter includes the following topics:

You use groups to organize and arrange sets of managed appliances that share a common configuration policy into a logical container. Common methods of group organization include:

The SCC uses a hierarchical group model. The SCC defines the group hierarchy with the default Global group as the root. All user-defined groups and managed appliances are contained within the Global group. A managed appliance can be a member of only one group.

Figure: Manage appliances page shows an example of a group organized by business function.

Policies are sets of common configuration options that can be shared among different appliances independently or through group membership. You can specify a policy to a single SteelHead, or it can represent settings for all of the appliances in your enterprise environment.

This section includes the following topics:

The following policy types are available:

Policies consist of one or more policy pages. Policy pages generally correspond to a feature (or part of a feature). You must enable a policy page to push the settings you configure.

You can assign each group of appliances, or single appliance, any number of policies, as long as there’s no conflicting configuration among those policies.

For more information about working with policies, see the SteelCentral Controller for SteelHead User Guide.

You can apply policy pages to appliances as follows:

The Inherited Policies view ( Figure: Inherited policies view) shows all the policy pages that are scheduled to be pushed to an appliance on the next policy push, and which policy defines the configuration on that page. To view policies inherited by appliance, choose Manage > Appliance > [the appliance you want to view] > Inherited Policies.

Figure: Inherited policies view shows a SteelHead in the New York site (CFE) that doesn’t have a policy specifically assigned, so it inherits properties from the SSL policy, which is assigned to the group Global. The other SteelHead in a different location (SFE) can have different policies assigned. Individual settings in this policy override settings in the Global policy.

Inherited policies enable you to:

For example, a networking policy can configure Web Cache Communication Protocol (WCCP). It is unlikely that the WCCP configuration is the same across all data centers, so a Global DC Networking policy doesn’t need to include the WCCP settings. You can have the same Network Time Protocol (NTP) servers across all sites and belong to the same global policy.

Figure: Editing page for global dc networking policy shows that the WCCP page check box is not selected and the Host Settings page check box is selected. These selections indicate that WCCP settings aren’t configured by this policy, but that Domain Name System (DNS)—and other host settings—are configured by this policy.

Figure: Editing page for NY DC networking policy shows the Host Settings page check box is selected in the NY DC Networking policy, but the Port Labels page check box is not selected. A SteelHead doesn’t inherit host settings from a global networking policy, but it does inherit other pages, if available. The enabled pages in NY DC Networking override inheritance from parent policies.

Because of policy inheritance, policies you apply at the Global group provide the default settings for all managed appliances in your environment.

For more information about inherited policies, see the SteelCentral Controller for SteelHead User Guide.

You create policies on the Policies page. In environments in which there are preexisting supported Riverbed appliances deployed, you can use SCC to import the settings of these appliances into a policy. Importing allows you to quickly reuse and apply these settings to another appliance rather than creating them again in a new policy. To import the settings from a managed appliance, choose Manage > Services: Policies > [the appliance that you want to import from] and select Import policy from an appliance configuration ( Figure: Import configuration from managed appliance).

You can use the SCC-managed appliance group hierarchy and policy inheritance to streamline your policy design and configuration push. For example, if you want to apply port labels universally to every SteelHead in the environment, but NTP servers are specific to different locations, you can create two different networking policies. Apply the first policy for the port labels at the Global group level, and apply the second policy for the NTP servers at the data center group level or to the managed appliance.

Although creating a policy from a running appliance configuration is useful, you can end up with as many policies as there are appliances. Consider a group and policy plan before beginning to import SteelHead configurations into policies. Advance thinking about which settings you want to apply at which level prevents mistakes that require pages to be disabled in one policy and reenabled in a different policy at a different layer of the hierarchy. Advance planning about which common settings are shared among appliances in a group avoids the situation in which there’s a 1:1 ratio of policies to SteelHeads.

For more information about importing a running configuration into a new policy, see the SteelCentral Controller for SteelHead User Guide.

Existing settings in a SteelHead do not change until the new policy is pushed. The Push Required symbol is shown in Figure: Push Required symbol.

This symbol indicates that there have been policy or configuration changes on the SCC that haven’t been pushed to the SteelHead. The symbol also indicates that the configuration of the SteelHead is different from the expected configuration of the SCC for that SteelHead: for example, if you made a local change to a SteelHead. You only see the changes if the SteelHead is managed by the SCC at the times you made the change. You can fetch the appliance configuration from the Appliance Utilities tab in the Appliances page, but there’s no automatic comparison of this configuration against the expected policy configuration.

The symbol doesn’t persist after an SCC reboots.

In Figure: Example of an SCC-managed SteelHead requiring policy push, SteelHead EX is connected, but the Push Required symbol indicates that policies haven’t been pushed. The configuration doesn’t necessarily reflect the current policy settings until the policy has been pushed.

When the push is successful, the Appliances page shows an empty Push Required column. Figure: Appliances page showing an SCC-managed SteelHead not requiring a policy push shows that the SteelHead is operating with the new policy.

It is a best practice to make a copy of the policy before applying major changes to it. If the changes do not work as expected, you can reassign the previous policy to the affected SteelHeads and repush it to roll back the changes. You can delete the previous policy after changes are successfully applied.

The policy push operation from the SCC is atomic; that is, configuration nodes on the SteelHead aren’t left in a partially configured state.