VPN as a backup to Frame Relay

Jonathan,

Well, I have a few thoughts. Not really sure what you are looking for, since there is no specific question in there. But, here goes...

First, this is definitely do-able and a good solution, depending on needs. Be aware that using DSL can cause problems with VPN. You'll be using PPPoE, which uses a small portion of the packet. Not much (I think 8 bytes), but enough that it can cause problems with mtu. You may find that some of your apps just don't work. So, there can be some engineering to be done. Cable makes a better solution, IMHO.

You can have the VPN only come up when the frame drops. However, there are issues with that as well. At my locations, I'm only using my internet connections for the vpn backup as well. If the internet ever went down, I wouldn't know it. So, I prefer to always have the vpn up. Create a tunnel interface, use a routing protocol and the only traffic you will pass will be the routing updates, until the frame goes down. I monitor both live circuits as well as the vpn to know when either is not working. Another issue with this is bandwidth and latency. If your apps are latency sensitive, it could cause you problems. Your throughput will most likely be less during the vpn than when using the frame. Not a big problem for most setups since it is just a backup. Just something to be aware of.

You can use a firewall of choice to create the vpn, and then tunnel from router to router (needed to get routing updates). Or, I think the latest pix code does ospf, so you might be able to use that. Another good option is to add a small router (83x series) that can do the firewall, vpn and routing updates.

One more thought... Not sure exactly how sensitive your information, but it sounds pretty much so if you are doing a vpn over the frame. Perhaps they could add a secondary circuit instead of the vpn backup. More expensive, but also more secure. IPSec vpn has its flaws. If you did have two private circuits, you could load balance.

Hope that helps. Good luck!!!

Jim

The use of a VPN for the frame relay link actually makes the configuration a bit trickier, but still very much doable. You need a setup which backs up a VPN with a second VPN, rather than a setup to back up a frame relay link with a VPN. That is why you have not found anything appropriate in your searches.

There are multiple approaches available, which is best for you will depend upon your specific requirements and available hardware, software, and skills. My favorite approach is to used BGP to detect loss of the primary VPN, with the backup VPN always up for test purposes (you don't want to fail over to the backup VPN only to discover that your DSL line failed while you were not looking).

See the white paper on redundant IPSec VPNs on my website for a sample configuration and discussion of how it works.

Good luck and have fun!

Unfortunately they aren't interested in going with an additional Private circuit at this time. In our geographic area there is really only one provider for Frame Relay circuits, and so if they got two circuits it really wouldn't be redundant. The main point of the VPN over the frame is just as an added security measure for them since it was available on their routers. The VPN over the Internet is actually likely to be about the same speed as what they currently have as they only have 128Kbps frame circuits at this time. Specifically they actually have three locations with a cisco 1721 at each location. The plan is to add a DSL wic card to each of them with access-rules such that they only traffic allowed in on the DSL link is the IPSEC traffic from the static IP's of their other locations.

As far as the PPPoE causing problems are there any work arounds to that in the Cisco VPN world. I know that for other VPN specific venders they have added features to get around these limitations such as fragmented packet handling etc.

I guess I never did really get around to asking a specific question in my first post, sorry about that. My overall question was how would anyone recommend going about this? My first thought since they are already running a VPN tunnel on the Frame circuits was to have the Static IP of the Remote DSL connection as the failover target of the VPN tunnel. This way it would actually use the failover built into the VPN and not specifically have to deal with adjusting routes. The only hangup here is that the remotes currently traverse the Frame back to the Main location for internet access, but I figured I could get around this by leaving the VPN as the default route at the remotes and adding a specific route to the static public IP of the Main location's DSL connection to route out the remote DSL connection.

Jonathan

Jonathan:

How many routers do you have at each remote site? One or two?

Which routing protocol are you running at the moment? You could use a routing protocol to failover, using costs, etc.

Aun.

Currently there is only one router at each remote site, and the plan was to leave it that way and just add a dsl wic card to each remote router.

Currently there isn't any routing protocol running, it's simply using static routes, the remote sites, route everything back through the VPN tunnel over the Frame circuit and the main location has a default route to the internet, and specific routes for the subnets at the remotes.

Jonathan

I am currently using VPN as a backup for 6 of my major sites. I am using eigrp for the routing and a VPN3030 concentrator to terminate the VPN connections. The whole setup was complicated on the first couple of tries, but now it works great. My users sometimes don't even see a hickup in connectity when the frame goes down. Getting the GRE work correctly was the biggest problem. If your frame connections are only 128 - 256. I would suggest using ISDN. It will be a lot easier to setup. And again use some routing protocol and get rid of the statis routes. It will make any backup setup a lot easier especially if your company grows at all. The biigest bonus I found using GRE, eigrp over VPN as a backup was you can use the VPN connection to add bandwith or load balancing.