Table Of Contents

Creating a simple site-to-site network

Install type: site-to-site VPN basics

Scenario 1a: Modeling a simple two-site network

Creating sites

Creating per-site devices and DSCs

Setting up business policies

Building business policies among multiple sites

Troubleshooting this simple network

Scenario 1b: Moving servers from site to site

Scenario 1c: Creating a business access policy

Creating a simple site-to-site network

---

This chapter introduces you to using the OverDrive Command Center:

•Install type: site-to-site VPN basics

•Scenario 1a: Modeling a simple two-site network

•Scenario 1b: Moving servers from site to site

•Scenario 1c: Creating a business access policy

At this point, your OverDrive installation should have been completed, and the command center installed, as explained in Cisco OverDrive 4.0 Installation Guide. You should have read the chapter in Introducing Cisco OverDrive 4.0 that describes concepts central to OverDrive, plus the main views and functions of the command center.

Install type: site-to-site VPN basics

Site-to-site VPNs are installations where each given site involves a router, a set of ports and protocols (formerly called applications), what OverDrive calls a business policy, and other local resources such as subnets, servers, and workstations that are assigned to the policy or policies.

In a nutshell, OverDrive allows you to define a policy that describes a business need, essentially that some resources need to communicate with some server, and then it builds all of the connections to support that. In the case of site-to-site connections, these include VPN, routing, and access control list configurations.

Scenario 1a: Modeling a simple two-site network

This section steps you through modeling a very simple network with two simple sites. This is mostly to introduce you to some common, general procedures, so you can become acquainted with the interface.

In summary, Scenario 1a exercises the following steps:

1. Create a couple of sites—"Creating sites" section

2. Create a resource at each site—"Setting up business policies" section

3. Create a business policy and add the resources into this—Step 2 of "Setting up business policies" section

Creating sites

To set up these basically one-time objects:

1. Click the Browse Layout icon on the right side of the icon toolbar. (You can use any of these layouts, but this guide generally uses the browse layout.)

2. Create a domain and enter a tooltip comment for it.

a. Highlight the root domain, or a parent domain in which you want to create a domain, then click the domain icon in the toolbar.

b. Enter a new domain name in the pre-filled text field, so that the Domain Name field reads Domain: North East.

c. Enter a comment to be displayed when someone hovers over the new domain in the policy view.

d. Click Submit.

Why create a domain? Domains are used for delegating control, but also as a point to delineate network entities like a managed address space, or subdomains for VLANs.

3. Create two sites, named Site: Boston and Site: New York:

a. Highlight the domain and choose New Site.

b. Enter the site name.

c. Click Submit.

d. Repeat Steps a-c for the second site.

---

Note Ignore the alerts that say the site has no DSC. The next procedure addresses them.

---

Creating per-site devices and DSCs

For each site, define the DSC and devices in the Devices tab:

1. Highlight each site in turn and choose Edit.

2. Under each site's Config tab:

a. For the DSC, enter a name that is unique within the OverDrive managed network. A good practice is to use a prefix for your organization, followed by a unique ID that is helpful to you. For our example, enter DSC-HR-NewYork-01 and DSC-HR-Boston-01.

---

Note If you are an administrator of a subdomain, the name you choose must be unique among all the networks managed by OverDrive in the ROOT domain, no matter where they are in the tree.

---

b. Enter a password and confirmation.

c. Make a note of both the password and the DSC name as you will need them later when you configure the DSC appliance.

3. Under each site's Device tab (for more details, see the"Specifying the site DSC and its devices" section on page A-3):

a. Choose the type of actual hardware role in the drop-down list labeled Add, at the bottom of the panel: switch (access, distribution, or aggregation), VM manager, NAT device, or router. (See the Glossary for definitions of these types of devices.)

b. Fill in the name, IP address, IPsec properties, and CLI and SNMP credentials, depending on the particular switch or router.

---

Note For now, just create a router for each site. Name it NewYork Router and Boston Router as appropriate, with username admin and password 123456, IP address of 10.0.0.1, tunnel IP addresses of 10.0.0.2, and tunnel interface of f0.

---

Name devices to help you and other administrators distinguish them. You can tell the difference between the agent and router/switches by recognizing the icons used for each, which are as follows:

Object	Icon	Object	Icon
Access switch		NAT device
Aggregation switch		Router
Distribution switch		VM manager
DSC

c. Enter a useful comment, so you and other admins will know specifically which router or switch this is.

d. Click Submit.

---

Note You may get a warning that the tunnel interface must conform to the following patterns: g0, g0/0, g/0/0/0, where g can be letters e, f, and g; and 0 can be any digits 0-9).

---

Setting up business policies

Once you have defined the sites and its devices, you can begin to use policies to describe connections between resources at each site. Where you create sites, per-site devices, and DSCs basically once or seldom, your business policies may proliferate or change fairly often.

1. For each site, create local resources by specifying, in this example, the desktop and laptop:

a. Right-click the site and choose New Local Resource.

b. Specify the desktop icon (there is no icon for laptops) and name them Local Resource: SiteName Desktop and Local Resource: SiteName Laptop.

c. Give each desktop and laptop an IP address of 10.0.0.3 and 10.0.0.4.

---

Note These need to be separate local resources, unless you specify a subnet that includes both IP addresses.

---

d. Right-click each site in turn and select Edit. Note that in the Participating Resources tab, each site's desktop and laptop are listed in its Site Resources panel.

2. Specify communications ports and protocols to use between sites in the domain:

a. Right-click the North East domain and choose New Ports & Protocols.

b. Name this Ports & Protocols: Outposts Domain.

c. Click Add and select ANY from the Predefined list.

d. Click Submit and look for ANY under the Protocols column, and an asterisk (*) under the Ports column.

e. Click Submit.

3. Create a business policy that uses the resources and protocol we have just set up:

a. Right-click the North East domain and choose New Business Policy.

b. Name it Business Policy: Let New York and Boston sites talk to each other.

c. In the Ports & Policies tab, highlight what we created in Step 2 and click Add to move it into the Selected Ports & Protocols panel.

d. In the Resources tab, highlight the four computers (local resources) listed in the Available Resources panel, and click Add to move them into the Participating Resources panel.

e. Click Submit.

Now, the NSVE begins its work. It determines which sites are affected by the new policy. For each of these, it constructs a set of abstract directives to tell each site's DSC which network services and connections it needs to implement. (Network services are http, ftp, and so on. See the "Allowing ports and protocols for services" section on page A-6.)

Depending on which services are enabled at the sites, when the DSCs receive these instructions, they will begin to convert them into device-specific instructions and configure the devices accordingly.

Building business policies among multiple sites

You can permit users access to the network and have OverDrive write rules that permit them to access resources that have been defined for them. See the "Creating network identities" section on page 2-6.

In most cases it is sufficient to create business policies that enroll the users' assigned VLANs rather than their individual network IDs.

---

Note When when you enroll an LDAP group in a business policy, because OverDrive processes each user login as the user connects, the resulting rules will be written per-user host IP address and not per-VLAN. This in turn results in a large number of ACLs.

---

Troubleshooting this simple network

In the network status view, you should see the two DSCs and their network routers come up.

---

Note There are no network users in this network, and you would need network policies to create a connection between the two sites.

---

Figure 1-1 shows that both site routers seem to be working, but the DSCs have a warning flag (the exclamation mark in a yellow triangle). In this case, there is a particular problem with them, but the fact that the routers are up shows the DSCs are communicating with them and with the NSVE.

Figure 1-1 Unconnected routers, switches, or DSCs

Notice that the alert window reports the reason for this:

To diagnose similar problems, follow these steps:

1. For routers and switches that have device down alerts, and if their DSCs are not accessible, as in the example below, confirm that the DSC processes are running on the DSC appliance:

Figure 1-2 Router with non-available DSC

2. For non-DSCs, try checking the IP address of the device, and then re-entering the CLI and SNMP credentials.

3. In the domain navigator, edit each site to make sure that your configuration specifies that the site's DSC has been assigned a device.

4. Check the device type, name, and so on.

Scenario 1b: Moving servers from site to site

This section explains what happens if you move a server from one site to another. Consider moving one from, say, San Francisco to Boston, and that you can move a rack mounted or even a VM-based server very quickly.

Without OverDrive, the networking infrastructure built to support users accessing the machine are not automatically going to be adjusted. Network engineers would have to change everyone's access.

With OverDrive, a high-level business policy drives the network. The policy, in this case, has already stated that all salesforce workstations need access to a CRM serve.

The policy already also specifies a network topology, in this case hub-and-spoke with the server at the hub.

With OverDrive, the change is simple: you don't need to edit the policy, just change the server's site and IP address.

The site drop-down list that lets you change the location of the server has a cheat-sheet at the bottom that tells which IP addresses to use for which site.

After you modify the site and address to match Boston's, and click Submit, the NSVE sends directives to the DSCs and devices to keep the business policy true. Within seconds, the connections change from a hub at San Francisco to a hub at Boston. In the following figure, the NSVE is already talking to each of the devices involved in Chicago and Nashville. The Boston-to-Nashville connection has been expanded to show the DSCs at those sites, and they each report traffic.

In a couple minutes, all the connections turn green. In the meantime, OverDrive displays any relevant status alerts, for example, whether the CRM server has confirmed transport connections.

---

Note Alerts and red flags do not mean something bad has happened. They indicate states without reported traffic. See Table 7-1 on page 7-3.

---

Once traffic starts flowing between the hub and each spoke, the connections all go green and the alerts go away. The logs will verify that all the sites have made the changes.

Scenario 1c: Creating a business access policy

This section leads you through modeling and verifying a business access policy that lets you provide access to a CRM server for a group of users in a sales department.

The following steps summarize the procedure:

1. Inspect the ports and protocols that are available to you in your domain (click the domain and check the summary view for ftp, http, and so on).

2. If there is not the protocol that you need to access the CRM server, create a new one and fill in TCP and the ports that are needed for access (see "Allowing ports and protocols for services" on page 86).

3. Click the create business policy icon.

4. Select the Sales VLAN and the CRM server.

5. Choose a hub and spoke configuration with the CRM server as the hub.

6. Choose the ports and protocols for accessing the CRM server.

7. Have a user connect to a managed switch and try to access the CRM server.

OverDrive will have created the Sales VLAN defined in the "Scenario 2a: creating VLANs for sites" section on page 2-7, because the user is in the group chosen in "Scenario 2b: creating a network ID and access policy" section on page 3-7, and associated with the user in the first section of Scenario 2b.

Overdrive will also have created access rules to permit access to the ports and protocols for the CRM server on the VLAN.