[c-nsp] MPLS VPN Running BGP w/ failover IPSec VPN Over Internet

Jason LeBlanc jasonleblanc at gmail.com
Tue Jan 26 19:47:31 EST 2010


Current topology is pretty simple.  AT&T drops an MPLS circuit either PPP Multilink Bundled T1's or an Ethernet hand off.  On another interface we generally have an ethernet hand off from another ISP.  We run BGP to move all the traffic around on one 172.x.x.x/30's and then our LAN is on 10.x.x.x.  We have an outside IP address on another ethernet port which is the IPSEC termination point.  BGP from our main campus injects a default route which we receive.  Currently we just manually added static 0.0.0.0 routes out the tunnel interfaces with a metric of 32000.  So when BGP drops off we will route over the IPSEC VPN Tunnel back home.

Headquarters 172.1.1.1/30 --> ATTMPLS 172.1.1.2/30 --> 
                                                                                                        ATTMPLS 172.2.2.1/30 --> Remote Campus 172.2.2.2/30 (running BGP) --> 10.1.1.1/24
                                                                                                        ISP-X Ethernet 200.1.1.1/30 --> Remote Campus 200.1.1.2/30 --> IPSEC VPN Tunnel.1 10.1.1.20/24 --> Headquarters Tunnel.1 10.1.1.21/24

BGP Provides default route
Static 0.0.0.0 0.0.0.0 Tunel.1 Metric 32000

It is my assumption that if the traffic cant get to its destination because BGP has lost it our backup link the IPSEC VPN with the higher metric will become the new default route.


On Jan 26, 2010, at 4:44 PM, Luan Nguyen wrote:

> What's the topology?  One CPE terminating MPLS and IPSEC tunnel? If this is
> the case, then if at one site MPLS goes down, it starts to use IPSEC tunnel,
> when packets get to the other side, the default route to MPLS VPN is still
> there so packets will get routed back into the MPLS cloud. You need more
> specific routes advertised so that when MPLS lost, it will withdraw the
> route and IPSEC will kick in.  Just a default won't work unless you'll be
> doing some creative conditional advertising in the BGP or some fancy EEM
> scripting...or maybe using ip sla to withdraw route...which might be a
> little more complicated than need be.
> 
> Even with specific routes, you still have lots of decision to make like
> whether to switch everything to use IPSEC tunnels once just ONE MPLS
> connection goes down or only that site.  Then you have to make sure not
> running into asymmetric routing...etc.
> With GNS3/Dynagen, you could probably test this whole thing out in your
> labtop.
> 
> ---------------------------------------
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> [Web] http://www.netcraftsmen.net
> ---------------------------------------
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason LeBlanc
> Sent: Tuesday, January 26, 2010 4:20 PM
> To: Cisco-nsp
> Subject: [c-nsp] MPLS VPN Running BGP w/ failover IPSec VPN Over Internet
> 
> Team,
> 
> This questions was put out there before in another chain but I wasn't able
> to figure out the best solution.  We have multiple campuses connecting to an
> MPLS VPN cloud running BGP internally.  At some locations we have backup ISP
> services and an IPSec VPN tunnel over that.  Currently BGP provides a
> default route to each campus as external BGP / Pref 40 / Metric 0.  Our
> backup IPSec is in as a Static / Pref 20 / Metric 32000.  When we lose
> BGP/MPLS VPN we want the IPSec tunnel to begin routing traffic between the
> campus and our main datacenter.  What is the best way to achieve this? 
> 
> Thanks,
> 
> //LeBlanc
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 4807 (20100126) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
> 
> 
> 



More information about the cisco-nsp mailing list