Chad must have decided to stir the pot one day with his innocent question:
**************************************************************************
Anyone ever hear of customers directly connecting external servers to Virtual Connect switches? Would this even work?
******************************************
Everyone wanted to voice their opinion.
***************************************
Lee started:
I’m not aware of any Virtual Connect switches, so no. ;-)
You can direct connect to an uplink on a VC module. It will work provided the right interface is in place(hardwired RJ45 or RJ45 SFP). It would be similar to hooking a port sniffer up to an uplink and monitoring traffic.
We did something similar to perform configuration and discovery to a system install at a government site which we couldn’t hook into SIPR net.
Then Cullen jumped in:
It’s important to be aware – Virtual Connect is not a switch. Based on what I’ve seen and read, you can hook a server directly to a Virtual Connect uplink port. However, this connection will only connect the server to that particular Virtual Connect domain. The external server will not be able to communicate to devices that are not in that particular Virtual Connect domain through this interface – only to systems within the enclosure that are connected to the VC network that includes that uplink port.
Virtual Connect Fibre Channel modules must connect to Fibre Channel switches.
Now it was Michael's turn:
Excellent discussion, as the Ethernet set up is an ideal small environment set up with a P4000; But here is the kicker...... is it supported?!
Chris added:
Lefthand needs to go through a switch if there is more than one node, the nodes need to talk to each other and the VC-Eth will not allow them to see each other.
If you use 2 switches they will have to be linked when using ALB on the nodes.
Lee came back with:
OK, I guess we need to clarify. Is this Ethernet or SAN?
Ethernet: Yes, it will connect layer 1. As long as the external server is assigned to the same vNet as the Blades and is on the same IP block. It will move the packets as desired.
SAN: We would need an NPIV capable switch, yes. What benefit would a customer look for unless the FC storage target is a Storage server with DAS? Wouldn’t a SAS Blade solution be a better fit?
And finally Chris joined in:
First off, you can connect an “external server” directly to Virtual Connect. Only a single NIC from this external server would be supported per vNet defined. The vNet and external server would be isolated from any other external network without requiring additional NICs, uplink ports and vNets. Connecting VC to an external switch, and then your external server would be the better approach.
Those that are reading this email and continue to use the term “switch” when referring to VC, needs to remove that from their vocabulary. Virtual Connect is *NOT* a switch, by the marketing definition of a switch. All ports on a VC module are not equal. Meaning, uplink ports are termination ports, not transient ports. I cannot take two uplink ports from VC and “switch” or “forward” traffic between these two ports to two different networks. Please review the VC Myths and the VC for Cisco Administrator whitepapers for further explanation. Both are located on the BSRT SharePoint internal portal (http://teams1.sharepoint.hp.com/teams/bladeinfo/default.aspx) and externally on the VC Product Whitepaper Page (http://h18004.www1.hp.com/products/blades/components/c-class-tech-function.html)
************************************************
Care to comment? Are you using this configuration?
