New Network Design but Old Security Models?
We’re full into our core network design here at our Greenfield deployment. A couple of interesting discussions have come up around the design, particularly in terms of Cisco Virtual Device Contexts (vDC) on the Nexus gear.
First, here’s what we have already sitting on the dock or in the racks:
- (2) Nexus 7010 Core Switches w/ 3 fabric modules and 2 supp’s
- (4) 8-Port 10 GbE blades
- (2) 48-Port 1Gb Copper blades
- (2) Nexus 5020 Agg Switches deployed top-of-rack
- (2) ASA 5580-40’s w/ 4 10 GbE ports ea.
- A handful of Nexus 1000v licenses
A primer for those who, like me, are still fairly unfamiliar with Nexus technology:
The virtual device context idea is really what puts the virtual into Cisco’s virtualized networking (why you still need physical cables for each vDC is beyond me and another story :) ). As I understand it, a vDC basically allows you to segregate your physical switching into multiple virtual switches, just as if you had bought multiple physical switches to begin with. Currently the Nexus 7000’s allow up to 4 vDCs, and I believe that will be expanded to eight in the future.
Each vDC requires a pair of physical cables (actually Cisco recommends cabling sufficient to avoid over-subscription based on traffic to other parts of the network) to send traffic between vDCs, as well as a dedicated “peer link” to facilitate heart beat and keep alive. Again, this is my pretty rudimentary understanding of virtual device contexts. I’m sure the networking guys can expound on this!
Now, all of that said, here’s what we’re thinking for vDC use cases.
Model 1:
- Default vDC for Management
- vDC2 for Production & DMZ traffic
- vDC3 for Test/Dev traffic
Model 2:
- Same as model 1, but adding vDC4 for DMZ traffic
The upside of Model 2 is that we get added separation for DMZ traffic (potentially more secure), the downside of course being the increase in physical cabling, port density, and the loss of a spare vDC (at least until the allowed number of vDCs goes to 8).
Finally, we come to my question in all of this. As the Server/Virt guy, I’m starting to ask, “Why are we using traditional security models as we try to foster a private cloud environment?” Perhaps I’m ignorant about particular security methodologies on the Nexus switches, but it seems to me that creating these security zones (traditional Inside, DMZ, Outside) in conjunction with the ASAs feels a bit archaic. My thoughts are to use vDCs to split workloads (production, Dev, etc), not as security walls. There are a host of other features in the Cisco arsenal to handle that (VLANs, VRF, etc).
Now, the hole in my argument, is that while I don’t like the traditional security model in a private cloud, I don’t really have any answers as to what it should be instead.
Thoughts?
