ComBrio's Virtual Service Infrastructure 2.0 (Beta)

To begin testing, I plugged the VSIa (VSI administrator), the optional VSIe (VSI enterprise), the VSIm (VSI manager) and a VSIg (VSI gateway) into the network and configured them with IP addresses and domain information. I also entered the devices that would be accessed under the VSI umbrella. These devices are configured into domains--single devices or groups of devices managed by VSI. Then I created Internet-style VPNs to let preauthorized third-party support personnel originate service requests over the Internet and access domains inside the firewall.

After configuration, you must implement a VSIg and the VSIe at the enterprise end. But don't panic, this isn't complicated--VSI uses an appliance-based architecture and will fit right into your enterprise (see screen at right). Mindful that the service provider will typically implement the VSIa and VSIm at its NOC (network operations center), I set up those devices on a network separate from the VSIg and VSIe.The VSIa came on an IBM eServer xSeries 305 with 3.2-GHz dual-processing Intel Pentium 4 processors, 4,096 MB of RAM and two network interfaces. That's a lot of processing and memory capability. Unfortunately, I couldn't see how much work it was doing, as I didn't get CLI (command-line interface) access to the Linux performance metrics.

Most of the processing power is for managing the open VPNs--DCs (directed circuits), in VSI parlance--with the VSIm. Driven by vmlinux with three network interfaces, the VSIm came on a VSIg model 400 (VSI gateway) box the size of a long patio brick.

I implemented the VSIe and another VSIg on an "enterprise" network. The VSIe also came on an IBM eServer, but it had only a single Intel Pentium 4 (2.4-GHz) with 1,536 MB of RAM. Except for the VSIm, which doesn't need a browser, all the devices sported an Apache Tomcat Web server with agnostic browser support.

The VSIm works hand in hand with the VSIa to manage DCs residing between the NOC technicians and the enterprise hosts. To establish DCs, the VSIa by default uses Port 65534, which at a minimum must be open to both inbound and outbound traffic at the NOC.

The VSIa applies policy-based rules letting support personnel access remote devices over a DC through the VSIg in the enterprise. The VSIg bridges network connections to a virtual network containing devices under support contracts. Operational DCs use SSL for communication (Port 443) and IKE (Internet Key Exchange) default UDP Port 500. If NAT (network address translation) is involved, they will also use UDP Port 4500 for port floating. These ports should be open to inbound and outbound traffic, both in the enterprise and at the supporting NOC.

Keys to the Castle

The optional VSIe lets you authorize connections between service provider support personnel and supported devices in the enterprise. If you choose not to use it, your service provider will have access to all supported devices on your network without having to be approved--not a great idea unless you totally trust everyone at the service provider's end.

Although the controls were not as finely tuned as I would have liked, they gave me options ranging from "take no action" to "deny," "allow" or "always allow" a DC request from a remote provider. I wish I could have allowed DCs for just a limited time, to avoid having to monitor the system constantly.Setting up a VSIg on the enterprise network was as easy as plugging in a null modem cable and running a script. There's no command-line access on the VSIg--or, for that matter, on any of the appliances--so what you see from a Web browser is what you get. Thankfully, I got most of what I wanted.

I set up the VSIg on the enterprise network to interface the LAN and bridge to a VPN (10.0.15.0). The configuration script includes the IP information of the VSIa and domain information.

Resources requiring support are created on the VSIg through a Web browser interface. In the Web interface, I created objects corresponding to network resources, ranging from a DNS and e-mail server to an FTP and IP-PBX server. Populating the administrative pages on both the VSIa and VSIe, the objects each received a virtual address associated with the 10.0.15.0 network.

I created a static route on the network to access resources on the 10.0.15.0 VPN through the VSIa's public interface, which routes to the private network. The VSIa can also act as a DNS server so you don't have to recall the virtual private addresses. In addition, the VSIa has a number of tools for service providers to configure SNMP trap receivers, SMTP servers and e-mail alerts to monitor remote hosts.

Accessing the Virtual NetUpon creating the static route, I put on my service provider technician hat and brought up a Web browser interface to the VSIa. I successfully tested this from both Internet Explorer 6 and Netscape 7.0.

My request to access a remote host required VSIe approval. To start the approval process, you click on domains, then on a domain resource such as an application or file server. Clicking on a link displays all pending requests. However, there's no way to set up e-mail or pager alerts if there are requests pending, so you must check the list regularly.

Acting as the VSIa-authenticated technician, I could access the remote server by its virtual address upon receiving the VSIe's stamp of approval. Although there was no limit to my access, such as by protocol or time, the DC process was fully controlled by the VSIe.

From the VSIe interface, I could monitor all open DCs, review the limited policies on all DCs (deny, allow, always allow), and obtain a complete history log of all DCs. However, the reports lacked the originating IP of the technician. I obtained this information by digging into the server logs, but I'd like to see it provided up front.

I was pleased to see a fail-safe switch option--a necessary emergency tool. One click and I could cut off all open DCs operating on the enterprise network. Try that with your firewall!VSI's $35,000 starting price is a bit of a shocker, but the cost will be divided between the enterprise and its managed service providers. And the configuration will support up to 20,000 total devices, 200 concurrent DCs and 100 concurrent users, which should turn some heads. But remember that DCs do not have protocol and time limits in this release, and VSI lacks automation to alert enterprise personnel of incoming service requests.

Sean Doherty is a senior technology editor and lawyer based at our Syracuse University Real-World Labs®. A former project manager and IT engineer at Syracuse University, he helped develop centrally supported applications and storage systems. Write to him at [email protected].