how to use subnet sharing in common deployments

June 2014 of 20

SOLUTION SHEET

2860 De La Cruz Blvd., Suite 100 Santa Clara, CA 95050 408.935.1800 www.silver-peak.com

How to Use Subnet Sharing in Common Deployments

This document introduces you to the components of the subnet table and illustrates how to use subnet sharing in the following deployments:

Velocity Deployment See page 3.

Hub and Branch Offices Deployment See page 6.

VRRP (Master/Backup) with Subnet Sharing See page 14.

VRRP (Master/Master) with Subnet Sharing See page 20.

What is subnet sharing?

Subnet sharing is one of the three strategies that Silver Peak uses to auto-optimize all IP traffic, automatically directing flows to the appropriate tunnel. Auto-optimization strategies reduce the need to create explicit route map entries to optimize traffic. The other two strategies are TCP-based auto-opt and IP-based auto-opt.

How is subnet sharing implemented?

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.

When would you need to use a Route Policy?

Subnet sharing takes care of optimizing IP traffic based on the destination IP address alone.

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:

• sent pass-through (shaped or unshaped)

• dropped

• configured for a specific high-availability deployment

• routed based on application, ports, VLAN, DSCP, or ACL (Access Control List)

June 2014 How to Use Subnet Sharing in Common Deployments of 20

SOLUTION SHEET

What are the components of the subnet table?

This section provides an introduction to the components of Appliance Manager’s Configuration - Subnets page.

see definitions belowglobal tags

The following are global tags, which apply at a system level:

• 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) for 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.

These fields apply to individual subnets:

Column Name Definition/Content

Subnet/Mask Specifies the actual subnet to be shared/advertised so it can be learned by a peer appliance.

Metric 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.

Is Local Specifies if the subnet is local to this site.

To keep a manually added subnet in the table but make it unavailable for auto-optimization, deselect this option.

Advertise to Peers Selecting this shares the subnet information with peers. Peers then learn it.

To add a subnet to the table without divulging it to peers, yet, deselect this option.

Type [of subnet]

Learned from Peer Identifies the peer appliance that advertised this subnet information.

• Auto (added by system) Automatically added subnets of interfaces on this appliance

• Added by user Manually added/configured subnets for this appliance

• Learned from peer Subnets added as a result of exchanging information with peer appliances


SOLUTION SHEET

Velocity Deployment

The most obvious and elegant deployment for 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). All they need to do is put the Silver Peak appliance in the same subnet and, 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.

Figure 1

To configure the subnets

Configure the subnet table at Replication Site 1, and then configure the subnet table at Replication Site 2.

1 From the menu, access Configuration > Subnets. The empty Configuration - Subnets page appears.

Repl

icat

ion

Site

1


SOLUTION SHEET

2 Do the following:

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.

Repl

icat

ion

Site

1

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.

Repl

icat

ion

Site

2


SOLUTION SHEET

4 Do the following:


b Select Automatically include local subnets.

c Click Apply. The appliance automatically adds its own subnet and shares the information with its peers.

Repl

icat

ion

Site

2

5 To verify that the information has been shared, return to the Replication Site 1’s subnet table and view the results.

Repl

icat

ion

Site

1

The process is now complete.

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 WAN-side redirects on the router.

This demonstrates how to set up subnet sharing when using a Velocity deployment for replication.


SOLUTION SHEET

Hub and Branch Offices Deployment

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.

Figure 2

This example assumes the following facts before configuring the subnet tables:

• The tunnels already exist between hub and branches, and also between branches.

• All out-of-path traffic is redirected using VRRP (Virtual Router Redundancy Protocol), WCCP (Web Cache Communication Protocol), or PBR (Policy-Based Routing).


SOLUTION SHEET


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.


Hub

2 Do the following:


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.

Hub

c Click Apply.


SOLUTION SHEET

Now, configure the appliance, branch-2.

3 From the menu, access branch-2’s Configuration - Subnets page. The Configuration - Subnets page appears. br

anch

-2

Notice that Hub’s shared information appears as an entry.

4 Do the following:


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.

bran

ch-2

Next, configure the appliance, branch-1.


SOLUTION SHEET

5 From the menu, access branch-1’s Configuration - Subnets page. The Configuration - Subnets page appears. br

anch

-1

Notice that branch-1 has already learned subnets from the configurations performed on Hub and branch-2.

Do the following:


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.

Because of VLAN 10 (see diagram), the appliance is able to learn this subnet automatically.

bran

ch-1


SOLUTION SHEET

You can refer to Hub’s subnet table to verify that all the appropriate entries are there. H

ub

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:

• to client B, 10.1.237.85, in Branch Office 1, and

• to client C, 10.1.166.85, in the Main Office.

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 B, 10.1.237.85, in Branch Office 1

The tunnel from branch-2 to branch-1 is 2-branch-1, and it’s traffic is being optimized successfully.

bran

ch-2


SOLUTION SHEET

• from client A, 10.1.155.85, in Branch Office 2, to client C, 10.1.166.85, in the Main Office

The tunnel from branch-2 to Hub is 2-hub, and it’s traffic is being optimized successfully.

bran

ch-2

• 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).

An ALERT is visible when traffic is not being optimized successfully.

This host lives in the internet.

bran

ch-2

The traffic has been sent through pass-through, that is, unoptimized:

• 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.


SOLUTION SHEET

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.

Since this is for traffic that’s not local to Hub, ensure that it’s deselected.

Hub

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.

8 Go to branch-2’s subnet table, and notice that it has learned the subnet.

If Internet subnet is not among the previous entries, it will always go to Hub.

bran

ch-2


SOLUTION SHEET

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.

If 128.242.109.0/24 is in the Internet, then branch-2’s internet access is now via Hub.

This assumes that the firewall translates the internal IP address to a public address.

Now the bidirectional view ...

A D

Traffic is flowing in both directions.

bran

ch-2

bran

ch-2

The process is now complete.

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.


SOLUTION SHEET

VRRP (Master/Backup) with Subnet Sharing

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.

Figure 3

Before configuring the subnet tables:

• The tunnels must already exist.

• 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.


First, configure Site A’s Master appliance (vrrp2), and then the Backup appliance (vrrp1).


Mas

ter [vrrp2]


SOLUTION SHEET

2 Do the following:


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.



Lower number = higher priority

Mas

ter [

vrrp2]

c Click Apply.

Now, configure Site A’s Backup appliance, vrrp1.

3 From the menu, access vrrp1’s Configuration - Subnets page. The empty Configuration - Subnets page appears.

Back

up [v

rrp1

]


SOLUTION SHEET

4 Do the following:


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.



Back

up [v

rrp1

]

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.

6 Do the following:


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.



SOLUTION SHEET


Site

B

d Click Apply.

Site B’s subnet table now also includes those subnets advertised by the peers in Site A.

vrrp2, the Master applianceMaster

Backup

same subnet (VRRP)

Site

B


SOLUTION SHEET

If you now examine the subnet tables for vrrp2 and vrrp1, you’ll see that both have learned Site B’s subnets.

Mas

ter [

vrrp2]

Back

up [v

rrp1

]

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.

This shows that the tunnel carrying traffic is the one that goes to vrrp2.

Site

B


SOLUTION SHEET

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 In vrrp1’s user interface, access the Configuration - VRRP page and verify the state.

Back

up [v

rrp1

]

When the original Master goes down, its learned entries disappear from Site B’s subnet table.

vrrp1, the new master

Site

B

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.

Site

B

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.


SOLUTION SHEET

VRRP (Master/Master) with Subnet Sharing

For Active/Active style deployments, we need to configure two VRRP groups/instances.

• Each VRRP group/instance will look similar to the one in Active-Backup setup (shown in Figure 3).

• Only one VRRP group/instance is active on each appliance (shown in Figure 4).

• In this deployment, Silver Peak recommends that you set up flow redirection between appliances. This helps avoid traffic not being optimized due to asymmetry.

Figure 4

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.

how to use subnet sharing in common deployments

Documents