[c-nsp] VPN failover / load sharing using IOS?
Rodney Dunn
rodunn at cisco.com
Wed Feb 9 12:23:14 EST 2005
That is exactly right to be the easy way to do
it.
You encrypt all gre traffic and just run EIGRP
stubs over the GRE's.
You can not get "load balancing" with this in any
way other than some manual route changes or either
by doing per-packet (which really is load sharing).
I've never tried it but I wonder if you can configure
one router as an OER master and have it install
routes to "load balance" the traffic egress on the
two GRE tunnels. Most customers are ok with
the per src/dst hash (please don't say per destination
because that is not what it is).
If you do have a single flow between a src/dst ip combination
you will overrun one link and not use the bandwidth of the
other. But even OER can not fix that because it load
balances based on injecting routes to destination prefixes.
Rodney
On Wed, Feb 09, 2005 at 10:41:27AM -0500, Luan Nguyen wrote:
> 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