We are currently running an IPSec/GRE based VPN network setup in a hub-and-spoke model, The hub site has redundancy via multiple T1 circuits and BGP routing. We would now like to also make the spoke sites redundant using low-cost broadband links. I am not sure on how to do this when using GRE tunnels. Since my spoke sites would be using to different public IPs I would somehow need to configure the tunnels at my spoke sites with two different source IPs and the tunnels at the hub site with two different destinations IPs. Is this possible? Will I have to create two tunnel interfaces?
-- Create loopback interfaces on the routers that terminate the tunnels, and set the source and destination addresses on the tunnels to those loopback interfaces.
-- Use the existing endpoints as they are, and just provide routing to the current endpoints through the new broadband connections.
-- Create two sets of tunnels.
The right solution is going to depend on the routability of the addresses you're using for the tunnel endpoints through the new broadband links, I would think. For instance, you say the new broadband links will be public address space--I assume this means the existing tunnels are in private address space. If you try and route your existing tunnels across the new broadband links, this means routing private address space over the publicly address links--generally not workable.
You'll hit the same issue if you decide to do the tunnels from loopback to loopback--what addresses can you give the loopback addresses so they are routable over both sets of existing links? Should you use public addresses, and if you do, where will those addresses come from?
Once you settled questions of addressing, the easiest/most practical option will probably be obvious.
My main concern is link failure. I am not too worried about the hub site because I am using two (2) T1 circuits and BGP. Therefore the tunnel endpoint IP at the hub will always be consistent.
My big problem seems to be at the spoke sites. At the spokes I use a 1710 router with the e0 interface using a static public IP and the fa0 interface uses a private IP. I have a broadband router on the private LAN that can NAT the private IP of fa0 but that IP is dynamic. I am now using pure IPSec tunnels that terminate on a PIX at the hub. Since the PIX accepts dynamic IPsec peers I am good for the moment whether the spoke comes into the hub using the static, public e0 IP or the dynamic, NATed IP from the broadband router. My main problem there is how to define a GRE tunnel that uses dynamic IPs. It seems like I can't.
I am starting to think that maybe I can use GRE and the static IP for my main link and use a dynamic IPSec tunnel via the broadband as a backup.
Since the ip address on the broadband connection is dynamic, I would think that the gre tunnel for the primary, and the ipsec tunnel to the pix with dynamic addressing, is going to be your best bet.
You could probably make one end of the GRE tunnel dynamic by making it unnumbered to the dynamically numbered interface (will this work? I've never tried it, but it should, in theory), but that would still leave you having to manually configure the tunnel destination on the other end, so it wouldn't be much use anyway.
If you could always count on having at least one linek up, something like NHRP might be useful, but I'm not certain it's worth the trouble for just a couple of tunnels.
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...