Network Computingwww.networkcomputing.com

Managing a Remote Site Network

April 10, 2000
By John Shireley

Print this entire chapter Browse this chapter by content Managing Individual Remote Users Mobilizing the Troops Plan for the Worst Application Usage and Quality of Service Local Calling Area or Long Distance Establish How Much Bandwidth is Appropriate Choosing a RAS That¹s Right for You Helpdesk Support Outsourcing Security Concerns Managing a Remote Site Network Bandwidth Considerations Disaster Recovery

There’s another thing to be aware of when trying to keep the infrastructure invisible and seamless to your users. A workstation or other host on a remote network really doesn’t know or care that it’s talking to another host on another subnet in terms of infrastructure or individual host configuration. Your connecting routers act as gateways and handle all of that. Security is still a large concern of course, but as long as you apply the same policies to your remote network that you do to your local one, and the transport mechanisms between them, you’ll be fine.

If the remote network isn’t attached to your central site directly via a point-to-point circuit and you’re using the Internet to access each other, security becomes a bigger concern. You need to consider firewall and VPN technologies. Many dedicated firewalls now offer integrated VPN support. The easiest way to address this issue would be to configure a pair of dedicated units to talk to each other directly. This remains invisible to the desktop clients on either side (or servers), and should ease most of your security concerns. Since the secure traffic is tunneled from end-to-end by the hardware, there is nothing further to configure at the desktop level which greatly decreases your support and management burden.

Another alternative to consider for connecting smaller client networks via the Internet if you need to be more budget-conscious is to install them with a dial-on-demand setup. This eliminates the cost of a dedicated circuit connection on their side, which most ISPs charge higher fees for. Using ISDN access as an example, you only need to purchase a single dial-up ISDN account (telco fees remain the same, of course) from the service provider. Here’s how it works: You install a router that supports a special feature that allows it to dial in and share the connection with the rest of the network by acting as the gateway. When no traffic is present for a predefined time period, the unit closes the connection. When new traffic is sensed, it calls the ISP back and re-establishes the connection.

There are several caveats here, however. This particular setup will only work when you don’t need to access their network for management purposes during off-hours; if no one is there using it, it’s down and you can’t access it (unless you set up "camping," but most ISPs frown on this since it wastes their resources). Network-to-network security can be a major hassle if you can’t get a static IP address for your far side. Because the router is constantly redialing the connection, it’s usually getting a different IP address assigned. You will not be able to add it to any access-control lists on your side. In general, it’s an inexpensive way to have a remote network reach you via the Internet, but there are quite a few trade-offs for you to consider.

Bandwidth Considerations

Bandwidth considerations can be quite intimidating. One of your most difficult challenges will be determining how much you’re going to need between locations, which of course is determined by application type and usage patterns. This is an area where you can’t allocate enough money. To be the most cost-effective, you’ll need to utilize techniques that allow you to maximize your available resources. Methods for calculating your bandwidth needs greatly depend on your particular application.

When determining the right formula, first address what is the specific type of data (large files or small files) and the application delivery method (e-mail or database access, for example), as well as your performance expectations. After you’ve determined the amount of bandwidth overhead needed for each application and how many users will require access, you can begin to formulate what type of connection speed will be necessary by compounding these elements using a simple linear equation. Bandwidth needed will be the variable you’re solving for, and you should multiply users by applications by data overhead (and latency requirements) of each application. There are many resources already available to you, but make sure you’re examining the right parameters to meet your unique needs. No one particular bandwidth calculator will be the precise one, so try several to ensure that you’re getting the whole picture.

Even after you've deployed as much bandwidth as possible, you may still run into some latency or other speed issues, especially as your users increase their traffic on your circuit. If you suddenly find your T1 feeling more like a rusty, old modem connection, explore the possible reasons why, and don't limit yourself to known applications. In fact, the applications that you planned for most likely are not causing the slow-down problems. Streaming video from auction sites within the accounting department is more likely the culprit. Perform a site visit and walk around to see what people are doing. You'd be surprised at just how brazen some folks are with their Web browsers.

Develop fair usage policies with management that are enforceable. Consider purchasing some type of traffic-shaping or limiting device, such as a firewall that is able to filter based on content. That will return your circuit back to normal.

If you've eliminated extraneous traffic as the culprit, it's time to use the packet sniffers and traffic analyzers. These tools should be in your arsenal: They are extremely helpful in determining exactly what is happening on your network. If you find your circuit is getting clobbered by legitimate traffic, it's time to think about load-balancing across multiple circuits, or upgrading to a larger one.

Disaster Recovery

Finally, you should create a failover or disaster-recovery solution for your remote connection. Since you’re connecting your remote network with your central one, there are probably important business processes occurring every day that can not tolerate a great deal of downtime. One very good method of providing for recovery from a failed circuit is to have two in place instead of one. One primary circuit, which is going to be your fattest pipe, and one secondary circuit for emergency use. In addition to cost savings, it’s better to use a separate type of circuit as an auxiliary one. It is less likely to be affected by whatever brought the first circuit down. Do make sure that your fail-over circuit(s) can meet the bare minimum of your transfer and latency needs however; it's not going to do you any good to bring a connection back up that no one can use.

As you can see managing a remote and mobile workforce requires a great deal of forethought. It is not enough to merely hang a remote-access server off your Windows NT server. You must carefully examine your security needs, user requirements, environmental constraints, network capabilities, and support capacity long before you divvy out that first dial-up number. But through careful planning, you can bring your distant workers back into the fold.