[afnog] Need help on Disaster Recovery Site Setup

Thu Oct 6 04:01:33 UTC 2011

Thanks very much Mr. Bernard
Your ideas are quite clear.

-----Original Message-----
From: Bernard Wanyama [mailto:bwanyama at syntechug.com]
Sent: Wednesday, October 05, 2011 4:40 PM
To: Yasini Kilima
Cc: afnog at afnog.org
Subject: Re: [afnog] Need help on Disaster Recovery Site Setup

Hi Yasini,

>From your mail, I think you are looking at network-level disaster recovery.
You can start by clarifying your requirements and then developing a
design that meets your requirements.
>From there, implementation and then operation follows.

A simple plan & design comes to mind:

Planning:
- Choose a LIVE SITE and a DR SITE
- Size the traffic, interfaces and growth requirements so that you can
deploy the correct equipment model for core routers
- Confirm that ALL ISPs can deliver a high-capacity trunk link to the
LIVE SITE and DR SITE
- WAN service preferred to be Layer 3 VPN (MPLS)

Design:
- LIVE SITE - Core router with 4 trunk links to WAN providers and 2
point-to-point links to DR SITE
- DR SITE - Core router with 4 trunk links to WAN providers and 2
point-to-point links to LIVE SITE
- BGP routing with WAN service providers
- BGP and OSPF (or IS-IS) in the core between LIVE and DR SITEs across
the 2 point-to-point links

Improvements & suggestions:
- Four WAN providers can work very well technically, but from an
operations and management view, 2 are better.
- Fiber access for the core sites will make life easier
- BGP and dynamic routing in general with the WAN providers will also
make life much easier.
- If you are able to get high speed fibers (or even dark fiber)
between the core sites, then you can leverage application-level DR
technologies like Vmware Vmotion, etc

I hope the above helps.

Kind regards,
Bernard

On 4 October 2011 10:18, Mark Tinka <mtinka at globaltransit.net> wrote:
>
> On Tuesday, October 04, 2011 12:39:34 PM Yasini Kilima
> wrote:
>
> > The scenario is not an issue to design but the challenge
> > is how should I configure the failover or load balancing
> > for the sites that are distant and connected by MPLS
> > Layer 3 links? I have 4 WAN service providers and it is
> > required all should be involved as our regional sites
> > are connected on either or two of the four where
> > multihoming is used. I have Cisco routers throughout. I
> > have googled but didn't find any useful information.
>
> Typically, you're going to consider:
>
>        a) One data centre handles all traffic. Other data
>           centre comes online if the main data centre dies.
>
>        b) Both data centres handle all traffic, load
>           sharing as equally as possible.
>
>
> There are two paradigms in which you can solve this problem
> - at the Network level and at the Application level.
>
> At the Network level tends to work if your budget and
> requirements are simple, using basic IP routing to attain
> your goal.
>
> Application level solutions tend to be more granular, simple
> or complex. Solutions range from open source (as some have
> mentioned on this list) to commercial options, not
> discounting what role virtualization can play here. Things
> can be as simple as DNS, or as complex as geographically-
> aware site load balancers.
>
> I'd defer to others on the application side of things, as my
> thoughts would be centred more around solving the problem at
> the routing level (I'm biased, hehe), which may not
> necessarily be what you're looking for :-).
>
> Mark.
>
> _______________________________________________
> afnog mailing list
> http://afnog.org/mailman/listinfo/afnog

--
Bernard Wanyama
Technical Manager
SYNTECH ASSOCIATES Ltd
Cell: +256 712 193979
Fixed: +256 414 251591
Web: www.syntechug.com
Email: bwanyama at syntechug.com

<html>
<body>
[X] Yasini Kilima | Communication Engineer | Direct Line: +255 22 2119640 | Fax Line: | Office: 6th Floor, Mapato House | Mobile: +255 715 123754 | Website: http://www.tra.go.tz ________________________________ ________________________________ DISCLAIMER: This
 e-mail and any attachments are proprietary to TANZANIA REVENUE AUTHORITY.Any unauthorized use or interception is illegal. The views and opinions expressed are those of the sender, unless clearly stated as being those of TANZANIA REVENUE AUTHORITY. This e-mail
 is only addressed to the addressee and TANZANIA REVENUE AUTHORITY shall not be responsible for any further publication of the contents of this e-mail. If this e-mail is not addressed to you, you may not copy, print, distribute or disclose the contents to anyone
 nor act on its contents. If you received this in error, please inform the sender and delete this e-mail from your computer.
</body>
</html>