Let it not be said that I don’t listen to my readership, a couple of weeks ago I tweeted that I had setup one of our in-house Cisco UCS pods to our Solutions Centre Brocade Virtual Cluster Switching (VCS) Ethernet Fabric. Well since then I have had several requests for info as to how it went.

So I thought I would do a short post detailing the setup and what I liked about it along with what I felt could be improved.

Now I’m not going into which fabric solution is the best or the pros and cons of each, that may well be the subject of a future post, once I have “the main three” stood up in our Solutions Centre and I can put them all through their paces. (The other two on my radar being Cisco FabricPath and Juniper QFabric)

Again this post will not cover the merits of Ethernet Fabrics, I’m sure if you have already read this far, you no doubt already know the benefits they promise.

As a side bar if you want to see a great debate on Ethernet Fabrics check out the Brocade Virtual Symposium by Packet Pushers and Tech Field day with great Tweeple like @etherealmind, @ioshints and @ECBanks along with Brocade Principal Engineer Chip Copper. Here.

So anyway the setup I have is drawn out below.

Solutions Centre VCS plus UCS

This UCS Pod runs alongside other pods which utilize Cisco Nexus 5000 switches, One Pod being a Vblock, these provide great baselines from which to establish performance statistics and comparrisons, which I shall provide as and when I can next get some time in the Lab.

OK, so on with the main topic of this post, what I liked and disliked about setting this up. The first task I did was to upgrade the Network Operating System (NOS) of the switches (Brocade VDX 6720’s) to the latest version (2.1.1a). This was as you would expect real easy and worked without any issues, only downside was it required a reboot of the switches, unlike an In-service software upgrade (ISSU) on the Nexus 5k’s.

The CLI was very familiar to an old Cisco guy like me which was very re-assuring and made navigating the NOS CLI really easy.

The Auto formation of the Brocade Trunks was great, no config at all required, the Switches just recognized that they have multiple links to the same switches and auto channeled them at hardware level.

The vLAG (LACP Software) Channels worked really well, giving all the benefits of VSS or vPC but without the limiation of only being able to channel from or to a single pair of switches.

Now for the best bit, in order to turn these 3 separate or “Classic Mode” Brocade VDX switches into an Ethernet Fabric “VCS Mode” took all of 1 line of code on each switch. Literally just set the RBridge ID (Think of this as the unique switch identifier, similar to a stack member in a Catalyst 3750 stack)and VCS ID and job done.

VDX6720-1# vcs rbridge-id 1 vcsid 1 enable

The ease and simplicity of setting up a Brocade VCS Fabric will no doubt be its main differentiator over the other Ethernet Fabric offerings along with its relatively low price point for full Ethernet Fabric functionality.

Now as mentioned I am an independent, and you will not find any vendors 30 pieces of Silver in my pockets, I just say what I like about a particular tech and what I don’t like about it. My “Man in the Pub” view on things, If you like.

So a quick rundown on what disappointed me about VCS:

• As already mentioned would like to see in service software upgrades, it’s what we now expect from an Enterprise class switch. Without having to rely on teaming and multi-pathing to maintain connectivity.

• Although once in VCS mode the fabric looks like a single switch (Again think 3750 stack) you still have to attach and configure the ports locally on every switch, I would like to see some sort of management cluster address that you can configure any port in the fabric from the one management point.

• vCenter integration, As you may know Brocade VCS integrates with VMware’s vCenter as does many other technologies these days. And having seen many technology roadmaps, everything seems to be converging to be managed by vCenter. So why is this in my dislike list you may be wondering? Well glad you asked. I have been a Networking guy for many many years and like most networking guys I did at first really dislike vSwitches as I lost control and visibility of my network edge, now being older and wiser and now understanding vSwitches a lot better than I did back then , I now kind of except them al-be-it as a necessary evil perhaps. Well with technologies like Cisco Nexus 1000v and VM-FEX the point of which is to give visibility and control of the network edge back to the Network Admins it just seems to me that allowing VMware administrators to create VLANs and Port-Groups and have them pushed into the VCS fabric is the wrong way round. I would much rather have the Network admin create the VLANs in the VCS Fabric and have them pushed into vCenter (ala VM-FEX). But hey let me know if you disagree.

Anyway this post was to give you my opinion on how I found setting up Cisco UCS with Brocade VCS. In short really easy and am liking what I am seeing from Brocade VCS. Can see why EMC have added Brocade VDX switches as an option in their VSPEX architecture.

Thanks Matt
I will have another go with the Twin-Ax cables, and have removed the reference to them not working for me in this post.
In looking at your output I see your Vendor is listed as “Brocade” and ActiveI was trying Cisco Passive Twin-Ax cables so maybe that was my issue will see if there is a VDX cable compatibility Matrix.
Regards
Colin

Though not technically supported, third-party TwinAx cables should work, as long as they’re active twinax. Passive twinax will definitely not work. For better results, use Brocade branded active twinax cables…

Hi Colin, great write up! I’m glad you put your two cents in or in your case, two pence! =) I suppose you went straight into your lab last April after our hands on lab in the Bracknell office to set this up in your Soluions Centre. =) Great job! Easy as pie, right?

Regarding the things you don’t like; no hot code load during firmware upgrade and the fact that the vCenter Integration is “backwards”. Valid points. The hot code load feature will be available as a NOS feature in a future release. As for the vCenter integration, via RBAC, a Network Admin or a VMware admin that the network guys trust can be the one to create the VLAN from vCenter. Perhaps it is backwards from your point of view but the fact that you no longer have to coordinate between Server and Network Admins should be a benefit. I think once you coordinate by designating someone that a Network guy trusts or even a Network guy himself, it doesn’t necessarily have to be backwards. We were just trying to make things easier.

Hi Earl
Hope you are well and thanks for the comments.
Glad to hear that an “in Service” upgrade is on the roadmap.
Seems like everything is converging on vCenter now-a-days so perhaps you guys are going down the right road after all. Remember I’m an old Cisco Guy who is very protective over who can do what on “My” Network :-)
VMwares aquisistion of Nicira will obviously increase the ammount of Network administration and control from within vCenter, and vCenter will likley become the single pane of glass for all “Virtual” Network administration. I know you guys are already well down the SDN / OpenFlow route so am very interested to see what VMware will offer us up out of this.
Keep in touch!
Colin