My interest was piqued by news from Juniper Networks that they had licensed JunOS to BLADE Network Technologies. Not that I’m surprised; I’ve suggested this approach (and some approaches more extreme…) to both Juniper and Cisco in the past. But it did get me thinking about the differences in network architecture, between the approach of Cisco’s UCS versus the potential JunOS/BLADE approach.
For instance, a UCS system leverages a "fabric extension" module, transparently connecting multiple blades to a Top-of-Rack switch (TOR) such as the Nexus 6120. When combined with the Nexus 1000V software (and VMware-integrated port profiles) an entire cluster of UCS chassis can be managed as a single resource pool. Making a few design assumptions, the environment may look something like this:
This design provides a single logical interface to the external network (i.e. data center backbone, WAN, whatever). However it is a flat network within the environment. This is great for VM mobility throughout the resource pool, but not so great for scaling the network to many VLANs.
The alternative presented by Juniper provides an interesting comparison because it moves a switching function into the blade-server chassis. Admittedly this doesn’t have to replace the TOR switch. But just for argument’s sake, again making a few additional assumptions, the design could look something like this:
Note that I show a chassis with and without hypervisor-local switching. This is just to illustrate the possibility, which admittedly could also exist in the Cisco UCS environment; this is not because I have some interesting point to make about it. 
Regardless, the Juniper/BLADE design may allow for better network scaling depending on the features that are bundled into the chassis switch. However, in contrast to the UCS design there are more management touch-points. And to really take advantage of the network scale possibilities, the network architecture itself has to be different — more oriented around layer 3, less of a wide-flat-layer 2. This could be a problem for VM mobility depending on the overall application needs (mostly due to IP addressing and the need for shared broadcast domains).
The key next-step in either approach, in my opinion, is to deploy new features in the TOR and/or chassis switch. Specifically, data center networking doesn’t have to be an all or nothing L2 vs L3 debate. Please look for additional thoughts on this topic in a future post.
