The Virtual Fabric feature of the Fabric OS is a perfect complement to device connection policies. Virtual Fabric is neither a new nor mandatory feature, but its implementation becomes nearly indispensable in the large, consolidated networks built on DCX.
In essence, with Virtual Fabric you can divide the physical fabric into isolated administrative domains (the analogy with Cisco's VSANs is too good to pass up), creating software borders that shelter each domain from its neighbors.
Another nice feature of Virtual Fabric is that the implementation of ADs (administrative domains) is granular and nondisruptive. For example, you can migrate all or part of an existing zone to a new AD and assign a device to multiple ADs.
In the large, consolidated environments that the DCX makes possible, the ability to assign separate administrative duties for an individual AD is also a great feature, because separation of duties facilitates independent domain updates and confines the impact of each change to that AD.
To prove that claim, I copied the same zone to two ADs, then assigned a different admin account to each. To create some traffic, I started Iometer on one host connected to the first domain. Next, to simulate a conflicting configuration change, I logged in as admin for the second domain and removed that host port from the zone.
Finally, I switched back to the host on the first domain: Iometer was still running, unaffected by the change made on the parallel AD.
Sharing devices across separate administrative domains is more likely to happen with storage targets than with host ports. However, the type of device shared by domains is irrelevant, because the principle is the same: Changes made on one administrative domain have no impact outside of its borders.
The last action item of my DCX evaluation was less spectacular, consisting simply of connecting a switch to the DCX and proving that the devices connected to that switch were readily available and usable in normal zones.
Usually connecting a switch to a fabric would be a rather boring and straightforward exercise, but the switch I had in mind was a McData 6140 working in native mode.
As McData customers know all too well, connecting McData switches in native mode to a Brocade fabric was not possible before Brocade's acquisition of McData. After seeing it work in practice, I am glad to say that it now can be done, at least for the 6140.
For details on which legacy devices are supported by the DCX, a good reference is the Brocade connectivity matrix.
Obviously there are some limitations when connecting legacy devices. For example, the old interoperability mode is now obsolete, replaced by two new modes: McData native (the mode I tested) and McData open. Further, according to Brocade those two modes work only when connecting devices running Fabric OS 6 and EOS 9.6.
Even with those limits, customers with McData-branded items should be in better shape regarding connectivity support than they were before the acquisition. However, note that features such as Top Talkers that query performance counters embedded in Brocade ASICs are not available for legacy devices.
The most difficult part of reviewing a complex product such as the DCX Backbone is deciding where to stop. In addition to being a fabric backbone, the DCX is a powerful switch. My evaluation skipped on some of the typical grinding you would challenge a switch with, in order to focus on the features that allow you to pull together a super-fabric of datacenter networks. So while the specs of the DCX are impressive both for performance and capacity, what I like most about the solution is the effort to bring more intelligence to the fabric.
As impressed as I was by my first experience with the DCX, it would be deceiving to think that future requirements would be satisfied by the cocktail of networking muscle and smart management tools that Brocade injected into this debut version. Nor is the shift in focus from storage fabric to datacenter network unique to Brocade. Cisco has been preaching the datacenter cult perhaps even longer than Brocade. Cisco's new switch targeting the datacenter, the Nexus 7000, released around the same time as the DCX, proves that Cisco is not conceding anything to Brocade.
In addition to faster connectivity -- for example, converging both native and Fibre Channel traffic on 40 Gigabit Ethernet and 100 Gigabit Ethernet via FCoE (Fibre Channel over Ethernet) -- the challenge ahead for these megahubs includes becoming good virtualization mates, offering more networking services such as encryption, and becoming easier to tame and control via policy management and ever more sophisticated rules. The rate limiting, QoS capability, and the initial, rudimentary attempt at enforcing security from the fabric are a promising beginning, but I can't help thinking that those features are -- must be -- only a first step, and that the best of the DCX intelligence is yet to come.