More than a year ago I was enjoying a cool beer with my friend Nicola Modena who started explaining how he solved the “you don’t need IP address renumbering for disaster recovery” conundrum with production and standby VRFs. All it takes to flip the two is a few changes in import/export route targets.
I asked Nicola to write about his design, but he’s too busy doing useful stuff. Fortunately he’s not the only one using common sense approach to disaster recovery designs (as opposed to flat earth vendor marketectures). Adrian Giacometti used a very similar design with one of his customers and documented it in a blog post.
- Layer-3 DCI
- No stretched VLANs
- Simple storage replication between sites
- Recovery site is in ready-to-go hot standby. Storage is ready, networking is ready, all it needs are the virtual machines
- Production and Recovery VRFs use the same IP addressing internally. They are never connected directly.
- He complicated the design a bit with NAT and probing-based DNS. I’m positive it would be possible to get rid of these requirements following Nicola’s approach.
He concluded his blog post with three rhetorical questions that I couldn’t resist answering:
Is technology evolving or is just a pile of old stuff rebranded by new developers?
It’s just a pile of old stuff (see also RFC 1925 rule 11). Unfortunately most developers don’t care about history and thus repeat its mistakes ad nauseam.
Why haven’t I seen these scenarios before? I know it might sound weird, but it is completely viable as a basic case of study.
Because these scenarios don’t fulfill two requirements:
- You can’t fake disaster recovery testing with them, because it’s impossible to move a single VM to the other site, claim “mission accomplished”, and go home.
- These designs don’t make any money for the networking or virtualization vendors – they work well on any gear that supports VRFs, and are not complex enough to justify selling new gear.
How far away were we from having an active-active scenario?
Very very far. More in an upcoming blog post.