About sites

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

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

A site is essentially a grouping of subnets, representing both the physical and logical structure of a site type, such as a data center or various sizes of branch offices. Traffic is classified for each site using IP addresses. Sites manage how traffic flows through SteelHeads, with their properties influencing both behavior and location.

When creating a site in the SCC, it’s important to assign all SteelHeads to that site, whether it's a parallel or serial deployment, or even no SteelHeads if necessary. After a state migration or RMA operation, you will need to manually add the appliance back to the site where it was originally located. Additionally, if the appliance being replaced was a secure transport concentrator, its configuration needs to be manually updated as well.

Path selection users can configure custom probe IP addresses for each site to specify specific endpoints to be probed for path availability. By default, the SCC uses the SteelHead in-path interfaces as probe endpoints, but with a custom probe, users can direct the SteelHeads to probe an IP address of their choice, such as a router, switch, or other system within the site.

Each SteelHead typically probes its neighbors within the site every 2 seconds by default. When a custom probe is configured, SteelHeads will instead probe the defined endpoint IP addresses.

This feature is especially useful for service-sensitive path selection deployments. It helps distinguish between accurate path availability and false positives or incorrect assumptions about service availability. By configuring custom probes, you ensure that only the specified endpoints need to be reachable for the path to be considered available.

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.