Switching to a virtual private network saved my previous employer, a global company, £275,000 a year. We were faced with some technical issues and most were solved. The network gives a lot more bandwidth than our old wide area network.
We needed to save money: Frame Relay was costing us £410,000 a year to link 20 sites worldwide. Half the end-points were in Europe, connected to a London hub with a single costly transatlantic link to the US headquarters.
Manufacturing locations in Europe required total reliability as all their transactions were over the Wan to an Oracle server in the US. We also had a number of small sales offices where the cost of a full-blown Frame Relay port was denting profitability. All users needed to connect to the single Oracle server in the US.
I set the strategy and pioneered the implementation method in Europe before we rolled it out to the US and Japan. I had development support from UK security company Integralis. We set up internet connections at each plant and office.
Since public internet is not dependable, we had to build in resilience at key manufacturing plants. For these we used dual connections with dual firewalls, one ADSL connection backing up a tie-line ISP connection.
We used a mix of providers to ensure independence of supply - if one ISP’s network went down we had failover to the other. We installed dual Checkpoint NG firewalls running on Nokia hardware. These used Virtual Router Redundancy Protocol to bring up the back-up firewall in milliseconds if the primary firewall should go down. Smaller offices used a single ADSL connection with the same firewall hardware and software.
We also brought management of the network in-house.
However, if you are considering replacing a Frame Relay network with ADSL you should be aware of some of the problems you may experience.
For example, a typical ADSL connection is 512kbps up/256kbps down or 1mbps/256kbps. We based our sizing on comparison with the pre-existing Frame Relay connections. Thus assuming that a 1mbps/256kbps 1:1 ADSL connection would outperform a 256kbps Frame Relay connection.
Sounds fair doesn’t it? But the results were not what we expected. The symptom was that the VPN link between sites could occasionally become critically congested, leading to failure of e-mail and Active Directory services, for instance.
A clue is in the ping time response. When congestion occurs, a 30 millisecond round-trip time rises to around a second or more.
What is going on? It boils down to the different ways that Frame Relay routers and ADSL routers deal with congestion. Frame Relay routers are programmed to discard frames, so that the surviving traffic is never delayed.
E-mail services can survive a percentage of dropped frames, they just ask for re-transmission. However, ADSL routers queue up the packets and when the traffic through an ADSL router gets congested, a packet can take a second or more to traverse the router, and normal services start to fail.
Overall we completed a very successful project. As well as cutting cost for the operating companies, it provided a first-class security infrastructure supporting home and travelling staff, better bandwidth, and failover resilience for our larger plants.
Another improvement was that the VPN was fully meshed with all points directly connected to the US Oracle server in a single hop. I can see this being a very popular route for corporates.
A cautionary note: we never eliminated the problem of ADSL suffering from uplink congestion as, by its nature, upward bandwidth was throttled. For ADSL to succeed as a replacement for Frame Relay, it must be significantly over-specified, and preferably symmetric otherwise the uplink will be the first to choke up. My advice is to use SDSL if you can get it.
Overall we brought the cost down to a level that makes even a small office an economic proposition.
Peter Skipwith was the European IT manager leading this project. He now runs his own company Skipwith Associates