We have a Site to Site VPN setup that comes into use when the primary links to our London site go down. Yesterday we lost the primary links and along with it alot of connectivity.
We use floating static routes to tell our router to pass traffic to the VPN router when we lose the primary links. The problem is the statics are very intensive from an admin perspective. I think the VPN routers should learn all routes via RIP in their respective sites and pass these over the link, when interesting traffic brings the interface up.
What is the best way to do this? Has anyone worked on a problem like this?
Reason for choosing floating static routes is it doesnt consume any ISDN bandwidth which is valuable.But since RIP sends updates every 30 secs it consumes extra bandwidth.There is no option in RIP to automatically bring down the ISDN interface when the primary interface comes back up again.
As I read the original post, Gavin is talking about a connection over VPN. I do not see anything in the original post that talks about ISDN. The issues with routing over VPN are significantly different from the issues of routing over ISDN.
Gavin - have I understood your post correctly that you want to run a routing protocol (RIP ?) over the VPN and you want it to advertise only when the VPN is active? Getting a routing protocol over the VPN can be done. Getting it to advertise only when the primary link has failed is much more difficult.
The main issue with running a routing protocol over VPN is that IPSec is for processing unicast IP traffic and our routing protocols (except for BGP) use multicast or broadcast for propagating routing packets. The traditional solution for routing protocols over IPSec has been to combine IPSec VPN tunnels with GRE. The GRE is able to forward both unicast and multicast/broadcast traffic. In recent versions of IOS Cisco has provided another alternative. The Virtual Tunnel Interface is a new feature for processing IPSec which is able to handle multicast traffic. I have done routing protocols over GRE IPSec VPNs many times and it works well. I have not yet done a VTI so I can not speak to how well it works.
So we have solutions of how to run a routing protocol over the VPN. But I am not sure of a good way to have the routing protocol only advertise when the primary link is down. How important is it that the routing protocol not run if the primary link is up? You should be able to manipulate the metrics so that the routes through the VPN are less attractive and would only be used if the primary link were down. Would that be good enough or do you really need the routing protocol to not run while the primary link is up?
We run OSPF with adapted costs for the same situation: primary serial links and vpn failover.
As Rick states you need to use gre in ipsec tunnels for the routing protocol. We configure a higher cost for the gre tunnel interfaces as opposed to the interfaces from the primary links, we leave them standard. So the primary links are the favorite ones
You need to add the costs carefully also with respect to the returning traffic to avoid asymetrical routing.
Your 100% correct. I want to run RIPv2 over the Tunnel. With periodic updates RIP would keep the tunnel up at all times. I don't think this is a major issue, just as long as the VPN router advertises a less attractive route. Could you provide an example of how you have used RIP over a GRE Tunnel?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...