[c-nsp] VPN failover / load sharing using IOS?
Luan Nguyen
luan.nguyen at mci.com
Wed Feb 9 10:41:27 EST 2005
I put a sample config for you to look at. My definition of a VPN is the
IPSEC transport mode( or tunnel) over the GRE. So if you have dual T1 with
their own address from different ISP, then you could build 2 VPNs, one for
each link. The LAN side - most of the time will be 1918 address? Then just
use EIGRP or static to create 2 routes equal cost over the 2 GRE tunnels.
If you only have one host talking to one host on the LAN side, then there
will not be load sharing per-destination. Per packet would do the job
though. These are T1 so you don't need that object tracking thing. If you
only have one host to one host then maybe do policy base routing base on the
type of traffics so you could load share somewhat.
crypto isakmp policy 1001
encr 3des
hash sha
authentication pre-share
group 2
crypto isakmp key connection1 address 1.1.1.1
crypto isakmp key connection2 address 2.2.2.2
!
crypto ipsec transform-set TRANS esp-3des esp-sha-hmac
mode transport
!
crypto map CryptoMap1 local-address T1_1
crypto map CryptoMap1 1024 ipsec-isakmp
set peer 1.1.1.1
set transform-set TRANS
match address ACL_1
!
crypto map CryptoMap2 local-address T1_2
crypto map CryptoMap2 1024 ipsec-isakmp
set peer 2.2.2.2
set transform-set TRANS
match address ACL_2
!
interface Tunnel1
description *To 2nd router - T1_1*
bandwidth 1544
ip unnumbered fa0/0 <--------Could use static ip like a.a.a.1 on one side
and a.a.a.2 on the other
!*UNNUMBERED TO PRIVATE LAN*
ip mtu 1440
tunnel source X.X.X.X
tunnel destination 1.1.1.1
crypto map CryptoMap1
!
interface Tunnel2
description *To 2nd router T1_2*
bandwidth 1544
ip unnumbered FastEthernet0/0
!*UNNUMBERED TO PRIVATE LAN*
ip mtu 1440
tunnel source Y.Y.Y.Y
tunnel destination 2.2.2.2
crypto map CryptoMap2
!
interface WAN1
ip address X.X.X.X 255.255.255.252
description *WAN 1*
no ip redirects
no ip unreachables
no ip proxy-arp
duplex full
speed 100
crypto map CryptoMap1
!
interface WAN2
ip address Y.Y.Y.Y 255.255.255.252
description *WAN 2*
no ip redirects
no ip unreachables
no ip proxy-arp
duplex full
speed 100
crypto map CryptoMap2
!
interface FastEthernet0.0
ip address Z.Z.Z.Z 255.255.255.0
description *LAN 2*
no ip redirects
no ip unreachables
no ip proxy-arp
duplex full
!
ip access-list extended ACL_1
permit gre host X.X.X.X host 1.1.1.1
ip access-list extended ACL_2
permit gre host Y.Y.Y.Y host 2.2.2.2
!
router eigrp 1
passive-interface FastEthernet0/0
network Z.Z.Z.0 0.0.0.255
no auto-summary
eigrp stub connected
!
ip route 1.1.1.1 255.255.255.255 WAN1_gateway_address
Ip route 2.2.2.2 255.255.255.255 WAN_2_gateway address
Hope that help.
Luan
----- Original Message -----
From: "Brian Feeny" <signal at shreve.net>
To: "Rodney Dunn" <rodunn at cisco.com>
Cc: <cisco-nsp at puck.nether.net>; "Luan Nguyen" <luan.nguyen at mci.com>;
<Cameron.Dry at didata.com.au>
Sent: Wednesday, February 09, 2005 10:09 AM
Subject: Re: [c-nsp] VPN failover / load sharing using IOS?
>
> I haven't even gotten that information back yet. Are you talking about
> the SAA object tracking stuff?
>
> Since their would be load sharing one link could go down and it should
> be ok. In other words rather than a standby circuit, both circuits
> should be live. But since after the GRE's are up and even EIGRP in
> place, the actual IPSEC SA represents a single source/destination pair
> (as far as the level that GRE and EIGRP are at), then that will create
> a single flow over only one link.......which is fine I suppose. I may
> do up a diagram to give a clearer picture of what I am trying to
> accomplish. I am pretty sure whatever route I go the 1700's will work
> ok for this application.
>
> Brian
>
> On Feb 9, 2005, at 7:07 AM, Rodney Dunn wrote:
>
> > What are your ISP connections?
> > HDLC, PPP, *net, ?
> >
> > I've done a couple of desigs leveraging
> > HSRP with Object tracking of the wan
> > links for failover also.
> >
> > Rodney
> >
> > On Wed, Feb 09, 2005 at 12:18:40AM -0600, Brian Feeny wrote:
> >>
> >> Actually, your right. But really the vpn is establishing a single
> >> source host to a single destination host, since whats really riding on
> >> top of the GRE layer is the VPN itself. Like you say, per destination
> >> balancing sort of makes it not work very well.
> >>
> >> Too bad cisco doesn't allow you to just define two vpn's and treat the
> >> result as two equal paths, that would be a bit better.
> >>
> >> Brian
> >>
> >> On Feb 8, 2005, at 11:59 PM, Luan Nguyen wrote:
> >>
> >>> It would work just like that I think. The router would just do
> >>> per-destination load share wouldn't it - unless you only have one
> >>> host
> >>> talking to one host? In our environment we have one spoke with dual
> >>> GRE
> >>> tunnels to 2 hubs with equal cost. Yours is a little different but
> >>> it
> >>> should work for load balancing just like that.
> >>>
> >>> Luan
> >>>
> >>> -----Original Message-----
> >>> From: cisco-nsp-bounces at puck.nether.net
> >>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Feeny
> >>> Sent: Wednesday, February 09, 2005 12:33 AM
> >>> To: Rodney Dunn
> >>> Cc: Cameron.Dry at didata.com.au; cisco-nsp at puck.nether.net
> >>> Subject: Re: [c-nsp] VPN failover / load sharing using IOS?
> >>>
> >>>
> >>> Rodney,
> >>>
> >>> I will definitely look into OER. But if I had 2 GRE tunnels, why
> >>> can't
> >>> I just point statics like in my example, for each remote subnet down
> >>> the tunnels? Wouldn't that load balance AND work for failover?
> >>>
> >>> Thanks,
> >>>
> >>> Brian
> >>>
> >>> On Feb 8, 2005, at 11:20 PM, Rodney Dunn wrote:
> >>>
> >>>> There are really on two ways to do this:
> >>>>
> >>>> a) you announce some subset of routes down
> >>>> one gre tunnel from the headend and prefer
> >>>> them and the other subset over the backup tunnel
> >>>>
> >>>> that way if one tunnel goes away you will have failover.
> >>>> The drawback there is the load sharing isn't dynamic.
> >>>>
> >>>> The only way you can get dynamic loadsharing in
> >>>> this type of setup is OER.
> >>>>
> >>>> b) Do OER at the spoke side and let it load balance
> >>>> the traffic back towards the headend.
> >>>>
> >>>> They were going to put a sample of that in the OER
> >>>> deployment guide but I'm not sure they have gotten
> >>>> to it yet.
> >>>>
> >>>> http://www.cisco.com/go/oer
> >>>>
> >>>> Rodney
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Feb 08, 2005 at 10:31:43PM -0600, Brian Feeny wrote:
> >>>>>
> >>>>> thanks, although that looks to be for sites with multiple routers
> >>>>> and
> >>>>> multiple links. Each of these sites is only going to have one
> >>>>> router,
> >>>>> that takes in 2 T1's. I don't think that will work in that
> >>>>> scenrio.
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>> On Feb 8, 2005, at 10:07 PM, Cameron.Dry at didata.com.au wrote:
> >>>>>
> >>>>>> Check out:
> >>>>>>
> >>>>>> http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/
> >>>>>> products_feature_
> >>>>>> guide09186a00800ed370.html
> >>>>>>
> >>>>>> Cameron
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: cisco-nsp-bounces at puck.nether.net
> >>>>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> >>>>>> signal at shreve.net
> >>>>>> Sent: Wednesday, 9 February 2005 11:50 AM
> >>>>>> To: 'cisco-nsp'
> >>>>>> Subject: [c-nsp] VPN failover / load sharing using IOS?
> >>>>>>
> >>>>>>
> >>>>>> Has anyone done any type of VPN failover and/or load balancing
> >>>>>> using
> >>>>>> IOS?
> >>>>>>
> >>>>>> For example something like a 2 1700 routers, each with 2 T1 cards
> >>>>>> in
> >>>>>> them,
> >>>>>> Each T1 card would be connected to a different ISP, each with its
> >>>>>> own
> >>>>>> IP space
> >>>>>> (no BGP). Either T1 would be able to go down, and the VPN could
> >>>>>> re-establish
> >>>>>> itself over the remaining T1. Both T1's would be load balanced
> >>>>>> over
> >>>>>> for VPN
> >>>>>> connectivity.
> >>>>>>
> >>>>>> Is it possible to establish 2 VPN's, 1 over each link, with the
> >>>>>> same
> >>>>>> source/destination private networks defined, and have the router
> >>>>>> load
> >>>>>> balance these and also work in failover?
> >>>>>>
> >>>>>> Another thought, which is kind of ugly (but maybe not), is 2 GRE
> >>>>>> tunnels, and then dual static routes over the tunnels:
> >>>>>>
> >>>>>> Router 1 T1 #1 <----------------------- GRE Tunnel #1
> >>>>>> -------------------> Router 2 T1 #1
> >>>>>> Router 2 T1 #2 <------------------------ GRE Tunnel #2
> >>>>>> -------------------> Router 2 T1 #2
> >>>>>>
> >>>>>> ip route <insert vpn endpoint ip> 255.255.255.255 Tunnel1
> >>>>>> ip route <insert vpn endpoint ip> 255.255.255.255 Tunnel2
> >>>>>>
> >>>>>> Then establish the VPN on top of the above. I don't particular
> >>>>>> like
> >>>>>> the idea of building a tunnel on top of 2 other tunnels, so if
> >>>>>> anyone
> >>>>>> has experience in doing this type of setup, please share what you
> >>>>>> used
> >>>>>> to do it.
> >>>>>>
> >>>>>> Brian
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Brian Feeny, CCIE #8036, CISSP
> >>>>>> Network Engineer
> >>>>>> ShreveNet Inc.
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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/
> >>>>>>
> >>>>>>
> >>>>>> ******************************************************************
> >>>>>> **
> >>>>>> *
> >>>>>> **
> >>>>>> *******
> >>>>>> - NOTICE FROM DIMENSION DATA AUSTRALIA
> >>>>>> This message is confidential, and may contain proprietary or
> >>>>>> legally
> >>>>>> privileged information. If you have received this email in error,
> >>>>>> please notify the sender and delete it immediately.
> >>>>>>
> >>>>>> Internet communications are not secure. You should scan this
> >>>>>> message
> >>>>>> and any attachments for viruses. Under no circumstances do we
> >>>>>> accept
> >>>>>> liability for any loss or damage which may result from your
> >>>>>> receipt
> >>>>>> of
> >>>>>> this message or any attachments.
> >>>>>> ******************************************************************
> >>>>>> **
> >>>>>> *
> >>>>>> **
> >>>>>> *******
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> 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/
> >>>>>>
> >>>>>
> >>>>> Brian Feeny, CCIE #8036, CISSP
> >>>>> Network Engineer
> >>>>> ShreveNet Inc.
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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/
> >>>
> >>> _______________________________________________
> >>> 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/
> >>>
> >>>
>
> Brian Feeny, CCIE #8036, CISSP
> Network Engineer
> ShreveNet Inc.
>
More information about the cisco-nsp
mailing list