About sites

You define sites in the Sites & Networks page. Sites are required for hybrid networking features: QoS, path selection, secure transport, application statistics, and web proxy. SCC 9.5 and later support 1000 sites.

You can migrate appliances to sites using the bulk import method or a single manual method. For bulk migration you download a text file and fill it out. For detailed information, see About migrating appliances to sites.

A site is a grouping of subnets and represents the physical and logical topology of a site type. You classify traffic for each site using IP addresses. Site types are typically a data center, small, medium, and large branch office, and so on.

Sites manage the flow of traffic through SteelHeads, as the site properties link behavior and location.

On the SCC, when you create a site, you should assign all the SteelHeads to that site—this can be multiple SteelHeads in the case of a parallel or serial deployment or it could be none in the case where there are no SteelHeads at that site.

If you have completed a state migration or RMA operation, the appliance needs to be manually added into the site on which it was a member. If the appliance being replaced was a secure transport concentrator, this configuration needs to be manually changed as well.

Path selection users can specify, on a per site basis, specific endpoints to be probed to determine path availability rather than having the SCC automatically use that site's SteelHead in-path interfaces as probe endpoints. You configure a custom probe when you create a site.

Each SteelHead probes its neighbors in each site at the default time-out rate of 2 seconds. When you configure a custom probe for a site, instead of probing each of the SteelHead in-path interfaces in the site, the SteelHead probes an endpoint IP address that you specify. This endpoint can be a router, switch, or any system in the site.

For service sensitive path selection deployments, custom-probe endpoints can better distinguish between true path availability versus false positives or inaccurate assumptions of service availability. You use the custom probe feature to define, on a per site basis, IP addresses that must be available for a path to be considered available to use.

This figure shows SteelHead-8 (SteelHead-8) probing the endpoint (R-3) in Site-3 rather than the SteelHeads located in the site: that is, SteelHead-4 and SteelHead-5.

If the endpoint supports GRE encapsulation, then the probe will be successful from the other sites, otherwise the probes will fail.

If custom endpoints aren’t specified, then the SCC pushes the in-path interfaces as peers on the SteelHeads and vice a versa.

This feature is optional.

The SteelHead Local Site field is replaced by the Site Name field in the SCC. The SCC field has a different name because the SCC pushes the configuration settings relative to the SteelHead receiving the push. In other words, you have specified in the SCC which SteelHead belongs to that site and you push that information to the specified SteelHead. The SteelHead Local Site field is renamed automatically.

The SteelHead Default Site is renamed to the site you specified as a recipient of the backhaul traffic in the SCC. In the SteelHead, the default site owns the all zero destination network (that is, 0.0.0.0), eliminating the need to configure every single internet subnet. In the SCC, you can’t build a site and give it the 0.0.0.0 subnet because once the configuration is pushed to the SteelHead the 0.0.0.0 subnet belongs to the site that traffic is being backhauled to, which is the default site.

There is no field for the peer IP address to probe on the SCC because the SCC automatically fills in this value with the SteelHead in-path IP addresses. The SCC uses the SteelHead in-path IP addresses that you have associated to that site. If no SteelHead is assigned to that site, the default gateway is used. This is only relevant to path selection configurations.

For path selection, the most important setting in a site is the Internet Traffic field. This field functions differently on the SteelHead. In the SCC, you specify how internet-bound traffic is routed. You can choose Direct to Internet if you’re putting public internet traffic directly at the site. Direct to Internet traffic sends all traffic with an unknown destination to the specified default gateway.

Your other choice is Backhaul through Site. Configure this option if you have to send your traffic back through a specific site, typically the data center. The Backhaul through Site option sends all traffic to whatever site you specify in this field and this becomes the default site on the SteelHead. On the SteelHead, the default site is automatically renamed after you push your settings, so you don’t have to configure the default site on the SteelHead. You simply specify it on the SCC.