Disaster Recovery

[cmx]

I am working on a DR design for our infrastructure and was looking for a little feedback. First let me layout our infrastructure:

Main Campus

• N7K in the core
  
• Big-IP F5 LTM (looking at implementing GTM but yet to decide)
  
• 30 MPLS sites; including our DR site (static sites)
  
• 70 DMVPN sites (dynamic sites)
  

DR Site

• 3845 in the core (know that we have to upgrade)
  
• MPLS connected (backup for Main Campus)
  

We are looking to span our L2 traffic across to our DR site to provide system level DR i.e. if a server goes down on the production side; we'll vMotion it across and have it back operational from the DR site. I've looked into a number of options thus far but OTV seems like it is what we are looking for. However, the purchase of another N7K is out of the question (at this point) but I'd like to get some feedback on what other platforms are supported when implementing OTV. As well, any experience that others have had in accomplishing L2 over MPLS connectivity to their DR sites.

Thanks,

Chris

[looperzab]

Have you looked into VPLS if your provider supports it?

http://www.cisco.com/en/US/products/ps6648/products_ios_protocol_option_home.html

Also I haven't had much experience with VMWare but there might be a latency limitation with vMotion, something like 5ms I think.  Something to consider when picking a DR site if you plan to use vMotion.

[cmx]

Thanks for the reply.  I've asked our provider to check into VPLS and Ethernet over MPLS but haven't heard back.  Have you heard anything about OTV and the platforms is supported on?

[looperzab]

I read something that other devices are getting it but I don't know what they are and only 7ks have support right now.  OTV is also kinda odd to setup as it also requires the VDC license if I am correct.

You might also want to take a look at LISP, looks like it is also in IOS.  I don't know if it is what you are looking for but from what I have read it may work.

[Jerry Ye]

LISP will not meet your L2 requirement. LISP is there to correct the asymmetric routing problem caused by L2 extention (OTV, etc). LISP is available in NXOS and IOS 15.x code.

OTV is only supported on the N7K 5.x code currently.

HTH,

jerry

[zahkhan]

Chris

Check Cisco WP at

http://www.cisco.com/en/US/partner/prod/collateral/routers/ps9853/white_paper_c11-694882.html#wp9000036

Did you check VMWare SRM for disaster recovery?

Zahoor Khan

CCIE, CBRM

[Steven Williams]

Is there even a reason to implement OTV for VMware SRM?

[pvinci]

LISP VM-Mobility absolutely can be used for this type of Disaster Recovery.  There are options for extended subnet as well as mobility across subnets.

It is critical that you have your data available at your alternate site in an application consistent state ready to be brought up.  

http://vinciconsulting.com/vxnet

http://vinciconsulting.com/disaster-recovery

Let me know of you have any questions.

Regards,

Paul

[zahkhan]

LISP VM-Mobility may be useful for High Availability (HA) scenarios. And, with the applications and data centers that are well within acceptable latency ranges too. This typically means that the two data centers are geographically close to be considered in same risk domain.

For Disaster Recovery, the primary is not available, so the notion of L2 extension is meaningless.

[pvinci]

Thanks for the feedback!

So, LISP is not L2 extension. It is a layer-3 solution.  Classically, you think of the hierarchy like this: an IP address is in a subnet and the subnet is attached to a gateway or gateways.  With LISP, the IP is associated with a gateway or gateways.  We don't need to address the subnet.

You are correct that LISP can be used in conjunction with OTV or another L2 extension mechanism to where a host is in a stretched network and reduce the "trombone effect". It also can provide VM-Mobility in ASM (Across Subnet Mode).  Disaster recovery is achieved by bringing up an application consistent snapshot from an earlier point in time (copy of the data must already be at recovery site), and using LISP to route traffic to the proper location.