Virtual Connect why must I trunk?

[jsimonelli]

Going over cookbooks and other material I have found that I will end up having to Trunk connectivity. I will say up front that I am new to Virtual Connect and have dealt with cisco devices in the past, so having many items put into one "virtual" device is completely new to me. I do have some questions and concerns and hope that the community can give me more insight on some of the questions I may have. The first thing i found out that boggles my mind is that I will need to go out of the VC into my cisco switches to be routed back or interconnected on vlans up in the cisco switch. I guess it seems to me that I figured that i could do this within VC but either I cant do this without trunking the uplinks or havent found the solution on the web interface. Problem is that I feel I dont have as much control over the network within VC or the web interface, I cant seem to be able to troubleshoot as much as I could with any cisco router or switch, like specifically watch packets go from certain ip's/mac addresses. Also, why should i have to follow the trunk concept done by so many. does the internal network within VC work as fibre, and if so wouldnt the network be somewhat degraded going from fibre style (within VC) and out to a gigabit switch outside to handle trunks and VLAN interconnectivity.

[David Billot]

Greetings J., All good questions. Let's first start with the simple fact that Virtual Connect modules are not switches and thus should not be compared to switching or routing capabilities. A Virtual Connect module is a layer 2 only, multi-ported bridging device. Keeping that in mind, I'll address your questions accordingly: For your first question, let me simply state what can and cannot be done within a Virtual Connect Domain: 1) Blades can communicate to one another without having to exit the enclosure (traverse external switches). The key criteria to do so though is that the communication must occur over the same network/VLAN/Subnet. If however, the server NICs are on separate VLANs then yes, the traffic must exit the enclosure in order to get routed to a different VLAN. 2) Regarding troubleshooting, VC does provide a number of entities to assist with troubleshooting such as a great many counters that are continuously logging. VC also provides link detection, as well as a VC Manager log of all changes that occur within the VC domain. VC also provides port mirroring as well as SNMP support. You are correct though that a typical switch or router does generally provide a great deal more of granularity with regard to packet flow and the like. For your last question, I'm not quite following you here with regard to the fibre portion. Nonetheless, if the question boils down to why VC can't/won't route traffic to and from different VLANs, well, I guess I have nothing better to offer than to say again that VC is a layer 2 multi-ported bridging device, not a L3 switch, not a router. While VC does manage MAC tables within the VC domain, it does not possess the capability to route VLAN traffic. I would also recommend that you take a look at the latest Virtual Connect User Guide that is based on that latest 1.3 firmware code. There were significant enhancements designed into VC with regard to VLAN tagging and how that traffic can either be mapped or tunneled through a VC domain. I'm not saying this as a RTM kind of answer...rather most of the documents, cookbooks etc that you might come across may not have these latest feature sets incorporated into their scenarios and thus may lead you astray as to the true capabilities of VC today. Thanks for posting and please don’t hesitate to continue doing so in your quest to learn more about Virtual Connect! Thanks, Dave [Updated on 10/29/2008 10:15 PM] [Updated on 10/29/2008 10:15 PM]

[jsimonelli]

Thanks for the response. it is much appreciated. To follow up on the last question was that internally VC uses some speed which i thought was equivalent to fibre speeds and having to trunk and go out of it would degreade the connection once it goes to a gigabit switch. If for example internally it moves at 4gb and goes up to a gigabit switch then it really moves at 1 gig speed. Am i correct when i make this assumption? Thanks for the response Jose

[David Billot]

I think you might be confusing Fibre Channel SAN protocol (1,2,4, 8Gb) speeds with Fibre LAN speeds (1Gb and 10Gb). Virtual Connect doens't run at either of these speeds internally -- it runs at wire speed all the way to the NIC. So, no matter what flavor of connectivity you connect to externally (copper or fiber), you will incur a minimal hop of latency to the adjoining network device -- but that's true of any networking technology. But the point of the discussion is moot because VC is not a switch and therefore it will require you to exit the enclosure whenever you need to be routed to a different network and thus you should plan for that additional latency if required - just as you would with any other networking solution. Thanks, Dave

[jsimonelli]

Just to give an update. And also to share what I had to go through in my own set up. I had to reconfigure the whole switch and VC for our new needs since we had to change the strategy from the time HP came and installed this initially. So here it is... I was able to set up the trunks and had everything working but did have issues with only packets originating from the server would only get through if they had a vlan tag attached to them... After playing around with it enough and emailing our HP install technitian they called me back and we had to make sure we used SUS (Shared Uplink Set) and add the ethernet networks through there and adding the VLANs there with the respective vlan id's used on the cisco switches. Then within the profile we had to change the profile to utilize "Multiple Networks" and that brought up a window where we checked the box at the top.. cant remember what it was exactly but it said verbatim but once check it brought the pulldown menu to select from my SUS networks. From there I selected the SUS network i created and then I was able to select the VLANs this network would be a member of, and was able to untag ONLY one per this setting. In the end we only brought out only one vlan to the cisco switch considering that this actually worked for us without having to bring our internal network out.

[jsimonelli]

Ohh also, I following the cookbook and was using Scenario 10, the only change I had to make was to add the port-channel to VLAN 101, since it did not have that setting, but with enough trial and error I figured this out. From here on out, outside network was able to hit my DMZ being controlled by the cisco switch with no problems.

[jsimonelli]

I had another question on a follow up... Currently we only used the DMZ to go out of VC and into the switch. I also have our internal network only on VC without any hooked up ports onto it just the ethernet network was created and then assigned to all the profiles. Everything seems to be working just fine. I also currently have all of the profiles having the internal network, and then the dmz network. Once we finalize testing with some of the apps I will be taking the dmz network from the majority of the blades except on 3 of them. Since the dmz blades will have both ethernet networks attached to it should this affect it to the point that it could fail the connection from internal to the blades that are outside. Keep in mind that the external blades will have both ethernet networks so in theory it seems like it would work. Just trying to get some suggestions thanks Jose