« Connectivity changes for April 2011 | Main | Enabling FIP Keep Alive on Brocade 8000 »



Feed You can follow this conversation by subscribing to the comment feed for this post.



First, full disclosuer, I work for Brocade.

Thanks for showing this implementation of FCoE isolation. As I look at this, I think an argument can be made that in a lot of ways the isolation afforded is reminiscent of the isolation achived when using FC routing with multiple FC fabrics. With FC routing, each fabric control plane (and zoning and other policies) remains independent so Mr. Murphy-based configuration errors can't propogate beyond a single fabric. A good thing.

For those reasons, FC routers, properly implemented, are seen as preserving the air gap architecture for fibre channel fabrics.
I'd appreciate your thoughts on that.

And, indeed simplifing configuration steps would be a virtue, so I'm interested in your experience with the Brocade VCS Ethernet fabric when you test that.



And one other point I forgot to add to my earlier comment. I think my argument about FC routing preserving the air gap for the control plane meant that FC routing preserved the the air gap design goal of more than one independent control plan for storage traffic.

IF you agree with that, AND, IF you further think your design for FCoE w/ vPC provides at least two independent control plans for FCoE traffic, then I'd say the title of your article would become "Emulating the SAN air gap for FCoE with vPC".

Last, can vPC support more than 2 switches as we can with FC Routing? If so, that would provide good scalability.

Erik Smith

Hi Brook, interesting point about FC Routing. I had originally considered including that concept to support my claim about vPC and VCS, but it opens a can of worms that I haven't fully thought through let alone tested in the lab.

If we are talking about a stand alone Brocade FC Router that contains EX_Ports, then with Brocade's implementation, I am fairly comfortable with the idea since the EX_Port was described to me by one of your Engineers' as a light E_Port that accepts configuration information from the fabric. Thinking about it now, the exceptions are probably SW_RSCNs and probably E_Port specific frames like HLO, etc but I'm sure you know more so than I. In any case, given that the EX_Ports aren't pushing configuration information to both fabrics, I'm OK with the idea but would want to get into the lab and validate before signing off on the idea completely.

With the other implementations, or when the routing capability is build into one or both of the switches that are participating in the fabric, I'm not ready to sign off on the concept yet. To be completely honest, my hesitation is due more to a lack of knowledge about the internals of Brocade's Integrated Routing and Cisco's IVR rather than specific knowledge about any particular problem. That having been said, I'd be open to the idea if either of them truly isolates the SANs from one another.

To answer your other questions, vPC is currently limited to two switches and I'm not sure if this will change or not going forward.

If we only disagree about the title of the blog post, I think we're in pretty good shape!!

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)


  • This is not an official EMC blog.
    The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.