Why Facebook’s Open Compute Switches Don’t Matter. To You.

Posted on May 13, 2013 by networkingnerd

Facebook announced at Interop that they are soliciting ideas for building their own top-of-rack (ToR) switch via the Open Compute Project. This sent the tech media into a frenzy. People are talking about the end of the Cisco monopoly on switches. Others claimed that the world would be a much different place now that switches are going to be built by non-vendors and open sourced to everyone. I yawned and went back to my lunch. Why?

BYO Networking Gear

As you browse the article that you’re reading about how Facebook is going to destroy the networking industry, do me a favor and take note of what kind of computer you’re using. Is is a home-built desktop? Is it something ordered from a vendor? Is it a laptop or mobile device that you built? Or bought?

The idea that Facebook is building switches isn’t far fetched to me. They’ve been doing their own servers for a while. That’s because their environment looks wholly different than any other enterprise on the planet, with the exception of maybe Google (who also builds their own stuff). Facebook has some very specialized needs when it comes to servers and to networking. As they mention at conferences, the amount of data rushing into their network on an hourly, let alone daily, basis is mind boggling. Shaving milliseconds off query times or reducing traffic by a few KB per flow translates into massive savings when you consider the scale they are operating at.

To that end, anything they can do to optimize their equipment to meet their needs is going to be a big deal. They’ve got a significant motivation to ensure that the devices doing the heavy lifting for them are doing the best job they can. That means they can invest a significant amount of capital into building their own network devices and still get a good return on the investment. Much like the last time I built my own home desktop. I didn’t find a single machine that met all of my needs and desires. So I decided to cannibalize some parts out of an old machine and just build the rest myself. Sure, it took me about a month to buy all the parts, ship them to my house, and then assemble the whole package together. But in the end I was very happy with the design. In fact, I still use it at home today.

That’s not to say that my design is the best for everyone, or anyone for that matter. The decisions I made in building my own computer were one’s that suited me. In much the same way, Facebook’s ToR switches probably serve very different needs than existing data centers. Are your ToR switches optimized for east-west traffic flow? I don’t see a lot of data at Facebook directed to other internal devices. I think Facebook is really pushing their systems for north-south flow. Data requests coming in from users and going back out to them are more in line with what they’re doing. If that’s the case, Facebook will have a switch optimized for really fast data flows. Only they’ll be flowing in the wrong direction for what most people are using data flows for today. It’s like having a Bugatti Veyron and living in a city with dirt roads.

Facebook admitted that there are things about networking vendors they don’t like. They don’t want to be locked into a proprietary OS like IOS, EOS, or Junos. They want a whitebox solution that will run any OS on the planet efficiently. I think that’s because they don’t want to get locked into a specific hardware supplier either. They want to buy what’s cheapest at the time and build large portions of their network rapidly as needed to embrace new technology and data flows. You can’t get married to a single supplier in that case. If you do, a hiccup in the production line or a delay could cost you thousands, if not millions. Just look at how Apple ensures diversity in the iPhone supply chain to get an idea of what Facebook is trying to do. If Apple were to lose a single part supplier there would be chaos in the supply chain. In order to ensure that everything works like a well-oiled machine, they have multiple companies supplying each outsourced part. I think Facebook is driving for something simliar in their switch design.

One Throat To Choke

The other thing that gives me pause here is support. I’ve long held that one of the reasons why people still buy computers from vendors or run Windows and OS X on machines is because they don’t want the headache of fixing things. A warranty or support contract is a very reassuring thing. Knowing that you can pick up the phone and call someone to get a new power supply or tell you why you’re getting a MAC flap error lets you go to sleep at night. When you roll your own devices, the buck stops with you when you need to support something. Can’t figure out how to get your web server running on Ubuntu? Better head to the support forums. Wondering why your BYOSwitch is dropping frames under load? Hope you’re a Wireshark wizard. Most enterprises don’t care that a support contract costs them money. They want the assurance that things are going to get fixed when they break. When you develop everything yourself, you are putting a tremendous amount of faith into those developers to ensure that bugs are worked out and hardware failures are taken care of. Again, when you consider the scale of what Facebook is doing, the idea of having purpose-build devices makes sense. It also makes sense that having people on staff that can fix those specialized devices is cost effective for you.

Face it. The idea that Facebook is going to destroy the switching market is ludicrous. You’re never going to buy a switch from Facebook. Maybe you want to tinker around with Intel’s DPDK with a lab switch so you can install OpenFlow or something similar. But when it comes time to forklift the data center or populate a new campus building with switches, I can almost guarantee that you’re going to pick up the phone and call Cisco, Arista, Juniper, Brocade, or HP. Why? Because they can build those switches faster than you can. Because even though they are a big captial expenditure (capex), it’s still cheaper in the long run if you don’t have the time to dedicate to building your own stuff. And when something blows up (and something always blows up), you’re going to want a TAC engineer on the phone sharing the heat with you when the CxOs come headhunting in the data center when everything goes down.

Facebook will go on doing their thing their way with their own servers and switches. They’ll do amazing things with data that you never dreamed possible. But just like buying a Sherman tank for city driving, their solution isn’t going to work for most people. Because it’s built by them for them. Just like Google’s server farms and search appliances. Facebook may end up contributing a lot to the Open Compute Project and advancing the overall knowledge and independence of networking hardware. But to think they’re starting a revolution in networking is about as far fetched as thinking that Myspace was going to be the top social network forever.

Brocade’s Pragmatically Defined Network

Posted on May 2, 2013 by networkingnerd

Most of the readers of my blog would agree that there is a lot of discussion in the networking world today about software defined networking (SDN) and the various parts and pieces that make up that umbrella term. There’s argument over what SDN really is, from programmability to orchestration to network function virtualization (NFV). Vendors are doing their part to take advantage of some, all, or in some cases none of the above to push a particular buzzword strategy to customers. I like to make sure that everything is as clear as possible before I start discussing the pros and cons. That’s why I jumped at the chance to get a briefing from Brocade around their new software and hardware releases that were announced on April 30th.

I spoke with Kelly Harrell, Brocade’s new vice president and general manager of the Software Business Unit. If that name sounds somewhat familiar, it might be because Mr. Harrell was formerly at Vyatta, the software router company that was acquired by Brocade last year. We walked through a presentation and discussion of the direction that Brocade is taking their software defined networking portfolio. According to Brocade, the key is to be pragmatic about the new network. New technologies and methodologies need to be introduced while at the same time keeping in mind that those ideas must be implemented somehow. I think that a large amount of the frustration with SDN today comes from a lot of vaporware presentations and pie-in-the-sky ideas that aren’t slated to come to fruition for months. Instead, Brocade talked to me about real products and use cases that should be shipping very soon, if not already.

The key to Brocade is to balance SDN against network function virtualization, something I referred to a bit in my Network Field Day 5 post about Brocade. Back then, I called NFV “Networking Done (by) Software,” which was my sad attempt to point out how NFV is just the opposite of what I see SDN becoming. During our discussion, Harrell pointed out that NFV and SDN aren’t totally dissimilar after all. Both are designed to increase the agility with which a company can execute on strategy and create value for shareholders. SDN is primarily focused on programmability and orchestration. NFV is tied more toward lowering costs by implementing existing technology in a flexible way.

NFV seeks to take existing appliances that have been doing tasks, such as load balancers or routers, and free their workloads from being tied to a specific piece of hardware. In fact, there has been an explosion of these types of migrations from a variety of vendors. People are virtualizing entire business lines in an effort to remove the reliance on specialized hardware or reduce the ongoing support costs. Brocade is seeking to do this with two platforms right now. The first is the Vyatta vRouter, which is the extension what came over in the Vyatta acquisition. It’s a router and a firewall and even a virtual private networking (VPN) device that can run on just about anything. It is hypervisor agnostic and cloud platform agnostic as well. The idea is that Brocade can include a copy of the vRouter with application packages that can be downloaded from an enterprise cloud app store. Once downloaded and installed, the vRouter can be fired up and pull a predefined configuration from the scripts included in the box. By making it agnostic to the underlying platform, there’s no worry about support down the road.

The second NFV platform Brocade told me about is the virtual ADX application delivery switch. It’s basically a software load balancer. That’s not really the key point of the whole idea of applying the NFV template to an existing hardware platform. Instead, the idea is that we’re taking something that’s been historically huge and hard to manage and moving it closer to the edge where it can be of better use. Rather that sticking a huge load balancer at the entry point to the data center to ensure that flows are separated, the vADX allows the load balancer to be deployed very close to the server or servers that need to have the information flow metered. Now, the agility of SDN/NFV allows these software devices to be moved and reconfigured quickly without needing to worry about how much reprogramming is going to be necessary to pull the primary load balancer out or change a ton of rules to take reroute traffic to a vMotioned cluster. In fact, I’m sure that we’re going to see a new definition of the “network edge” being to emerge as more software-based NFV devices begin to be deployed closer and closer to the devices that need them.

On the OpenFlow front, Brocade told me about their new push toward something they are calling “Hybrid Port OpenFlow.” OpenFlow is a great disruptive SDN technology that is gaining traction today, largely in part because of companies like Brocade and NEC that have embraced it and started pushing it out to their customer base well ahead of other manufacturers. Right now, OpenFlow support really consists to two modes – ON and OFF. OFF is pretty easy to imagine. ON is a bit more complicated. While a switch can be OpenFlow enabled and still forward normal traffic, the practice has always been to either dedicate the switch to OpenFlow forwarding, in effect turning it into a lab switch, or to enable OpenFlow selectively for a group of ports out of the whole switch, kind of like creating a lab VLAN for testing on a production box. Brocade’s Hybrid Port OpenFlow model allows you to enable OpenFlow on a port and still allow it to do regular traffic forwarding sans OpenFlow. That may be the best model for adopters going forward due to one overriding factor – cost. When you take a switch or a group of ports on a switch and dedicate them for OpenFlow, you are cost the enterprise something. Every port on the switch costs a certain amount of money. Every minute an engineer spends working on a crazy lab project incurs a cost. By enabling the network engineers to turn on OpenFlow at will without disrupting the existing traffic flow, Brocade can reduce the opportunity cost of enabling OpenFlow to almost zero. If OpenFlow just becomes something that works as soon as you enable it, like IPv6 in Windows 7, you don’t have to spend as much time planning for your end node configuration. You just build the core and let the end nodes figure out they have new capabilities. I figure that large Brocade networks will see their OpenFlow adoption numbers skyrocket simply because Hybrid Port mode turns the configuration into Easy Mode.

The last interesting software piece that Brocade showed me is a prime example of the kinds of things that I expect SDN to deliver to us in the future. Brocade has created an application called the Application Resource Broker (ARB). It sits above the fray of the lower network layers and monitors indicators of a particular application’s health, such as latency and load. When one of those indicators hits a specific threshold, ARB kicks in to request more resources from vCenter to balance things out. If the demand on the application continues to rise beyond the available resources, ARB can dynamically move the application to a public cloud instance with a much deeper pool of resources, a process known as cloudbursting. All of this can happen automatically without the intervention of IT. This is one of the things that shows me what SDN can really do. Software can take care of itself and dynamically move things around when abnormal demand happens. Intelligent choices about the network environment can be made on solid data. No guess what about what “might” be happening. ARB removes doubt and lag in response time to allow for seamless network repair. Try doing that with a telnet session.

There’s a lot more to the Brocade announcement than just software. You can check it out at http://www.brocade.com. You can also follow them on Twitter as @BRCDComm.

Tom’s Take

The future looks interesting at first. Flying cars, moving sidewalks, and 3D user interfaces are all staples of futuristic science fiction. The problem for many arises when we need to start taking steps to build those fanciful things. A healthy dose of pragmatism helps to figure out what we need to do today to make tomorrow happen. If we root our views of what we want to do with what we can do, then the future becomes that much more achievable. Even the amazing gadgets we take for granted today have a basis in the real technology of the time they were first created. By making those incremental steps, we can arrive where we want to be a whole lot sooner with a better understanding of how amazing things really are.

Juniper and the Removal of the Human Element

Posted on April 11, 2013 by networkingnerd

Our final presentation of Network Field Day 5 came from Juniper. A long-time contributor to Network Field Day, Juniper has been making noise as of late in the software defined networking (SDN) space with some of their ideas. We arrived on site for a nice hardy breakfast before settling in to hear what Juniper is bringing to the greater software networking space and how I later learned that it might be best to start phasing out the human element in the network.

First up was Jeremy Schulman (@nwkautomaniac) talking to us about Puppet integration into Junos. Jeremy opened with a talk about his involvement in automating things. Customers have been using infrastructure automation tools like Puppet and Chef for a while to provision servers. This allows you to spin up a new piece of hardware and have it quickly setup with basic configuration as soon as it boots up. Jeremy told us that reinventing the wheel when it comes to automation was unnecessary when you could just put a Puppet agent in Junos. So that’s what he did. As a side note here, Jeremy brings up a very good point about the future of networking. If you don’t know how to program in a real programming language, I suggest you start now. Most of the interfaces that I’ve seen in the last 6-9 months have a high degree of familiarity based on the old CLI interface conventions. But these interfaces only really exist to make us old school networking guys feel safe. Very soon, all the interfaces to these devices will be only be accessible via API – which means programming. If you don’t know how to write something in Python or Perl or even Java, you need to begin picking it up. For something like Python, you might consider Codecademy. It’s free and easy to pick up and follow whenever you want. Just a thought.

Demo time! There’s also a great overview of Puppet on Junos over on Packet Pushers written by none other than Anthony Burke (@pandom_). The basic idea is that you write the pertinent configuration snippets into a task that can be transformed into a workflow rather than being a CLI jockey that just spends time typing the command blindly into a Telnet or SSH session. Because you can also parse these tasks before they are sent out via the Puppet master, you can be sure your configs are sanitized and being sent to the appropriate device(s). That means that there are no humans in the middle of the process to type in the wrong address or type the right commands on the wrong device. Puppet is doing its part to remove the possibility of mistakes from your base configurations. Sure, it seems like a lot of work today to get Puppet up and running for the advantage of deploying a few switches. But when you look at the reduction of work down the road for the ability to boot up a bare metal box and have it be configured in a matter of minutes I think the investment is worth it. I spend a lot of time preconfiguring devices that get shipped to remote places. If I could have that box shipped the the remote location first and then just use Puppet to bring it online, I’d have a lot more time to devote to fine tuning the process. Which leads to greater efficiency. Which leads to more time (and so on and so on).

Next up, we got a sneak peek at Juniper’s next generation programmable core switch. While I didn’t catch the name at the time, it turns out that it was the new EX9200 that has been making some waves as of late. This switch is based on custom silicon, the Juniper One ASIC, rather than the merchant silicon in QFabric. Other than the standard speeds and feeds that you see from a core switch of this type, you can see that Juniper is going to support the kitchen sink of SDN with the EX9200. In addition to supporting OpenFlow and Puppet automation, it will also support VXLAN and NVGRE overlays as well as other interesting things like OpenStack and VMWare plugins in the future. Make no mistake – this platform is Juniper’s stalking horse for the future. There’s been a lot written about the longevity of the previous platforms compared to the new MX-based EX9200. I think that Juniper is really standing behind the idea that the future of networking lies in SDN and that a platform with support for the majority of the popular methods used to reach high levels of programmability and interoperability is critical going forward. Where that leaves other switching platforms is the realm of speculation. Just ask yourself this question: Are you planning on buying a non-SDN capable switch in the next refresh? Is regular packet forward fine for you for the next 3-5 years? That is the critical question being asked in strategy meetings and purchasing departments all over the place right now.

Parantap Lahiri stepped up next to present on the Contrail acquisition. Those of you interested in the greater SDN picture would do well to watch the whole video. Especially if you are curious about things like VMware’s new NSX strategy, as the Contrail idea is very similar, if not a bit more advanced. The three use cases outlined in the video are great for those not familiar with what SDN is trying to accomplish right now. In fact, commit this diagram to memory. You are going to see it again (I promise):

ContrailDiagram

Note that further in the video, Parantap goes over one of the features of Contrail that is going to get many people excited. Via use of GRE tunnels, this solution can create a hybrid cloud solution to burst your traffic from the private data center into a public provider like AWS or Rackspace as needed. That, if nothing else, is the message that you need to consider with the “traditional” vendors that are supporting SDN. Cisco and Juniper and even VMware don’t want you to start buying whitebox servers and turning them into switches. They don’t want a “roll your own” strategy. What Juniper wants if for you to buy a whole bunch of EX9200s and then build a Contrail overlay system to manage it all. Then, when the workloads get to be too great for your own little slice of private cloud you can use Contrail to tunnel into the public cloud and move those workloads until the traffic spike subsides. Maybe you even want to keep some of those migrated workloads in the cloud permanently in order to take advantage of cheap compute and ease overall usage in your private data center. The key is flexibility, and that’s what Contrail gives you. That’s where the development is going to be for the time being.

The last presentation came from the Juniper Webapp Secure team. You may recognize this product by its former moniker – Mykonos. In fact, you may recognize this presentation from its former delivery at NFD4. In fact, I said as much during the demo:

As I said last time, Juniper Webapp Secure (nee Mykonos) is the greatest trolling security program I’ve seen. #NFD5—
Tom Hollingsworth (@networkingnerd) March 08, 2013

There’s a market for a security tool like this for lots of websites. It gets the bad guys without really affecting the good guys. I’m sure that Juniper is going to sell the living daylights out of it. They’re trying their best right now based on the number of people that I’ve seen talking about it on Twitter. The demo is engaging because it highlights the capabilities as well as injecting a bit of humor and trollishness. However, based on what I’ve seen at NFD4 and NFD5 and what people have told me they saw when they were presented, I think the Webapp Secure demo is very scripted and fairly canned. The above video is almost identical to the one from NFD4. Compare:

Guys, you need to create a new Generic company and give us some more goodies in the demo. Having a self-aware web firewall that doesn’t need human intervention to stop the attackers is a big deal. Don’t use Stock Demo Footage to tell us about it every time.

Tom’s Take

What does the Juniper strategy look like? The hint is in the title of this post. Juniper is developing automation to reduce the amount of people in the network making critical decisions without good information or tools to execute. As those people begin to be replaced by automated systems, the overall intelligence in the network increases while at the same time reducing the amount of time that it takes to take action to bring new nodes online and reconfigure on the fly to support things we thought might have been impossible even three years ago. Through device deployment orchestration, flexible platforms supporting new protocols with programmability built in and even to new technology like overlay networking and automated security response for critical systems, Juniper is doing their best to carve out a section of the SDN landscape just for themselves. It’s a strategy that should pay off in the long run provided there is significant investment that stays the course.

Tech Field Day Disclaimer

Juniper 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 provided breakfast for the delegates. Juniper also gave the delegates a copy of Juniper Warrior, a mobile phone charger, emergency battery pack, and a battery-powered pocket speaker. 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.

Plexxi and the Case for Affinity

Posted on April 8, 2013 by networkingnerd

Plexxi Logo

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

Smart Optical Switching – Your Plexxible Friend – John Herbert

Plexxi Control – Anthony Burke

Brocade Defined Networking

Posted on April 4, 2013 by networkingnerd

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.

Aerohive Is Switching Things Up

Posted on March 5, 2013 by networkingnerd

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:

Screen Shot 2013-03-03 at 4.14.11 PM

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.

Why Is My SFP Not Working?

Posted on February 28, 2013 by networkingnerd

GenericSFP

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.

New Wrinkles in the Fabric – Cisco Nexus Updates

Posted on February 4, 2013 by networkingnerd

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.

Juniper – Land of Unicorns and Broccoli

Posted on November 8, 2012 by networkingnerd

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 <3 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 <3 @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.

Cisco – Borderless Speed Dating

Posted on November 5, 2012 by networkingnerd

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.

If you’d like to learn more about Cisco Borderless Networks, check them out at http://www.cisco.com/en/US/netsol/ns1015/index.html. You can see an archive of the presentations and associated data sheets at http://blogs.cisco.com/borderless/networking-field-day-4-at-cisco-nfd4/. You should also follow the Cisco Borderless team on Twitter as @CiscoEnterprise and @CiscoGeeks.

Tom’s Take

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.

The Networking Nerd

Networking With A Side of Snark

Category Archives: Switching

Why Facebook’s Open Compute Switches Don’t Matter. To You.

Brocade’s Pragmatically Defined Network

Juniper and the Removal of the Human Element

Plexxi and the Case for Affinity

Brocade Defined Networking

Aerohive Is Switching Things Up

Why Is My SFP Not Working?

New Wrinkles in the Fabric – Cisco Nexus Updates

Juniper – Land of Unicorns and Broccoli

Cisco – Borderless Speed Dating

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: