Review: Brocade DCX Backbone Part 2

Review: Brocade DCX Backbone Part 2

Welcome to the second part of my first peek at the new DCX Backbone from Brocade. If you haven’t already, please have a look at part 1 first.

How physical security is implemented in your data center certainly has its weight but, generally speaking, a larger installation such as what you can get consolidating multiple fabrics with DCX, is more vulnerable than a smaller one to trivial errors and to security breaks.

If you want to keep human errors to a minimum, or are concerned about the possibility of someone spoofing a WWN (world wide name) to connect a rogue device to the network, the DCX OS offers a system of policies that can bring some additional protection.

For example, you can define policies to control the connection of storage targets, switches and hosts, allowing access only when a device, identified by its WWN, is connected to a specific port.

The following screen image shows the commands to define a DCC policy for each of the two devices on ports 133 and 134 and to make those two policies actives.

For a large installation, manually setting a policy for each port could be a long and inefficient process, but for initial deployments a similar command can automatically create a policy from an existing configuration linking each active port to he WWN of its connected device.

However created, when a DCC policy is active, trying to connect a device with a different WWN will trigger an error message and access to the port will be denied.

The DCX security policies are not foolproof. Obviously anyone with access to an admin account with proper credentials can modify them, but the system offers an easy to audit log of possible violations, which can simplify monitoring and enforcement of those policies.

Speaking of security and administrative control, the Virtual Fabric feature of the OS is a perfect complement to device connection policies. Virtual Fabric is not a new nor a mandatory feature but its implementation becomes nearly indispensable in the large, consolidated networks backed by DCX.

In essence, with Virtual Fabric you can divide the physical fabric in isolated administrative domains (the analogy with Cisco’s VSANs is too good to pass on) creating software borders that shelter each domain from its neighbors.

Another nice feature of Virtual Fabric is that the implementation of AD (administrative domains) is granular and non-disruptive. For example, you can migrate all or part of an existing zone to a new AD and also assign a device to multiple ADs.

To prove that case scenario, I copied the same zone to two AD, and assigned a different admin account to each . To create some traffic, I then 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 its zone.

After making the changed zone active, I switched back to the host on the first domain: Iometer was still running, unaffected by the change made on the parallel domain.

Sharing devices across separate domains is more likely to happen with storage targets than with host ports. However, what device you overlap across 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 not as spectacular as other items in my test plan because it consisted in 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 predictable exercise, but that switch was a McData 6140 working in native mode, which made the test worthwhile.

As McData customers know all too well, switch connectivity in native mode to a Brocade fabric was not available before Brocade’s acquisition of McData . After seeing it work in practice, I am glad to say that connectivity of McData switches in native mode is possible now, at least for the 6140.

For more details on which other legacy devices are supported 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 and is replaced by two new modes: McData native, such as what I tested, and McData open. Also, 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 for connectivity than they were before the acquisition, although features such as Top Talkers that query performance counters embedded in Brocade ASICs, are not available for legacy devices.

Brocade DCX Backbone

Availability: Shipping

Pricing: Not disclosed

Verdict:

The most difficult part of reviewing a complex product such as the DCX Backbone is deciding where to stop. Before and in addition to being a fabric backbone, the DCX is a powerful switch. However, my evaluation had to skip on some of the typical grinding you would challenge a switch with, to focus on what makes more sense to have when you put together a super-fabric around the DCX.

I liked what I saw of the DCX, but I cannot make a judgment on its value because Brocade hasn’t divulged pricing info at the moment. I expect its price to be on the high side, if only because even a quarter million dollar (I am picking up this figure out of my hat) could be a reasonable price to pay to consolidate multi-million dollar fabrics.

The specs of the DCX are impressive both for performance and capacity, but what I like the most about the solution is the effort to bring more intelligence to the fabric.

QoS and the DCX initial, rudimentary attempt at enforcing security from the fabric are what I find most attractive, but can’t help thinking that those features are, must be, only a first step in that direction and that the best of the DCX intelligence is yet to come. Hopefully soon.