Today I want to explain why I think Brocade is not SDN ready. I spent lots of time into Brocade and gained lots of experience with their products the last months. I designed and implemented a 20 switches large Brocade VCS Ethernet Fabric, a traditional client access edge with Brocade ICX switches (500 ports) and an Internet Edge with Juniper MX routers and Juniper SRX firewalls.
If you spent a deeper look into Brocades products, you realize that the MLX series supports OpenFlow and NETCONF, the VDX series is multi-tenant capable and supports NETCONF, and last but not least there’s the vYatta Router, the product for NVF. Everything else is well-known, traditional ethernet gear and not SDN.
I want to talk about Brocade VDX and why I think this product doesn’t meet the SDN requirements.
What is SDN?
There’s no clear definition! In my humble opinion when we’re talking about SDN, we’re talking about rapid deployment/provisioning, multi-tenant capabilities, control-plane influence and automation. Let’s create a Q&A:
Can I deploy fast and automatically a Brocade VDX switch?
The Brocade VDX data sheets, tells you that you can Plug & Play a switch into the VCS Ethernet Fabric. That’s only the half-truth and it is only possible under certain conditions. You have to be sure that the new switch runs the same Network OS release as your existing VCS Ethernet Fabric. The rbridge-id should be unique, of course. And you have to install the VCS license prior joining the fabric. The same condition applies if you’re licensed Fibre Channel. And the last step is: Reset the switch to factory defaults! Otherwise your new switch won’t join the VCS Ethernet Fabric. Do you think this is PnP? Me not. On the other side, you even miss a puppet or similar plugin. Currently you’re not able to implement a simple (and automatic) deployment process.
Is a Brocade VCS Ethernet Fabric multi-tenant capable?
Yes, it is multi-tenant capable.
And that’s the big problem. The technology you need for multi-tenancy is Virtual-Fabric (Abbr.: VF) If you’re running a “legacy” Brocade VDX switch and a VF-capable switch in the same logical-chassis, you cannot enable VF!. Ouuppss… a legacy VDX switch? ;) Yes, you’re heard right. If you’re running a Brocade VDX 6710, 6720 or 6730 switch you have an outdated model. Currently nobody knows if NOS 5.x.x could run on this series. And the eAvin ASIC is not able to support VF and perhaps VXLAN, too. I’m not sure why the “old” series is outdated, but I have some ideas: Virtual Fabrics are defined with VLAN-IDs above 4095. I’m sure eAvin doesn’t supports Ethernet frames with this additional bit. On the other hand, the footprint of NOS is growing. The old generation of VDX switches has a PowerPC e500v2 control-plane/management processor and only 2 Gigs of RAM. Newer generations (VDX6740) running a PowerPC e500mc and 4 Gigs of RAM. The funny thing is: NOS is a 32-bit based OS and uses only 3 Gig of RAM. :)
Does Brocade VDX (VCS Ethernet Fabric) supports OpenFlow?
If you’re reading the Brocade datasheets, Brocade differs between OpenFlow-ready and OpenFlow-enabled. Every product can be OpenFlow-ready if my imagination is big enough. ;) But this is Bla-Bla ! And because I have no experience with OpenFlow I like to switch to the next step: NETCONF.
Can I automate and program a Brocade VCS Ethernet Fabric?
Brocade implemented a NETCONF based API. You can access a single switch and a VCS logical-chassis via NETCONF. In the time I designed our new network solution at work, a northbound API was a high priority requirement and because Brocade supports NETCONF, this requirement was satisfied. What a bad illusion! Yes, you can access a Brocade VDX switch via NETCONF, but it’s annoying slow. (Maybe a problem b/c of the earlier mentioned slow PowerPC processors or less RAM or 32bit caps.) I opened a case because the processing time to get the entire running-config took 15 minutes. In words: fifteen minutes. After two weeks waiting, the engineering told me, that’s the expected time! What??? That’s unbelievable! Today I upgraded our VCS Ethernet Fabric to NOS 4.1.0 (believe or not, the upgrade was funny, too) and I tried the NETCONF RPC again. Why? If you read the release notes you will mention a bug fix that says: Brocade improved the performance, when you’re doing a NETCONF get-config RPC call. The NETCONF call took 23 minutes. ;) More than before! I have no more words, sorry.
Brocades vision of SDN differs much of what Brocade is able to deliver. There’s a big difference between ready and enabled. And the worst thing is, you have to difference between enabled on paper and enabled in reality. Waiting 20 minutes to get the running config is not SDN. I studied the Brocade NETCONF documentation and two of three printed XML stances fails with an error. It’s annoying! And what about VXLAN VTEP? If you study carefully the datasheets this is a supported feature. But even the latest NOS 4.1.0a don’t know the command overlay-network. ;) Be careful! Brocade VDX and the VCS switch cluster is a rock solid and scalable Layer-2 Ethernet Fabric. But every feature above L2 has boundaries.