We are considering to replace our old Catalyst switches in our data centre with Nexus 5000 and Nexus 2000.
Most of our environments are virtualised (about 80-85% of our production and uat servers VMWare). Looking through Cisco's website, I noticed there is a new Cisco Nexus 1100 which I'm not familiar with. I understand that this actually houses the 1000V which is a virtual switch.
Our original plan is to connect the VMs to 2000s and since 2000s need its "parent" for configuration, which will be handled by 5000, would it make sense just to use 5000s and 2000s. Probably have difficulties to allocate budget for additional 1100 (since I assume even with 1100, we still need 2000. I don't see enough ports with 1100 to be connected directly to our VMs). Also, I have doubts of what can 1100 do that 2000 can't.
In an environment as you describe you'd have Nexus 5500 supporting Nexus 2000 to which you then connect the physical VMware ESX servers.
In the ESX server you have the option to use the standard vSwitch, the Distributed vSwitch or the Nexus 1000V as the virtual switch in the ESX host.
When you use the Nexus 1000V there are two components: the VSM (Virtual Supervisor Module) and the VEM (Virtual Ethernet Module). The VSM is the control for a number of VEM, with a VEM running in each ESX host.
The Nexus 1100 is effectively a dedicated server that can be used to host the VSM. You can't use the Nexus 1100 to connect Nexus 2K.
If you want to use Nexus 1000V then you have the option to run the VSM in the ESX servers that it is actually controlling. If you plan to use VMware VSS or VDS then you have no Nexus 1000V and so would not need Nexus 1100.
Let me start by stating I've not used Nexus 1000V in a production environment so others are probably better qualified to answer, but here's my take on it.
Cisco will obviously give a long list of advantages for the Nexus 1000V, "virtual servers using the same network configuration, security policy, diagnostic tools, and operation models as their physical server counterparts" etc. That's obviously true, but to be expected as VMware switches only live in the virtual world. Working in an environment where we use vSphere switching it can be a little frustrating not knowing what's going on beyond the physical network edge, and as such one of the things I really like with the Nexus 1000V is the visibility it gives me in comparison to the VMware standard or distributed switch.
The Nexus 1000V used to offer quite a bit more in terms of features, but in recent versions of the VMware vSphere the distributed switch has added support for Network I/O control, LACP, ERSPAN, Netflow support, VXLAN etc. If you want to do a quick comparison of the features supported in Nexus and vSphere switches take a look at the blog over at http://virtualpatel.blogspot.co.uk/2013/02/vsphere-vss-vds-cisco-nexus1000v.html. It's a little dated, but reasonable none the less.
In short, and with the aforementioned caveat on my real production experience, I'm not sure there are too many compelling reasons to go with Nexus 1000V, particularyl if you're running a recent VMware vSphere version.
As for the second part to the question, the Nexus 1110 is effectively a Cisco UCS C-series server and so the diagram I think you're referring to simply shows the different options of connecting the Nexus 1110 i.e., a server, to the FEX. In the diagrams the Nexus 5000 is still the controlling switch of the Nexus 2000 FEX.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...