Duplicate an existing network and isolate it inside a bubble

[heath]

For some reason this is making me scratch my head more than other problems lately.  We've set up a "DR" site at a branch location.  Everything there is just old stuff we've replaced at our home datacenter.  The virtual environment is several Dell R700 servers, networking is a Cisco 6509.  Storage is Tegile and is the newest thing there.  Host servers and storage are connected to the 6509.  I have no ASA or any other firewall in place as of yet.

I need to create an isolated "bubble" network.  Various vlans and physical ports (some trunk, some access) need to have packets switched and routed between them, but with no access in or out of the "bubble."  The 6509 is the gateway for some of the vlans while a virtual F5 in the virtual environment is the gateway for a couple others.  Again, I do not yet have an ASA in place.

This is only temporary for a small DR test to show that we can bring up certain mission critical servers and they can all talk to each other and be accessible by a client which, for now, is inside the bubble with them. 

This seems like it should be simple to set up, but without a firewall yet, I'm kind of at a loss.  Can anyone give me some guidance?

[wintermute000]

VRF-lite is your answer.

Your VLANs need to be different numbers but if you create everything in a VRF you can even dupe IP addresses. Just don't accidentally 'cross the streams'....


OR you could do a really nasty hack with ACLs on all the isolated VLANs but then you have to use different IP addresses:


(inbound on SVI)
- allow ip any <DR bubble summary>
- deny ip any any


Most of the time the fact that its DR means that people really love the idea of having the same IPs hence VRFs

[icecream-guy]

fairly easy, pc with 2 nics, that'll work,  1 nic connected to prod, and 1 nic connected to DR.  Remote into the PC as a gateway to the other network, then into other devices,  PITA and slow.
you can build a small unique transit network on the inside to get around the duplicate IP address issue.

****WARNING***********************************************************
Beware that your temporary solution to run some test will turn into a production network
***********************************************************************

Here is why,  you won't have access to all the tools and resources you'll need,
someone will need NTP, to make time accurate,
someone will need internet to download some patch directly from the vendor
and that download can't be done via IP, so they'll need DNS.
management won't want to get another license for some expensive proprietary software, so that'll need to touch production
someone will want to touch the production AD for some reason, maybe authentication
then some manager will need to see what going on, so you'll need to setup some sort of logging and reporting to production
on and on and on.

Believe me, at my last gig, we had a pre-prod environment for staging prior to deploying into production, we did have a firewall and NAT, and RDP and all that, it was a PITA.
it wasn't like production, although said to be, it was a mish-mosh of crappy spare parts we has lying around, and piece hammered together with paper clips and bubblegum.
it was all overhead, didn't make the company any money, so there was no investment. That and nobody wanted to go through the process to update the pre-prod environment when changes were made to prod, so every time someone needed to setup in preprod it was a scratch and think event to figure out what changed in prod over the past weeks or months to make this damn thing work in pre-prod.

[icecream-guy]

humm, when off on a tangent, there thinking same IP's on both networks don't know why,

even easier,  hang a new switch off the 6500'  on it's own vlan,   create the security ACL to block in/out, static routes to the new environment
and connect everything up to the new switch. did this at another gig, mock up of a network build we rolled out to WA state.

[heath]

VRF-lite is your answer.

Your VLANs need to be different numbers but if you create everything in a VRF you can even dupe IP addresses. Just don't accidentally 'cross the streams'....


OR you could do a really nasty hack with ACLs on all the isolated VLANs but then you have to use different IP addresses:


(inbound on SVI)
- allow ip any <DR bubble summary>
- deny ip any any


Most of the time the fact that its DR means that people really love the idea of having the same IPs hence VRFs

Looks like VRF-lite is the way to go.  Now to do some googling and learning...

[LynK]

This is why we VXLAN/OTV

Doesn't help your current situation, but it is what you should be striving for. The goal for DR is to have be as automated as humanly possible. By this I mean, DNS records the same/different but already configured, IP addresses the same/different but already configured, external IPs the same/different but already configured, etc. The only difference should be physical location & host.

If you can't do this I recommend something like SRM. Then having a duplicate network in another site with different L3 IPs and script SRM on failover to change the host IPs. For example if HQ server vlan is 10.0.0.0/24, in SRM you can have all the VMs change their networks to X.1.X.X/24 to then automatically change. You then have DNS records already in place (less preferred obviously) to support those services. The same goes for external IPs. NATs already in place. This makes your DR automatic, and require ZERO manual changes.

[heath]

The eventual goal is Active/Active datacenters. But we're not there yet! 

[heath]

VRF-Lite worked a charm.  Easy to set up too.  I didn't think it was working at first, but after re-coordinating with the system admin we discovered he had some things set up wrong on his end.  But it's working and we didn't blow anything up in the process.  I'll take that small success!