This section introduces you to the components of the subnet table and illustrates how to use subnet sharing in the following deployments:
Each appliance builds a subnet table from entries added automatically by the system or manually by a user. When two appliances are connected by a tunnel, they exchange this information ("learn" it) and use it to route traffic to each other.
Use a Route Policy (or when using the Global Management System (GMS), use and apply a Route Policy template) for flows that are to be:
|
•
|
This section introduces the components of Appliance Manager’s Configuration - Subnets page.
 |
|
•
|
Use shared subnet information enables subnet sharing on the appliance.
If deselected, the subnet table is not used or available for auto-optimization. |
|
•
|
Automatically include local subnets adds the local subnet(s) of the appliance's interfaces to the subnet table. A local subnet is a subnet that includes one of the appliance IP addresses.
|
If deselected, the system doesn't create entries for the appliance's local subnets. If these subnets aren't listed, they cannot be shared with peer appliances for auto-optimization.
|
•
|
Metric for automatically added subnets indicates the priority (0 to 100) of a given subnet. The default priority is 50.
|
|
Value must be between 0 and 100. When an appliance finds that more than one peer appliance is advertising the longest matching subnet, it chooses the peer that advertises the subnet with the lowest metric value — that is, lower metrics have priority.
|
|||||||
|
The appliance sets this parameter for automatically added subnets because those subnets are directly attached to an appliance interface, and therefore are most likely local to the appliance.
Also, you can select the parameter when manually adding a subnet:
If a subnet is too wide, and it’s marked local, then the stats will count any pass-through packets with an IP address within that range as WAN-to-LAN.
|
|||||||
|
|||||||
An excellent opportunity for using subnet sharing is with data protection (replication and backup) deployments, where storage personnel seek to optimize their replication, and backup, workloads and improve RPO (Recovery Point Objective). Just put the Silver Peak appliance in the same subnet, and either add a static route or change the default gateway to be the Silver Peak appliance. This, in fact, eliminates the requirement for WAN-side redirection on the routers, saving storage personnel the need to coordinate with network engineers.
 |
Configure the subnet table at Replication Site 1, followed by the subnet table at Replication Site 2.
|
1
|
 |
|
a
|
Select Use shared subnet information.
|
|
b
|
Select Automatically include local subnets.
|
|
c
|
Click Apply. The appliance automatically adds its subnet and will share the information with its peers.
|
 |
Now, configure Replication Site 2’s appliance.
|
3
|
From the menu, access Configuration > Subnets. The Configuration - Subnets page appears and displays the subnet learned from its peer at the other site.
|
 |
|
a
|
Select Use shared subnet information.
|
|
b
|
Select Automatically include local subnets.
|
|
c
|
Click Apply. The appliance automatically adds its own subnet and shares the information with its peers.
|
 |
|
5
|
To verify that the information has been shared, return to the Replication Site 1’s subnet table and view the results.
|
 |
Traffic originating from a replication site is sent to the Silver Peak appliance, which is the default gateway. Once traffic reaches the appliance, it uses the subnet table information to route traffic into the correct tunnel, thereby overcoming the need for inbound (WAN-side) redirects on the router.
In this example, the branches can only access the Internet via the Hub appliance. We direct and optimize Internet traffic between the branch offices and the hub site.
 |
|
•
|
All out-of-path traffic is redirected using VRRP (Virtual Router Redundancy Protocol), WCCP (Web Cache Communication Protocol), or PBR (Policy-Based Routing).
|
First, configure the subnet table on the Hub appliance, then configure the subnet table on branch-2, and finally configure the subnet table on branch-1.
|
1
|
 |
|
a
|
Select Use shared subnet information.
|
|
b
|
The subnet 10.1.166.0/24 is not in the same subnet as the Hub appliance. Therefore, you must manually add it to the appliance’s subnet table.
|
|
•
|
Select Is Local, to indicate that the subnet is local to this site.
|
|
•
|
Select Advertise to Peers.
|
 |
|
c
|
Click Apply.
|
Now, configure the appliance, branch-2.
|
3
|
From the menu, access branch-2’s Configuration - Subnets page. The Configuration - Subnets page appears.
|
 |
Notice that Hub’s shared information appears as an entry.
|
a
|
Select Use shared subnet information.
|
|
b
|
Select Automatically include local subnets. This ensures that the appliance automatically learns its own subnet, 10.1.155.0/24.
|
|
c
|
Click Apply. The subnet table updates.
|
 |
Next, configure the appliance, branch-1.
|
5
|
From the menu, access branch-1’s Configuration - Subnets page. The Configuration - Subnets page appears.
|
 |
Notice that branch-1 has already learned subnets from the configurations performed on Hub and branch-2.
|
a
|
Select Use shared subnet information.
|
|
b
|
Select Automatically include local subnets. This ensures that the appliance automatically learns its own subnets, 10.1.237.0/24 and 10.10.237.0/24.
|
|
c
|
Click Apply. The subnet table updates.
|
 |
You can refer to Hub’s subnet table to verify that all the appropriate entries are there.
 |
Next, separately test the connections and use branch-2’s Monitoring - Current Flows page to verify that traffic from client A, 10.1.155.85, in Branch Office 2, is being optimized correctly as it flows:
|
•
|
|
•
|
|
6
|
To verify communication between the branches, access branch-2. From the Monitoring menu, select Current Flows. One by one, the results were as follows:
|
|
•
|
 |
|
•
|
 |
|
•
|
from client A, 10.1.155.85, in Branch Office 2, to client D, 128.242.109.85, in the Internet
Client D has no configured or advertised subnet(s). |
 |
|
•
|
branch-2 subnet sharing failed because there is no subnet entry match for client D.
|
|
•
|
Without a known subnet, the Silver Peak software determines the correct tunnel by using other optimization strategies, such as TCP-based auto-opt and IP-based auto-opt. These failed because of the lack of WAN-side redirection at the Hub site for traffic intended for client D.
|
The end result is that the traffic goes pass-through.
|
7
|
To overcome these issues and to successfully optimize internet traffic, create a “wild card” (0.0.0.0/0) entry on Hub’s subnet table, and give it the highest value metric so that it’s accessed last.
|
 |
Note 
Exercise caution before configuring a wild card (0.0.0.0/0) subnet entry on the hub. This will cause the branches to steer traffic that is destined to unknown (that is, not in the subnet tables) subnets to the hub. Also, if you add a new network to a site, make sure to add that subnet to the appropriate appliance as a local subnet.
Exercise caution before configuring a wild card (0.0.0.0/0) subnet entry on the hub. This will cause the branches to steer traffic that is destined to unknown (that is, not in the subnet tables) subnets to the hub. Also, if you add a new network to a site, make sure to add that subnet to the appropriate appliance as a local subnet.|
8
|
Go to branch-2’s subnet table, and notice that it has learned the subnet.
|
 |
|
9
|
Go to branch-2’s Monitoring - Current Flows table to see that traffic from A to D is now being optimized between branch-2 and Hub.
|
 |
This demonstrates how subnet sharing can be used to auto-optimize internet traffic to and from a branch office, where the branch office’s only access to the internet is via the hub appliance.
In this example, Site A deploys two appliances out-of-path (Router mode), and Site B deploys a single appliance in-line (Bridge mode).
The peered appliances at Site A use the Virtual Router Redundancy Protocol (VRRP) to create and share a common IP address, called the Virtual IP (VIP) address (not shown here). Configuring for high availability assigns one appliance a higher priority than the other, thereby making it the master appliance, and the other, the backup.
 |
|
•
|
For each appliance in Site A, configure VRRP by using the Configuration > VRRP menu. Be sure to give your Master appliance the greater Priority value (for example, 130 for the Master, and 128 for the Backup).
|
|
•
|
Configure Site A’s WAN router to send traffic to the VRRP IP address.
|
|
1
|
 |
|
a
|
Select Use shared subnet information.
|
|
b
|
The subnets 10.1.166.0/24 and 10.1.167.0/24 are not in the same subnet as the appliance. Therefore, you must manually add them to the appliance’s subnet table.
|
|
•
|
Since this is the Master appliance, change the Metric to a smaller number to give its subnets precedence. Here, we’ve changed it from the default, 50, to 10.
|
|
•
|
Select Is Local, to indicate that the subnet is local to this site.
|
|
•
|
Select Advertise to Peers.
|
 |
|
c
|
Click Apply.
|
|
3
|
From the menu, access vrrp1’s Configuration - Subnets page. The empty Configuration - Subnets page appears.
|
 |
|
a
|
Select Use shared subnet information.
|
|
b
|
The subnets 10.1.166.0/24 and 10.1.167.0/24 are not in the same subnet as vrrp1. Therefore, you must manually add them to the appliance’s subnet table.
|
|
•
|
Since this is the Backup appliance, accept the default Metric value of 50. Since you changed vrrp2’s Metric to 10, vrrp2 has priority. With subnet metrics, the lower the number, the higher the priority.
|
|
•
|
Select Is Local, to indicate that the subnet is local to this site.
|
|
•
|
Select Advertise to Peers.
|
 |
|
c
|
Click Apply. The table updates.
|
Now, we’ll configure Site B’s appliance.
|
5
|
From the menu, access Site B’s appliance’s Configuration - Subnets page. The empty Configuration - Subnets page appears.
|
|
a
|
|
b
|
Select Automatically include local subnets. This assures that the appliance, 10.1.155.3, automatically adds the subnet (10.1.155.0/24) that’s local to its interface.
|
|
c
|
Because it’s not in the same subnet as the appliance, you must manually add 10.10.155.0/24 to the appliance’s subnet table.
|
|
•
|
Select Is Local, to indicate that the subnet is local to this site.
|
|
•
|
Select Advertise to Peers.
|
 |
|
d
|
Click Apply.
|
Site B’s subnet table now also includes those subnets advertised by the peers in Site A.
 |
If you now examine the subnet tables for vrrp2 and vrrp1, you’ll see that both have learned Site B’s subnets.
 |
|
7
|
To verify that traffic is flowing from Site B to the Master appliance, vrrp2, at Site A, go to Site B’s menus and access Monitoring > Current Flows.
|
 |
In the event that the Master appliance goes down, the first thing to verify is whether the Backup, vrrp1, has successfully become the Master appliance.
|
8
|
 |
When the original Master goes down, its learned entries disappear from Site B’s subnet table.
 |
|
9
|
View Site B’s Monitoring - Current Flows page to verify that the traffic is now flowing from host 10.1.155.85 to 10.1.166.85 through tunnel, 2-vrrp1.
|
 |
The process is now complete. This demonstrates how VRRP subnet sharing can be used in auto-optimization mode to correctly steer traffic to the Master appliance.
For Active/Active style deployments, we need to configure two VRRP groups/instances.
|
•
|
|
•
|
In this deployment, Silver Peak recommends that you set up flow redirection between appliances. This helps avoid traffic not being optimized due to asymmetry.
|
 |
All of the above deployments demonstrate how subnet sharing effectively helps the user achieve his goal for that specific topology and use case.
Some of the examples, like VRRP, show how to integrate subnet sharing with other features. Subnet sharing is not limited to these deployments. You can apply it to other different deployments, based on requirements and topology.
