Our last presentation from Day 2 of Network Field Day 5 came from a relatively new company – Plexxi. I hadn’t really heard much from them before they signed up to present at NFD5. All I really knew was that they had been attracting some very high profile talent from the Juniper ranks. First Dan Backman (@jonahsfo) shortly after NFD4 then Mike Bushong (@mbushong) earlier this year. One might speculate that when the talent is headed in a certain direction, it might be best to see what’s going on over there. If only I had known the whole story up front.
Mat Mathews kicked off the presentation with a discussion about Plexxi and what they are doing to differentiate themselves in the SDN space. It didn’t take long before their first surprise was revealed. Our old buddy Derick Winkworth (@cloudtoad) emerged from his pond to tell us the story of why he moved from Juniper to Plexxi just the week before. He’d kept the news of his destination pretty quiet. I should have guessed he would end up at a cutting edge SDN-focused company like Plexxi. It’s good to see smart people landing in places that not only make them excited but give them the opportunity to affect lots of change in the emerging market of programmable networking.
Marten Terpstra jumped in next to talk about the gory details of what Plexxi is doing. In a nutshell, this all boils down to affinity. Based on a study done by Microsoft in 2009, Plexxi noticed that there are a lot of relationships between applications running in a data center. Once you’ve identified these relationships, you can start doing things with them. You can create policies that provide for consistent communications between applications. You can isolate applications from one another. You can even ensure which applications get preferential treatment during a network argument. Now do you see the SDN applications? Plexxi took the approach that there is more data to be gathered by the applications in the network. When they looked for it, sure enough it was there. Now, armed with more information, they could start crafting a response. What they came up with was the Plexxi Switch. This is a pretty standard 32-port 10GigE switch with 4 QSFP ports.. Their differentiator is the 40GigE uplinks to the other Plexxi Switches. Those are used to create a physical ring topology that allows the whole conglomeration to work together to create what looked to me like a virtual mesh network. Once connected in such a manner, the affinities between the applications running at the edges of the network can now begin to be built.
Plexxi has a controller that sits above the bits and bytes and starts constructing the policy-based affinities to allow traffic to go where it needs to go. It can also set things up so that things don’t go where they’re not supposed to be, as in the example Simon McCormack gives in the above video. Even if the machine is moved to a different host in the network via vMotion or Live Migration, the Plexxi controller and network are smart enough to figure out that those hosts went somewhere different and that the policy providing for an isolated forwarding path needs to be reimplemented. That’s one of the nice things about programmatic networking. The higher-order networking controllers and functions figure out what needs to change in the network and implements the changes either automatically or with a minimum of human effort. This ensures that the servers don’t come in and muck up the works with things like Dynamic Resource Scheduler (DRS) moves or other unforeseen disasters. Think about the number of times you’ve seen a VM with an anti-affinity rule that keeps it from being evacuated from a host because there is some sort of dedicated link for compliance or security reasons. With Plexxi, that can all be done automagically. Derick even showed off some interesting possibilities around using Python to extend the capabilities of the CLI at the end of the video.
If you’d like to learn more about Plexxi, you can check them out at http://www.plexxi.com. You can also follow them on Twitter as @PlexxiInc
Tom’s Take
Plexxi has a much different feel than many of the SDN products I’ve seen so far. That’s probably because they aren’t trying to extend an existing infrastructure with programmability. Instead, they’ve taken a singular focus around affinity and managed to tun it into something that looks to have some very fascinating applications in today’s data centers. If you’re going to succeed in the SDN-centric world of today, you either need to be front of the race as it is being run today, like Cisco and Juniper, or you need to have a novel approach to the problem. Plexxi really is looking at this whole thing from the top down. As I mentioned to a few people afterwards, this feels like someone reimplemented QFabric with a significant amount of flow-based intelligence. That has some implications for higher order handling that can’t be addressed by a simple fabric forwarding engine. I will stay tuned to Plexxi down the road. If nothing else, just for the crazy sock pictures.
Tech Field Day Disclaimer
Plexxi was a sponsor of Network Field Day 5. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 5. In addition, they also gave the delegates a Nerf dart gun and provided us with after hours refreshments. At no time did they ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.
Additional Coverage of Plexxi and Network Field Day 5
Brocade stepped up to the plate once again to present to the assembled delegates at Network Field Day 5. I’ve been constantly impressed with what they bring each time they come to the party. Sometimes it’s a fun demo. Other times its a great discussion around OpenFlow. With two hours to spend, I wanted to see how Brocade would steer this conversation. I could guarantee that it would involve elements of software defined networking (SDN), as Brocade has quietly been assembling a platoon on SDN-focused luminaries. What I came away with surprised even me.
Mike Schiff takes up the reigns from Lisa Caywood for the title of Mercifully Short Introductions. I’m glad that Brocade assumes that we just need a short overview for both ourselves and the people watching online. At this point, if you are unsure of who Brocade is you won’t get a feel for it in eight short minutes.
Curt Beckman started off with fifteen minutes of discussion about where the Open Networking Foundation (ONF) is concentrating on development. Because Curt is the chairman of the ONF, we kind of unloaded on him a bit about how the ONF should really be called the “Open-to-those-with-$30,000-to-spare Networking Foundation”. That barrier to entry really makes it difficult for non-vendors to have any say in the matters of OpenFlow. Indeed, the entry fee was put in place specifically to deter those not materially interested in creating OpenFlow based products from discussing the protocol. Instead, you have the same incumbent vendors that make non-OpenFlow devices today steering the future of the standard. Unlike the IETF, you can’t just sign up for the mailing list or show up to the meetings and say your peace. You have to have buy in, both literally and figuratively. I proposed the hare-brained idea of creating a Kickstarter project to raise the necessary $30,000 for the purpose of putting a representative of “the people” in the ONF. In discussions that I’ve had before with IETF folks they all told me you tend to see the same thing over and over again. Real people don’t sit on committees. The IETF is full of academics that argue of the purity of an OAM design and have never actually implemented something like that in reality. Conversely, the ONF is now filled with deep pocketed people that are more concerned with how they can use OpenFlow to sell a few more switches rather than now best to implement the protocol in reality. If you’d like to donate to an ONF Kickstarter project, just let me know and I’ll fire it up. Be warned – I’m planning on putting Greg Ferro (@etherealmind) and Brent Salisbury (@networkstatic) on the board. I figure that should solve all my OpenFlow problems.
The long presentation of this hour was all about OpenFlow and hybrid switching. I’ve seen some of the aspects of this in my day job. One of the ISPs in my area is trying to bring a 100G circuit into the state for Internet2 SDN-enabled links. The demo that I saw in their office was pretty spiffy. You could slice off any section of the network and automatically build a path between two nodes with a few simple clicks. Brocade expanded my horizons of where these super fast circuits were being deployed with discussions of QUILT and GENI as well as talking about projects across the ocean in Australia and Japan. I also loved the discussions around “phasing” SDN into your existing network. Brocade realizes that no one is going to drop everything they currently have and put up an full SDN network all at once. Instead, most people are going to put in a few SDN-enabled devices and move some flows to them at first both as a test and as a way to begin new architecture. Just like remodeling a house, you have to start somewhere and shore up a few areas before you can really being to change the way everything is laid out. That is where the network will eventually lead to being fully software defined down the road. Just realize that it will take time to get there.
Next up was a short update from Vyatta. They couldn’t really go into a lot of detail about what they were doing, as they were still busy getting digested by Brocade after being acquired. I don’t have a lot to say about them specifically, but there is one thing I thought about as I mulled over their presentation. I’m not sure how much Vyatta plays into the greater SDN story when you think about things like full API programmability, orchestration, and even OpenFlow. Rather than being SDN, I think products like Vyatta and even Cisco’s Nexus 1000v should instead be called NDS – Networking Done (by) Software. If you’re doing Network Function Virtualization (NFV), how much of that is really software definition versus doing your old stuff in a new way? I’ve got some more, deeper thoughts on this subject down the road. I just wanted to put something out there about making sure that what you’re doing really is SDN instead of NDS, which is a really difficult moving target to hit because the definition of what SDN really does changes from day to day.
Up next is David Meyer talking about Macro Trends in Networking. Ho-ly crap. This is by far my favorite video from NFD5. I can say that with comfort because I’ve watched it five times already. David Meyer is a lot like Victor Shtrom from Ruckus at WFD2. He broke my brain after this presentation. He’s just a guy with some ideas that he wants to talk about. Except those ideas are radical and cut right to the core of things going on in the industry today. Let me try to form some thoughts out of the video above, which I highly recommend you watch in its entirety with no distractions. Also, have a pen and paper handy – it helps.
David is talking about networks from a systems analysis perspective. As we add controls and rules and interaction to a fragile system, we increase the robustness of that system. Past a certain point, though, all those extra features end up harming the system. While we can cut down on rules and oversight, ultimately we can’t create a truly robust system until we can remove a large portion of the human element. That’s what SDN is trying to do. By allowing humans to interact with the rules and not the network itself you can increase the survivability of the system. When we talk about complex systems, we really talk about increasing their robustness while at the same time adding features and flexibility. That’s where things like SDN come into the discussion in the networking system. SDN allows us to constrain the fragility of a system by creating a rigid framework to reduce the complexity. That’s the “bow tie” diagram about halfway in. We have lots of rules and very little interaction from agents that can cause fragility. When the outputs come out of SDN, the are flexible and unconstrained again but very unlikely to contribute to fragility in the system. That’s just one of the things I took away from this presentation. There are several more that I’d love to discuss down the road once I’ve finished cooking them in my brain. For now, just know that I plan on watching this presentation several more times in the coming weeks. There’s so much good stuff in such a short time frame. I wish I could have two hours with David Meyer to just chat about all this crazy goodness.
If you’d like to learn more about Brocade, you can check out their website at http://www.brocade.com. You can also follow them on Twitter as @BRCDcomm
Tom’s Take
Brocade gets it. They’ve consistently been running in the front of the pack in the whole SDN race. They understand things like OpenFlow. They see where the applications are and how to implement them in their products. They engage with the builders of what will eventually become the new SDN world. The discussions that we have with Curt Beckman and David Meyer show that there are some deep thinkers that are genuinely invested in the future of SDN and not just looking to productize it. Mark my words – Brocade is poised to leverage their prowess in SDN to move up the ladder when it comes to market share in the networking world. I’m not saying this lightly either. There’s an adage attributed to Wayne Gretskey – “Don’t skate where the puck is. Skate where the puck is going.” I think Brocade is one of the few networking companies that’s figured out where the puck is going.
Tech Field Day Disclaimer
Brocade was a sponsor of Network Field Day 5. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 5. In addition, Brocade provided a USB drive of marketing material and two notepads styled after RFC 2460. At no time did they ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.
I’ve had the good fortune to be involved with Aerohive Networks ever since Wireless Field Day 1. Since then, I’ve been present for their launch of branch routing. I’ve also convinced the VAR that I work for to become a partner with them, as I believe that their solutions in the wireless space are of great benefit to my customer base. It wasn’t long ago that some interesting rumors started popping up. I noticed that Aerohive started putting out feelers to hire a routing and switching engineer. There was also a routing and switching class that appeared in the partner training list. All of these signs pointed to something abuzz on the horizon.
Today, Aerohive is launching a couple of new products. The first of these is the aforementioned switching line. Aerohive is taking their expertise in HiveOS and HiveManager and placing it into a rack with 24 cables coming out of it. The idea behind this came when they analyzed their branch office BR100 and BR200 models and found that a large majority of their remote/branch office customers needed more than the 4 switch ports offered in those models. Aerohive had a “ah ha” moment and decided that it was time to start making enterprise-grade switches. The beauty of having a switch offering from a company like Aerohive is that the great management software that is already available for their existing products is now available for wired ports as well. All of the existing polices that you can create through HiveManager can now be attached to an Aerohive switch port. The GUI for port role configuration is equally nice:
In addition, the management dashboard has been extended and expanded to allow for all kinds of information to be pulled out of the network thanks to the visibility that HiveManager has. You can also customize these views to your heart’s content. If you frequently find yourself needing to figure out who is monopolizing your precious bandwidth, you’ll be happy with the options available to you.
The first of three switch models, the SR2024, is available today. It has 24 GigE ports, 8 PoE+ ports, 4 GigE uplinks, and a single power supply. In the coming months, there will be two additional switches that have full PoE+ capability across 24 and 48 ports, redundant power supplies, and 10 GigE SFP+ uplinks. For those that might be curious, I asked Abby Strong about the SFPs, and Aerohive will allow you to use just about anyone’s SFPs. I think that’s a pretty awesome idea.
The other announcement from Aerohive is software based. One of the common things that is seen in today’s wireless networks is containment of application traffic via multiple SSIDs. If you’ve got management users as well as end users and guests accessing your network all at once, you’ve undoubtedly created policies that allow them to access information differently. Perhaps management has unfettered access to sites like Facebook while end users can only access it during break hours. Guests are able to go where they want but are subject to bandwidth restrictions to prevent them from monopolizing resources. In the past you would need three different SSIDs to accomplish something like this. Having a lot of broadcasted SSIDs causes a lot of wireless congestion as well as user confusion and increased attack surface. If only there was a way to have visibility into the applications that the users are accessing and create policies and actions based on that visibility.
Aerohive is also announcing application visibility in the newest HiveOS and HiveManager updates. This allows administrators to peer deeply into the applications being used by users on the network and create policies on a per-user basis to allow or restrict them based on various criteria. These policies follow the user through the network up to and including the branch office. Later in the year, Aerohive will port these policies to their switching line. However, when you consider that the majority of the users today are using mobile devices first and foremost, this is where the majority of the visibility needs to be. Administrators can provide user-based controls and reporting to identify bandwidth hogs and take appropriate action to increase bandwidth for critical applications on the fly. This allows for the most flexibility for both users and administrators. In truth, it’s all the nice things about creating site-wide QoS policies without all the ugly wrench turning involved with QoS. How could you not want that?
Tom’s Take
Aerohive’s dip into the enterprise switching market isn’t all that shocking. They seem to be taking a page from Meraki and offering their software platform on a variety of hardware. This is great for most administrators because once you’ve learned the software interface and policy creation, porting it between wired switch ports and wireless APs is seemless. That creates an environment focused on solving problems with business decisions, not on problems with configuration guides. The Aerohive switches are never going to outperform a Nexus 7000 or a Catalyst 4500. For what they’ve been designed to accomplish in the branch office, however, I think they’ll fit the bill just fine. And that’s something to be buzzing about.
Disclaimer
Aerohive provided a briefing about the release of these products. I spoke with Jenni Adair and Abby Strong. At no time did Aerohive or their representatives ask for any consideration in the writing of this post, nor were they assured of any of the same. All of the analysis and opinions represented herein are mine and mine alone.
It’s 3 am. You’ve just finished installing your new Catalyst switches into the rack and you’re ready to turn them up and complete your cutover. You’ve been fighting for months to get the funding to get these switches so your servers can run at full gigabit speed. You had to cut some corners here and there. You couldn’t buy everything new, so you’re reusing as much of your old infrastructure as possible. Thankfully, the last network guy had the foresight to connect the fiber backbone at gigabit speeds. You turn on your switches and wait for the interminably long ASIC and port tests to complete. As you watch the console spam scroll up on your screen, you catch sight of something that makes your blood run cold:
%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port 65586 has bad crc
%PM-4-ERR_DISABLE: gbic-invalid error detected on Gi1/0/50, putting Gi1/0/50 in err-disable state
Huh?!? Why aren’t my fiber connections coming up? Am I going to have to roll the install back? What is going on here?!?
You will see this error message if you have a third party SFP inserted into the Catalyst switch. While Cisco (and many others) OEM their SFP transceivers from different companies, they all have a burned-in chip that contains info such as serial number, vendor ID, and security info like a Cyclic Redundancy Check (CRC). If any of this info doens’t match the database on the switch, the OS will mark the SFP as not supported and disable the port. The fiber connection won’t come up and you’ll find yourself screaming at terminal window at 3:30 in the morning.
Why do vendors do this? Some claim it’s vendor lock in. You are stuck ordering your modules from the vendor at an inflated cost instead of buying them from a different source. Others claim it’s to help TAC troubleshoot the switch better in case of a failure. Still others say that it’s because the manufacturing tolerances on the vendor SFPs is much better than the third party offerings, even from the same OEM. I don’t have the answer, but I can tell you that Cisco, HP, Dell, and many others do this all the time.
HP is the most curious case that I’ve run into. Their old series A SFP modules (HP calls them mini-GBICs) didn’t even have an HP logo. They bore the information from Finisar, an electroics OEM. The above scenario happened to me when I traded out a couple of HP 2848 swtiches for some newer 2610s. The fiber ports locked up solid and would not come alive for anything. I ended up putting the old switches back in place as glorified fiber media converters until I figured out that new SFPs were needed. While not horribly expensive, it did add a non-trivial cost to my project, not to mention all the extra hours of troubleshooting and banging my head against a wall.
Cisco has an undocumented and totally unsupported solution to this problem. Once you start getting the console spam from above, just enter these commands:
service unsupported-transceiver
no errdisable detect cause gbic-invalid
These commands are both hidden, so you can’t ? them. When you enter the first command, you get the Ominous Warning Message of Doom:
Warning: When Cisco determines that a fault or defect can be traced to the use of third-party transceivers installed by a customer or reseller, then, at Cisco’s discretion, Cisco may withhold support under warranty or a Cisco support program. In the course of providing support for a Cisco networking product Cisco may require that the end user install Cisco transceivers if Cisco determines that removing third-party parts will assist Cisco in diagnosing the cause of a support issue.
It goes without saying that calling TAC with a non-Cisco SFP in the slot is going to get you an immediate punt or request to remove said offending SFP. You’ll likely argue that your know the issue isn’t with the SFP that was working just fine an hour ago. They will counter with not being able to support non-Cisco gear. You’ll complain that removing the SFP will create additional connectivity issues and eventually you’ll hang up in frustration. So, don’t call TAC if you use this command. In fact, I would counsel that you should only use this command as a short term band-aid to get your out of the data center at 3 am so you can order genuine SFPs the next morning. Sadly, I also know how budgets work and how likely you are to get several hundred dollars of extra equipment you “forgot” to order. So caveat implementor.
There’s no denying that The Cloud is an omnipresent fixture in our modern technological lives. If we aren’t already talking about moving things there, we’re wondering why it’s crashed. I don’t have any answers about these kinds of things, but thankfully the people at Cisco have been trying to find them. They let me join in on a briefing about the announcements that were made today regarding some new additions to their data center switching portfolio more commonly known by the Nexus moniker.
Nexus 6000
The first of the announcements is around a new switch family, the Nexus 6000. The 6000 is more akin to the 5000 series than the 7000, containing a set of fixed-configuration switches with some modularity. The Nexus 6001 is the true fixed-config member of the lot. It’s a 1U 48-port 10GbE switch with 4 40GbE uplinks. If that’s not enough to get your engines revving, you can look at the bigger brother, the Nexus 6004. This bad boy is a 4U switch with a fixed config of 48 40GbE ports and 4 expansion modules that can double the total count up to 96 40GbE ports. That’s a lot of packets flying across the wire. According to Cisco, those packets can fly at a 1 microsecond latency port-to-port. The Nexus 6000 is also an Fibre Channel over Ethernet (FCoE) switch, as all Nexus switches are. This one is a 40GbE-capable FCoE switch. However, as there are no 40GbE targets available in FCoE right now, it’s going to be on an island until those get developed. A bit of future proofing, if you will. The Nexus 6000 also support FabricPath, Cisco’s TRILL-based fabric technology, along with a large number of multicast entries in the forwarding table. This is no doubt to support VXLAN and OTV in the immediate future for layer 2 data center interconnect.
The Nexus line also gets a few little added extras. There is going to be a new FEX, the 2248PQ, that features 10GbE downlink ports and 40GbE uplink ports. There’s also going to be a 40GbE expansion module for the 5500 soon, so your DC backbone should be able to run a 40GbE with a little investment. Also of interest is the new service module for the Nexus 7000. That’s right, a real service module. The NAM-NX1 is a Network Analysis Module (NAM) for the Nexus line of switches. This will allow spanned traffic to be pumped though for analysis of traffic composition and characteristics without taking a huge hit to performance. We’ve all known that the 7000 was going to be getting service modules for a while. This is the first of many to roll off the line. In keeping with Cisco’s new software strategy, the NAM also has a virtual cousin, not surprising named the vNAM. This version lives entirely in software and is designed to serve the same function that its hardware cousin does only in the land of virtual network switches. Now that the Nexus line has service modules, kind of makes you wonder what the Catalyst 6500 has all to itself now? We know that the Cat6k is going to be supported in the near term, but is it going to be used as a campus aggregation or core? Maybe as a service module platform until the SMs can be ported to the Nexus? Or maybe with the announcement of FabricPath support for the Cat6k this venerable switch will serve as a campus/DC demarcation point? At this point the future of Cisco’s franchise switch is really anyone’s guess.
Nexus 1000v InterCloud
The next major announcement from Cisco is the Nexus 1000v InterCloud. This is very similar to what VMware is doing with their stretched data center concept in vSphere 5.1. The 1000v InterCloud (1kvIC) builds a secure layer 2 GRE tunnel between your private could and a provider’s public could. You can now use this tunnel to migrate workloads back and forth between public and private server space. This opens up a whole new area of interesting possibilities, not the least of which is the Cloud Services Router (CSR). When I first heard about the CSR last year at Cisco Live, I thought it was a neat idea but had some shortcomings. The need to be deployed to a place where it was visible to all your traffic was the most worrisome. Now, with the 1kvIC, you can build a tunnel between yourself and a provider and use CSR to route traffic to the most efficient or cost effective location. It’s also a very compelling argument for disaster recovery and business continuity applications. If you’ve got a category 4 hurricane bearing down on your data center, the ability to flip a switch and cold migrate all your workloads to a safe, secure vault across the country is a big sigh of relief.
The 1kvIC also has its own management console, the vNMC. Yes, I know there’s already a vNMC available from Cisco. The 1kvIC version is a bit special thought. It not only gives you control over your side of the interconnect, but it also integrates with the provider’s management console as well. This gives you much more visibility into what’s going on inside the provider instances beyond what we already have from simple dashboards or status screens on public web pages. This is a great help when you think about the kinds of things you would be doing with intercloud mobility. You don’t want to send your workloads to the provider if an engineer has started an upgrade on their core switches on a Friday night. When it comes to the cloud, visibility is viability.
CiscoONE
In case you haven’t heard, Cisco wants to become a software company. Not a bad idea when hardware is becoming a commodity and software is the home of the high margins. Most of the development that Cisco has been doing along the software front comes from the Open Network Environment (ONE) initiative. In today’s announcement, CiscoONE will now be the home for an OpenFlow controller. In this first release, Cisco will be supporting OpenFlow and their own OnePK API extensions on the southbound side. On the northbound side of things, the CiscoONE Controller will expose REST and Java hooks to allow interaction with flows passing though the controller. While that’s all well and good for most of the enterprise devs out there, I know a lot of homegrown network admins that hack together their own scripts through Perl and Python. For those of you that want support for your particular flavor of language built into CiscoONE, I highly recommend getting to their website and telling them what you want. They are looking at adding additional hooks as time goes on, so you can get in on the ground floor now.
Cisco is also announcing OnePK support for the ISR G2 router platform and the ASR 1000 platform. There will be OpenFlow support on the Nexus 3000 sometime in the near future, along with support in the Nexus 1000v for Microsoft Hyper-V and KVM. And somewhere down the line, Cisco will have a VXLAN gateway for all the magical unicorn packet goodness across data centers that stretch via non-1kvIC links.
Tom’s Take
The data center is where the dollars are right now. I’ve heard people complain that Cisco is leaving the enterprise campus behind as they charge forward into the raised floor garden of the data center. These are the people driving the data that produces the profits that buy more equipment. Whether it be massive Hadoop clusters or massive private cloud projects, the accounting department has given the DC team a blank checkbook today. Cisco is doing its best to drive some of those dollars their way by providing new and improved offerings like the Nexus 6000. For those that don’t have a huge investment in the Nexus 7000, the 6000 makes a lot of sense as both a high speed core aggregation switch or an end-of-row solution for a herd of FEXen. The Nexus 1000v InterCloud is competing against VMware’s stretched data center concept in much the same way that the 1000v itself competes against the standard VMware vSwitch. WIth Nicira in the driver’s seat of VMware’s networking from here on out, I wouldn’t be shocked to see more solutions that come from Cisco that mirror or augment VMware solutions as a way to show VMware that Cisco can come up with alternatives just as well as anyone else.
The final Network Field Day 4 (NFD4) presentation was from Juniper. Juniper has been a big supporter of Tech Field Day so getting to see some of their newest technology and advances was just another step in the the wonderful partnership. We arrived Friday afternoon to a very delicious lunch before settling in for the four hour session.
We were introduced to one of our own, Derick Winkworth (@cloudtoad). Derick was a delegate and NFD2 and has recently come to Juniper as the PM of Automation. It’s always nice to see someone from Tech Field Day in front of us for the vendor. Some have said that the vendors are stealing away members of the Field Day community, but I see it more as the vendors realizing the unique opportunity to bring someone on board the “gets it.” However, I couldn’t let Derick off the hook quite that easily. At Cisco Live, Derick proved his love for Dave Ward of Cisco by jumping up during Dave’s OnePK panel and throwing a pair of men’s briefs at him with “I ❤ Dave” written on the back. Lots of laughs were had by all, and Dave seemed appreciative of his gift. Once I learned the Derick was presenting first for NFD4, I hatched my own fan boy plot. When Derick walked up front to face the NFD delegates as “the enemy,” I too proved my love for the Cloud Toad by jumping up and tossing him a pair of underwear as well. These were adorned with “I ❤ @cloudtoad” to show Derick that he too has groupies out there.
Derick then proceeded to give us a small overview of the decision he made to join Juniper and the things that he wanted to improve to make everyone’s life a bit better. I can tell the Derick is genuinely pumped about his job and really wants to make a difference. If someone is that excited about going to work every day, it really doesn’t matter if it’s for a vendor or a VAR or even a garbageman. I only wish that half the people I work with had the same passion for their jobs as Derick.
Our first presentation was a bit of a surprise. We got a first hand look at storage from Simon Gordon. Yes, Juniper shook things up by making their first peek all about hard drives. Okay, so maybe it was more about showing how technologies like QFabric can help accelerate data transfers back and forth across your network. The two storage people in the room seemed fascinated by the peek into how Juniper handled these kinds of things. I was a bit lost with all the terminology and tried to keep up as best I could, but that’s what the recorded video archive is for, right? It’s no surprise that Juniper is pitching QFabric as a solution for the converged data center, just like their competitors are pitching their own fabric solutions. It just reminds me that I need to spend some more time studying these fabric systems. Also, you can see here where the demo gremlins bit the Juniper folks. It seemed to happen to everyone this time around. The discussion, especially from Colin McNamara (@colinmcnamara) did a great job of filling the time where the demo gremlins were having their fun.
The second presentation was over Virtual Chassis, Juniper’s method of stacking switches together to unify control planes and create managment simplicity. The idea is to take a group of switches and interconnect the backplanes to create high throughput while maintaining the ability to program them quickly. The technology is kind of interesting, especially when you extend it toward something like QFabric to create a miniature version of the large fabric deployment. However, here is where I get to the bad guy a bit… Juniper, while this technology is quite compelling, the presentation fell a bit flat. I know that Tech Field Day has a reputation for chewing up presenters. I know that some sponsors are afraid that if they don’t have someone technical in front of the group that bedlam and chaos will erupt. That being said, make sure that the presenter is engaging as well as technical. I have nothing but respect for the presenter and I’m sure he’s doing amazing things with the technology. I just don’t think he felt all the comfortable in front of our group talking about it. I know how nervous you can be during a presentation. Little things like demo failures can throw you off your game. But in the end, a bad presentation can be saved by a good presenter. A good presentation can take a hit from a less-than-ideal presenter. Virtual chassis is a huge talking point for me. Not only because it’s the way that the majority of my customers will interconnect their devices. Not because it’s a non-proprietary connector way to interconnect switches. It’s because Virtual Chassis is the foundation for some exciting things (that may or may not be public knowledge) around fabrics that I can’t wait to see.
Up next was Kyle Adams with Mykonos. They are a new acquistion by Juniper in the security arena. They have developed a software platform that provides a solution to the problem of web application security. Mykonos acts like a reverse proxy in front of your web servers. When it’s installed, it intercepts all of the traffic traveling to your Internet-facing servers and injects a bit of forbidden fruit to catch hackers. Things like fake debug codes, hidden text fields, and even phantom configuration files. Mykonos calls these “tar pits” and they are designed to fool the bad guys into a trail of red herrings. Becauase all of the tar pit data is generated on the fly and injected into the HTTP session, no modification of the existing servers is necessary. That is the piece that had eluded my understanding up until this point. I always thought Mykonos integrated into your infrastructure and sprayed fake data all over your web servers in the hope of catching people trying to footprint your network. Realizing now that it does this instead from the network level, it interesting to see the approaches that Mykonos can take. The tar pit data is practically invisible to the end user. Only those that are snooping for less-than-honorable intentions may even notice it. But once they take the bait and start digging a bit deeper, that’s when Mykonos has them. The software then creates a “super cookie” on the system as a method of identifying the attacker. These super coookes are suprisingly resilient, using combinations of Java and Flash and other stuff to stay persistent even if the original cookie is deleted. Services like Hulu and Netflix use them to better identify customers. Mykonos uses them to tie attacker sessions together and collect data. There are some privacy concerns naturally, but that is a discussion for a different day. Once Mykonos has tagged you, that’s when the countermeasures can start getting implemented.
I loved watching this in demo form. Mykonos randomly selects a response based on threat level and deploys it in an effort to prevent the attacker from compromising things. Using methods such as escalting network latency back to the attacker or creating fake .htacess files with convincingly encrypted usernames and passwords, Mykonos sets the hook to reel in the big fish. While the attacker is churning through data and trying to compromise what he thinks is a legitimate security hole, Mykonos is collecting data the whole time to later identify the user. That way, they can either be blocked from accessing your site or perhaps even prosecuted if desired. I loved the peek at Mykonos. I can see why Christofer Hoff (@beaker) was so excited to bring them on board. This refreshing approach to web application firewalls is just crazy enough to work well. As I said on the video, Mykonos is the ultimate way to troll attackers.
The final presentation at Juniper once again starred Derick Winkworth along with Dan Backman. Dan had presented over workflow automation at NFD2. Today, they wanted to talk about the same topic from a slightly different perspective. Derick took the helm this time and started off with a hilarious description of the land of milk and honey and unicorns, which according to him was representitive of what happens when you can have a comfortable level of workflow automation. It’s also where the title of this post came from. As you can tell from the video, this was the best part of having a former delegate presenting to us. He knew just how to keep us in stitches with all his whiteboarding and descriptions. After I was done almost spitting my refreshments all over my laptop, he moved on to his only “slide”, which was actually a Visio diagram. I suppose this means that Derick has entered the Hall Of Slideless TFD Presenters. His approach to workflow automation actually got me a bit excited. He talked less about scripting commands or automating configuration tasks and instead talked about all the disparate systems out there and how the lack of communication between them can cause the silo effect present in many organizations to amplify. I like Derick’s approach to using Junos to pull information in from various different sources to help expedite things like troubleshooting or process execution. Leveraging other utilities like curl helps standardize the whole shooing match without reinventing the wheel. If I can use the same utilities that I’ve always used, all my existing knowledge doesn’t become invalidated or replaced. That really speaks to me. Don’t make me unlearn everything. Give me the ability to take your product and use additional tools to do amazing things. That, to me, is the essence of SDN.
If you’d like to learn more about the various Juniper products listed above, be sure to visit their website at http://www.juniper.net. You can also follow their main Twitter account as @JuniperNetworks.
Tom’s Take
Juniper’s doing some neat things from what they showed us at NFD4. They appear to be focusing on fabric technology, both from the QFabric converged networking overview and even the Virtual Chassis discussion. Of course, protecting things is of the utmost importance, so Mykonos can prevent the bad guys from getting the goods in a very novel way. Uniting all of this is Junos, the single OS that has all kinds of capabilities around SDN and now OpenFlow 1.3. Sure, the demo gremlins hit them a couple of times, but they were able to keep the conversation going for the most part and present some really compelling use cases for their plans. The key for Juniper is to get the word out about all their technology and quit putting up walls that try and “hide” the inner workings of things. Geeks really like seeing all the parts and pieces work. Geeks feel a lot more comfortable knowing the ins and outs of a process. That will end up winning more converts in the long run than anything else.
Tech Field Day Disclaimer
Juniper was a sponsor of Network Field Day 4. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 4. In addition, Juniper provided me with a hooded sweatshirt with the Juniper logo and some “I Wish This Ran Junos” stickers. They did not ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.
The first presentation of the final day of Network Field Day 4 brought us to the mothership on Tasman Drive. The Cisco Borderless team had a lineup of eleven different presenters ready to show us everything they had. For those of you not familar with the term, Borderless Networks inside Cisco essentially means “everything that isn’t data center or voice.” Yeah, that means routing and switching and security and wireless and everything else. That also meant that we got a very diverse group of people presenting to us and a lot of short twenty minute videos of their products. In a way, it’s very much like speed dating. With little time to get the point across, you tend to shed the unnecessary pleasantries and get right to the important stuff.
First up was the UCS team with new E-series servers. These are blades that are designed to slide into a ISR G2 router and provide a full-featured x86 platform. It’s a great idea in search of an application. I can still remember the AxP modules and how they were going to change my life. That never really materialized. The payoff use case that you are looking for is the second video above. Cisco is starting to push for the idea that you can contain a whole branch office in a single router and run not only the phone system and networking routing and VPN, but now a light-duty server as well. I’m not sure how many people will be looking to do that with virtualized server resources residing in the data center, but there was some discussion of using this a temporary failover type of environment to push the branch server to the edge in the event of some kind of disaster or outage. That might work better to me that running the entire branch on the router. Of course, as you can tell, the demo gremlins found Cisco as well.
The next presentation was the new darling Cloud Services Router (CSR) 1000v. This little gem got some face time on stage with John Chambers at Cisco Live this year. It’s a totally virtualized router (hence the “v”) that can move workloads into the cloud when needed. I’m really curious as to why this is included with Borderless, as this is a very data center specific play right now. I know that Cisco is pushing this device currently as a VPN concentrator or MPLS endpoint for WAN aggregation. It makes more sense from some of their diagrams to have it running inside a cloud provider network carving up user space. I’m going to keep an eye on this one to see where the development goes.
Now, we get to something fun. Cisco FlexVPN is what happens when someone finally took a look at all the different methods for configuring VPNs on the various Cisco devices and said “WTF?!?” FlexVPN utilizes IKEv2 to help speed configuration. You can watch the short video and see all the stuff that we have to deal with to configure a VPN today. Cisco finally took our complaints to heart and made things a lot more simple. Of course there are drawbacks, and with FlexVPN that means it only works with IKEv2. There’s no backwards compatibility. Of course, if you’re going to have to be migrating everything anyway, you might as well make a clean break and rebuild it right. That’s going to make things like hub-and-spoke VPN configuration a whole lot less painful in the near future. Props to Cisco for fixing a pain point for us.
Okay, so maybe a I lied just a bit. Since Cisco Unified Border Element runs on a router (even though it’s technically voice), we got a presentation about it! I was in hog heaven here. If you are looking at deploying a SIP trunk, you had better be looking at a CUBE box to handle the handoff. Don’t think, just do it. Listen to the voice of Amy Arnold (@amyengineer) and Erik Peterson (@ucgod). You need this. You just don’t know how much until you start banging your head against a wall.
More Voice!!! By this point, I was practically crying tears of joy. Two voice presentations in one day. At a networking event no less! This presentation on enhanced SRST shows how big of kludge SRST really is. I’m not a huge fan of it, but I have to configure it to be sure that the phone systems work correctly in the event of a WAN outage. It’s all still CLI and very annoying to configure and keep in sync. Thankfully, with the ESRST manager highlighted in the video above, we can keep those configurations in sync and even have it automagically pull the necessary configurations out of CUCM. This software runs on a Service Engine right now in the router, but I can’t wait to see if Cisco ports it to a virtual setup to run under a CUCMBE 6000 server or even on a UCS-E blade down the road. Anything that I can do to make SRST less painful is a welcome change.
Okay, this had to be one of the more interesting presentations I’ve been involved in at an NFD event. We got our AppNav presentation over Webex from a remote resource. I know this a hot thing to do at Cisco offices to make sure we have the most talented people giving us the most up-to-date info about a particular subject. However, I expect this when I’m in the middle of nowhere Oklahoma, not at the mothership in San Jose. The Webex cut out now and then and there were times when we had to strain to hear what was being said in the room. Looking back at the video, I marvel that the room mikes picked up as much as they did. As for AppNav itself, it’s a virtual DC version of the Wide Area Application Services (WAAS). My grasp of WAN acceleration isn’t as good as it should be, even from Infineta back at NFD3. There’s some good info in here I’m sure. I’m just going to have to go back and digest it to see where it fits into my needs.
Now it’s time for some switching talk. We got a roadmap on the Catalyst line. There are some interesting tidbits in the slides, such as a monster 9000W power supply for the 4500 to support UPoE (more on that in a minute). The 4500 is also going to get VSS support and ISSU support. Those two things alone are going to make me start considering the use of the 4500 in the core of most of my smaller networks. The fixed configuration Catalyst switches also have some nice roadmaps, including UPoE support and lots of IPv6 enhancements. As I move forward in 2013, I’m planning on doing a lot with IPv6, so knowing that I’m going to have switching support behind me is a nice comfort. Of all the updates, the most talked about one was probably the Catalyst 6500. A switch that has been rumored to be on the chopping block for many years now, the venerable Cat6K is getting more updates, including FabricPath support and 100Gig module support. I think this switch may outlast my networking career at this rate. There are lots of rumors as to why Cisco is renovating this campus core stalwart once more, but it’s clear that they are attempting to squeeze as much life out of it as they can right now. To me, the idea of stretching FabricPath down into the campus presents some very tantalizing opportunities to finally get rid of spanning tree on all but the user-facing links. Let’s hope that the Cat6k sticks around long enough to get a gold watch and a nice pension for all the work it’s given us over the years.
Our next discussion was around security and using Cisco TrustSec to do things a little differently that we’re used to. By now, I think everyone has talked your ear off about BYOD. Even I’ve done it a couple of times. It’s a real issue for people in the dark security caves because our traditional methods of access lists and so forth don’t work the same way when you’ve got employees bringing their own laptops or asking you to give them access to data from tablets or phones. What this has morphed into is a need to do more role-based authorization. That’s what TrustSec means to me. Of course, a lot of previous attempts to do this, like NAC, haven’t really hit the mark or have been so convoluted that it was almost impossible to get them working correctly. Today, Cisco has rolled all the functionality of NAC and ACS into the Identity Services Engine (ISE). I’ve had a very brief encounter with ISE, so I know it has a lot of potential. I want to see how Cisco will incorporate it into the bigger TrustSec picture to make everything work across my various platforms.
Time to turn up the juice. Cisco brought out Universal Power over Ethernet (UPoE), which is their solution to pump up to 60 watts of power across a standard Ethernet cable to power…well, whatever it is that eats 60w of power. Cisco’s doing this by taking 802.3at PoE+, which can pump 30w down the cable, and pushing an additional 30w of power down the other unused pairs. Interestingly, Cisco talked to the people behind the ISO and EIA/TIA standards and found that when you have a bunch of unstructured cables running about around 50 watts (which is the 60w number above minus cable loss), you get a temperature in the cable bundle about 8-10 degrees above the ambient room temperature. In reality, this means that 60w is the max amount of power you’re likely to ever get out of a Cat5e cable unless you chill it or have some kind of new material that can reduce the heating effect. Cisco seems to be targeting UPoE to drive things like monitors, thin client desktops, and even those crazy command center touch pads that you see littered across the floor of a trading house or stock exchange. This last item really makes me believe that UPoE is going to be positioned in the same vein as the ultra-low latency Nexus 3548 – financial markets. Thin clients and command center touch panels are likely to be the kind of mission-critical devices these companies are willing to pay big buck to power. With the above-mentioned 9000w PS for the Catalyst 4500, you can see why we’re going to soon need to put a nuclear reactor in to drive these things.
Cisco Smart Operations dropped by to talk to us about Cisco Smart Install. This is the feature that I tend to turn off when I see it by the telltale sign of “Error opening tftp://255.255.255.255/network-config.” The Smart Operations team is doing its best to create an environment where an IT department that doesn’t have the headcount to send technicians to deploy remote site switches can leverage software tools to have those devices auto-provision themselves. You can also configure them to automatically configure things like Smartport roles, which has never really been one of my favorite switch features. Overall, I can appreciate where Cisco is wanting to go with this technology. But, as a CLI jockey, I’m still a bit jaded when it comes to having part of my job replaced by a TFTP script.
The final Cisco NFD4 presentation was about application visibility and control. This is a lot of the intelligence that is built into the Cisco Prime monitoring software that was demoed for us back at NFD3. If you can identify the particular fingerprints of a given application, such as Telepresence, you can better determine when those fingerprints are out of whack. I’m also excited because fingerprinting apps is going to be a huge part of security in the near future, as evidenced by Palo Alto’s app-based firewall and the others like Sonicwall and Watchguard that have followed along. Even the Cisco ASA-CX is starting to come around to the idea of stopping apps and not protocols.
There you have it. Lots of presenters. Hours of video. A couple of thousand words from me on all of it. It’s almost exhausting to see that much information in a short span of time. Some of the things that Cisco did with this presentation were great. There were technologies that only needed a bit of time. There were others that we could have spent an hour or more on. I think that the next NFD presenters that want to try something along these lines should setup the first three hours with rapid fire presentations and reserve the last hour for us to call back to earlier presenters and hit them with additional questions. That way, we don’t run out of time and we get to talk about the things that interest us the most. Bravo overall to the Cisco Borderless team for breaking out of the mold and trying something new to keep the NFD delegates hooked in.
Tech Field Day Disclaimer
Cisco was a sponsor of Network Field Day 4. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 4. In addition, they provided me with an 8GB USB drive with marketing collateral and data sheets. They did not ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.
Brocade kicked off our first double session at Network Field Day 4. We’d seen them previously at Network Field Day 2 and I’d just been to Brocade’s headquarters for their Tech Day a few weeks before. I was pretty sure that the discussion that was about to take place was going to revolve around OpenFlow and some of the hot new hardware the Brocade had been showing off recently. Thankfully, Lisa Caywood (@TheRealLisaC) still has some tricks up her sleeve.
I hereby dub Lisa “Queen of the Mercifully Short Introduction.” Lisa’s overview of Brocade hit all the high points about what Brocade’s business lines revolve around. I think by now that most people know that Brocade acquired Foundry for their ethernet switching line to add to their existing storage business that revolves around Fibre Channel. With all that out of the way, it was time to launch into the presentations.
Jessica Koh was up first to talk to me about a technology that I haven’t seen already – HyperEdge. This really speaks to me because the majority of my customer base isn’t ever going to touch a VDX or and ADX or an MLXe. HyperEdge technology is Brocade’s drive to keep the campus network infrastructure humming along to keep pace with the explosion of connectivity in the data center. Add in the fact that you’ve got all manner of things connecting into the campus network, and you can see how things like manageability can be at the forefront of people’s minds. To that end, Brocade is starting off the HyperEdge discussion early next year with the ability to stack dissimilar ICX switches together. This may sound like crazy talk to those of you that are used to stacking together Cisco 3750s or 2960s. On those platforms, every switch has to be identical. With the HyperEdge stacking, you can take an ICX 6610 and stack it with an ICX 6450 and it all works just fine. In addition, you can place a layer 3 capable switch into the stack in order to provide a device that will get your packets off the local subnet. That is a very nice feature that allows the customer base to buy layer 2 today if needed then add on in the future when they’ve outgrown the single wiring closet or single VLAN. Once you’ve added the layer 3 switch to the stack, all those features are populated across all the ports of the whole stack. That helps to get rid of some of the idiosyncrasies of some of the first stacking switch configurations, like not being able to locally switch packets. Add in the fact that the stacking interfaces on these switches are the integrated 10Gig Ethernet ports, and you can see why I’m kind of excited. No overpriced stacking kits. Standard SFP+ interfaces that can be reused in the event I need to break the stack apart.
I’m putting this demo video up to show how a demo during your presentation can be both a boon and a bane. Clear you cache after you’re done or log in as a different user to be sure you’re getting a clean experience. The demo can be a really painful part when it doesn’t run correctly.
Kelvin Franklin was up next with an overview of VCS, Brocade’s fabric solution. This is mostly review material from my Tech Day briefing, but there are some highlights here. Firstly, Brocade is using yet a third new definition for the word “trunk”. Unlike Cisco and HP, Brocade refers to the multipath connections into a VCS fabric as a trunk. Now, a trunk isn’t a trunk isn’t a trunk. You just have to remember the context of which vendor you’re talking about. This was also the genesis of packet spraying, which I’m sure was a very apt description for what Brocade’s VCS is doing to the packets as they send them out of the bundled links but it doesn’t sound all that appealing. Another thing to keep in mind when looking at VCS is that it is heavily based on TRILL for the layer 2 interconnects, but it does use FSPF from Brocade’s heavy fibre channel background to handle the routing of the links instead of IS-IS as the TRILL standard calls for. Check out Ivan’s post from last year as to why that’s both good and bad. Brocade also takes time to call out the fact that they’ve done their own ASIC in the new VCS switches as opposed to using merchant silicon like many other competitors. Only time will tell how effective the move to merchant silicon will be for those that choose to use it, but so long as Brocade can continue to drive higher performance from custom silicon it may be an advantage for them.
This last part of the VCS presentation covers some of the real world use cases for fabrics and how Brocade is taking an incremental approach to building fabrics. I’m curious to see how the VCS will begin to co-mingle with the HyperEdge strategy down the road. Cisco has committed to bringing their fabric protocol (FabricPath) to the campus in the Catalyst 6500 in the near future. With all the advantages of VCS that Brocade has discussed, I would like to see it extending down into the campus as well. That would be a huge advantage for some of my customers that need the capability to do a lot of east-west traffic flows without the money to invest in the larger VCS infrastructure until their data usage can provide adequate capital. There may not be a lot that comes out of it in the long run, but even having the option to integrate the two would be a feather in the marketing cap.
After lunch and a short OpenStack demo, we got an overview of Brocade’s involvement with the Open Networking Foundation (ONF) from Curt Beckmann. I’m not going to say a lot about this video, but you really do need to watch it if you are at all curious to see where Brocade is going with their involvement with OpenFlow going forward. As you’ve no doubt heard before, OpenFlow is really driving the future of networking and how we think about managing data flows. Seeing what Brocade is doing to implement ideas and driving direction of ONF development is nice because it’s almost like a crystal ball of networking’s future.
The last two videos really go together to illustrate how Brocade is taking OpenFlow and adopting it into their model for software defined networking (SDN). By now, I’ve heard almost every imaginable definition of SDN support. On one end of the spectrum, you’ve got Cisco and Juniper. A lot of their value is tied up in their software. IOS and Junos represent huge investments for them. Getting rid of this software so the hardware can be controlled by a server somewhere isn’t the best solution as they see it. Their response has been to open APIs into their software and allow programmability into their existing structures. You can use software to drive your networking, but you’re going to do it our way. At the other extreme end of the scale, you’ve got NEC. As I’ve said before, NEC is doubling down on OpenFlow mainly for one reason – survival. If they don’t adapt their hardware to be fully OpenFlow compliant, they run the risk of being swept off the table by the larger vendors. Their attachment to their switch OS isn’t as important as making their hardware play nice with everyone else. In the middle, you’ve got Brocade. They’ve made some significant investments into their switch software and protocols like VCS. However, they aren’t married to the idea of their OS being the be all, end all of the conversation. What they do want, however, is Brocade equipment in place that can take advantage of all the additional features offered from areas that aren’t necessarily OpenFlow specific. I think their idea around OpenFlow is to push the hybrid model, where you can use a relatively inexpensive Brocade switch to fulfill your OpenFlow needs while at the same time allowing for that switch to perform some additional functionality above and beyond that defined by the ONF when it comes to VCS or other proprietary software. They aren’t doing it for the reasons of survival like NEC, but it offers them the kind of flexibility they need to get within striking distance of the bigger players in the market.
If you’d like to learn more about Brocade, you can check out their website at http://www.brocade.com. You can also follow them on Twitter as @BRCDComm.
Tom’s Take
I’ve seen a lot of Brocade in the last couple of months. I’ve gotten a peek at their strategies and had some good conversations with some really smart people. I feel pretty comfortable understanding where Brocade is going with their Ethernet business. Yes, whenever you mention them you still get questions about fibre channel and storage connectivity, but Brocade really is doing what they can to get the word out about that other kind of networking that they do. From the big iron of the VDX to the ability to stack the ICX switches all the way to the planning in the ONF to run OpenFlow on everything they can, Brocade seems to have started looking at the long-term play in the data networking market. Yes, they may not be falling all over themselves to go to war with Cisco or even HP right now. However, a bit of visionary thinking can lead one to be standing on the platform when the train comes rumbling down the track. That train probably has a whistle that sounds an awful lot like “OpenFlow,” so only time can tell who’s going to be riding on it and who’s going to be underneath it.
Tech Field Day Disclaimer
Brocade was a sponsor of Network Field Day 4. As such, they were responsible for covering a portion of my travel and lodging expenses while attending Network Field Day 4. In addition, Brocade provided me with a gift bag containing a 2GB USB stick with marketing information and a portable cell phone charger. They did not ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone.
While I was at Brocade Tech Day, I had the wonderful opportunity to sit down with Jon Hudson (@the_solutioneer) and just talk for about half an hour. While the rest of the day was a whirlwind of presentations and interviews, Jon and I talked about all manner of things not related to VDX or VCS. Instead, we had a very fascinating discussion about TRILL and SPB.
For those not familiar, TRILL is the IETF standard for the issue of layer 2 multipath. It’s a very elegant solution for the spanning tree problem. Our data centers today are running at half capacity. That’s not because we don’t have enough bandwidth, though. It’s because half our links are shut down, waiting for a link failure. Thanks to 802.1d spanning tree, we can’t run two links at the same time unless they are bundled into a link aggregation (LAG) solution. And heaven forbid we want to terminate that LAG bundle on two different switches to prevent single-switch failure from affecting our traffic. Transparent Interconnection of Lots of Links (TRILL) fixes this by creating a layer 2 network with link state. It accomplishes this by running a form of IS-IS, which allows the layer 2 nodes to create an SPF table and determine not only the best path to a node, but other paths that could be equally as good. This means that we have a real fabric of interconnections with no blocked links.
802.1aq Shortest Path Bridging, or SPB informally, is the IEEE version of a layer 2 multipathing replacement for spanning tree. It looks a lot like TRILL and even uses IS-IS for the layer 2 protocol as well. It does differ in some respects, such as using MAC-in-MAC encapsulation for frames as opposed to rewriting the header like TRILL does. This makes it very attractive to the service provider market, as they don’t have to buy a bunch of new gear to get everything up and running quickly on SPB. Looking at the proponents of SPB, such as Avaya and Alcatel-Lucent that really comes as no surprise. Those companies are heavily invested in the service provider space and would really love to see SPB adoption take off as it would protect their initial investments.
The showdown between TRILL and SPB isn’t that far removed from the old showdown between VHS and Betamax. For those not entirely familiar, this was a case of two competing standards that was eventually settled in the court of the consumer. While many regard the early Betamax units as technologically superior, there was an issue of tape length (1 hour vs the VHS 2 hour limit). As time wore on, there was significant development done on both sides that stretched the formats to their absolute limits. However, by the end, VHS had won due to simple popularity. Since VHS had become the most popular format for consumers, even the supposed superiority of Betamax couldn’t save it from being relegated to the junk pile of history. Another more recent case is the battle between HD-DVD and Blu-ray. Similarly to the analog format wars decades earlier, the digital disc war erupted from two alliances thinking they had the best solution to the problem. Blu-ray eventually won out in much the same way that VHS – by becoming the format that most people wanted to use. The irony that Sony actually won a format war isn’t lost on a lot of people either.
I believe that we’re going to see something like these showdowns in TRILL vs. SPB. Right now, the battle lines seem drawn between the data center vendors supporting TRILL and the service provider vendors getting ready to implement SPB. Whether or not one of the solutions is technically superior to the other is inconsequential at this point. It’s all going to come down to popularity. Brocade and Cisco have non-standard TRILL implementations in VCS and FabricPath. The assumption is that they will be compatible with TRILL when a working solution is finally released. I’m also guessing that we’re going to see more support for TRILL in the cloud providers to maximize their revenue potential by offering non-blocking paths to increase throughput for those hungry cloud applications. Brocade showcased some providers moving to VCS at Brocade Tech Day. If that’s the case, we’re going to see TRILL at the enterprise level and the cloud provider level connected by an SP core running SPB. Just like Betamax being the favorite of the professional video industry, SPB will be the go-to protocol for providers, as they can put of yet one more round of equipment upgrades. I think by that point, however, TRILL will have obtained enough critical mass to drive adoption to the point where TRILL silicon will be a very inexpensive option on most new equipment in a few years, perhaps even becoming the default configuration. If that is indeed the case, then TRILL will indeed become the VHS or Blu-ray of this protocol war.
Tom’s Take
I can still remember going into the video store and seeing the great divide. On one side, Betamax. On the other, VHS. Slowly, the Betamax side of the house shrank away to nothing. It happened again with HD DVD and Blu-ray. In the end, both format wars came down to popularity. VHS was in more households and offered the ability to record two hours worth of programming instead of one. Blu-ray got the popular movie studios on board quickly, like Disney. Once the top selling movies were on Blu-ray, the outcome was all but guaranteed. In the big debate of TRILL against SPB, it’s going to come down to popularity. I think we’re already seeing the beginning of TRILL winning this fight. Sure, the service providers are going to use SPB as long as they can to avoid upgrading to TRILL-compatible hardware. I could even make a pretty compelling case the neither of these two layer 2 protocols would make a bunch of sense for a service provider. At the end of the day, though, I’m pretty sure that we’ll eventually be speaking about SPB in the same hushed nostalgia we reserve for the losers of the format wars so many years ago.
Here are a few posts about TRILL and SPB that generated some ideas for me. You should check them out too:
I am once again humbled and honored to accept an invitation to my favorite industry event – Network Field Day (now in its fourth iteration). Network Field Day 4 (NFD4) will be coming to you from San Jose October 10-12th. The delegate lineup has a bunch of new faces that I’m excited to catch up with and/or meet for the first time:
This is a great crew with a lot to say and I’m anxious to see them unleashed on our assembled sponsors:
Brocade – I’m betting that VCS is going to be up on the block this time around. We got a chance to play with it a while back and we had a blast. With the annoucements that you’ve made around Brocade Tech Day, I’d like to hear more about the VCS strategy and how it will dovetail into your other product lines. I’d also like to hear more about the ADX and how you plan on terminating VXLAN tunnels in hardware. Please be sure that you can talk about these in decent depth. Being told over and over again that something is NDA when it shouldn’t be a huge mystery is a bit disconcerting. Also, if Jon Hudson isn’t presenting, at least have him show up for a few minutes to say hello. We love that guy.During Wireless Field Day 3, Gregor Vučajnk (@GregorVucajnk) had a great blog post about attending that had something that I’m going to borrow for this NFD outing. He called out each of the participating sponsors and gave them a short overview of what he wanted to see from each of them. I loved the idea, as it gives a bit more direction to the people making the decisions about presentation content.
Cisco Borderless – Please, please, oh please tell me what Borderless really means. Even if it’s just “everything but data center and collaboration”. I really want to know how you’re pulling all these product lines together to create synergy. Otherwise, it’s still just going to be the routing BU, switching BU, and so on. We had a great time listening to the last presentation about ASA CX and Wireshark on the Cat 4500. More of that good stuff, even if it means you have to shave your presentation down a bit to accommodate. Remember, we ask lots of questions.
Juniper – Firstly, I want a bit of talk about Ivan’s post exploring all the gooey details around QFabric. I understand that in this case it may be a bit like the magician telling how the trick is done, but this is the kind of thing that fascinates me. I’m also sure there’s going to be discussion around SDN and the Juniper approach to it. The presentation at NFD2 was so great I want to see you keeping up the good work.
OpenGear – Hello there. I know nothing about you beyond the cursory Google search. It looks like you’ve got some interesting technology that could be of great use to network professionals. Case studies and anecdotes about using a 3G console failover to prevent global chaos would be awesome. Also, allowing us the opportunity to poke around on a box for a few minutes would rock. I want to think about how I can use your product to make my life less miserable when it comes to offline console access.
Spirent – Hello again to you. I didn’t know anything about Spirent last time, but now I see them everywhere I look. Spirent is like the Good Housekeeping seal for network gear. Lets dive deeper into things. I know you’re squeamish about showing off GUIs and things like that, but we nerd out on those things. Also, I want to talk about how you plan on building testing rigs to handle all the coming 100GigE traffic. Show me how Spirent is going to keep up the Ginger Rogers mystique that I’ve associated with it.
Statseeker – Network Performance Management and monitoring can be a bit of a dry subject, but doing it with an accent from the Land Down Under could be a bit of a treat. After your recent Packet Pushers episode, I want to drill down more into how you go about keeping all the monitoring data. I’ve seen what overwhelming an NMS with data can do, and while it was a pretty light show, I want to prevent it from happening again. I don’t expect you to bring one of your famous Minis to give away to the delegates, but don’t underestimate the power of bribery via Tim Tam.
Tech Field Day – Audience Participation
For those of you that like to follow along with the Tech Field Day delegates from the comfort of your office chair or recliner, you are more than welcome. I’ve even seen people talking about taking the day off from work or making sure they aren’t on a remote site. We will be streaming each of the presentations live at http://techfieldday.com. Note that this stream does use uStream, so we aren’t optimized for mobile devices just yet. We’re working on it, though. We will also be spending a lot of time on Twitter discussing the presentations and questions about them. Just make sure to use the hashtag #NFD4 and you can be a part of the discussion. I love seeing discussion and commentary from all the people watching online. I always make sure to keep my Twitter client at the forefront so I can ask questions from the home audience when they arise. That way, I’m truly a delegate representing people and giving them a say in what shapes the events.
If you’d like to learn a little more about Tech Field Day, you can head over to http://techfieldday.com and read up on things. You can also apply to be a delegate at this link. I look forward to seeing you online and hearing from you at this Tech Field Day event.
Standard Tech Field Day Sponsor Disclaimer
Tech Field Day is a massive undertaking that involves the coordination of many moving parts. It’s not unlike trying to herd cats with a helicopter. One of the most important pieces is the sponsors. Each of the presenting companies is responsible for paying a portion of the travel and lodging costs for the delegates. This means they have some skin in the game. What this does NOT mean is that they get to have a say in what we do. No Tech Field Day delegate is every forced to write about the event due to sponsor demands. If a delegate chooses to write about anything they see at Tech Field Day, there are no restrictions about what can be said. Sometimes this does lead to negative discussion. That is entirely up to the delegate. Independence means no restrictions. At times, some Tech Field Day sponsors have provided no-cost evaluation equipment to the delegates. This is provided solely at the discretion of the sponsor and is never a requirement. This evaluation equipment is also not a contingency of writing a review, be it positive or negative.
The Networking Nerd 