Tag Archives: cisco

IOS X-Treme!

Posted on by
6

IOSXtreme

As a nerd, I’m a huge fan of science fiction. One of my favorite shows was Stargate SG-1. Inside the show, there was a joke involving an in-universe TV program called “Wormhole X-Treme” that a writer unintentionally created based on knowledge of the fictional Stargate program. Essentially, it’s a story that’s almost the same as the one we’re watching, with just enough differences to be a totally unique experience. In many ways, that’s how I feel about the new versions of Cisco’s Internetwork Operating System (IOS) that have been coming out in recent months. They may look very similar to IOS. They may behave similarly to IOS. But to mistake them for IOS isn’t right. In this post, I’m going to talk about the three most popular IOS-like variants – IOS XE, IOS XR, and NX-OS.

IOS XE

IOS XE is the most IOS-like of all the new IOS builds that have been released. That’s because the entire point of the IOS XE project was to rebuild IOS to future proof the technology. Right now, the IOS that runs on routers (which will henceforth be called IOS Classic) is a monolithic kernel that runs all of the necessary modules in the same memory space. This means that if something happens to the routing engine or the LED indicator, it can cause the whole IOS kernel to crash if it runs out of memory. That may have been okay years ago but today’s mission critical networks can’t afford to have a rogue process bringing down an entire chassis switch. Cisco’s software engineers set out on a mission to rebuild the IOS CLI on a more robust platform.

IOS XE runs as a system daemon on a “modern Linux platform.” Which one is anyone’s guess. Cisco also abstracted the system functions out of the main kernel and into separate processes. That means that if one of them goes belly up it won’t take the core kernel with it. One of the other benefits of running the kernel as a system daemon is that you can now balance the workload of the processes across multiple processor cores. This was one of the more exciting things to me when I saw IOS XE for the first time. Thanks to the many folks that pointed out to me that the ASR 1000 was the first device to run IOS XE. The Catalyst 4500 (the first switch to get IOS XE) is using a multi core processor to do very interesting things, like the ability to run inline Wireshark on a processor core while still letting IOS have all the processor power it needs. Here’s a video describing that:

Because you can abstract the whole operation of the IOS feature set, you can begin to do things like offer a true virtual router like the CSR 1000. As many people have recently discovered, the CSR 1000 is built on IOS XE and can be booted and operated in a virtualized environment (like VMware Fusion or ESXi). The RAM requirements are fairly high for a desktop virtualization platform (CSR requires 4GB of RAM to run), but the promise is there for those that don’t want to keep using GNS3/Dynamips or Cisco’s IOU to emulate IOS-like features. IOS XE is the future of IOS development. It won’t be long until the next generation of supervisor engines and devices will be using it exclusively instead of relying on IOS Classic.

IOS XR

In keeping with the sci-fi theme of this post, IOS XR is what the Mirror Universe version of IOS would look like. Much like IOS XE, IOS XR does away with the monolithic kernel and shared memory space of IOS Classic. XR uses an OS from QNX to serve as the base for the IOS functions. XR also segments the ancillary process in IOS into separate memory spaces to prevent system crashes from an errant bug. XR is aimed at the larger service provider platforms like the ASR 9000 and CRS series of routers. You can see that in the way that XR can allow multiple routing protocol processes to be executed at the same time in different memory spaces. That’s a big key to the service provider.

What makes IOS XR so different from IOS Classic? That lies in the configuration method. While the CLI may resemble the IOS that you’re used to, the change methodology is totally foreign to Cisco people. Instead of making live config changes on a live system, the running configuration is forked into a separate memory space. Once you have created all the changes that you need to make, you have to perform a sanity check on the config before it can be moved into live production. That keeps you from screwing something up accidentally. Once you have performed a sanity check, you have to explicitly apply the configuration via a commit command. In the event that the config you applied to the router does indeed contain errors that weren’t caught by the sanity checker (like the wrong IP), you can issue a command to revert to a previous working config in a process known as rollback. All of the previous configuration sets are retained in NVRAM and remain available for reversion.

If you’re keeping track at home, this sounds an awful lot like Junos. Hence my Mirror Universe analogy. IOS XR is aimed at service providers, which is a market dominated by Juniper. SPs have gotten very used to the sanity checking and rollback capabilities provided by Junos. Cisco decided to offer those features in an SP-specific IOS package. There are many that want to see IOS XR ported from the ASR/CSR lines down into more common SP platforms. Only time will tell if that will happen. Jeff Fry has an excellent series of posts on IOS XR that I highly recommend if you want to learn more about the specifics of configuration on that platform.

NX-OS

NX-OS is the odd man out from the IOS family. It originally started life as Cisco’s SAN-OS, which was responsible for running the MDS line of fibre channel switches. Once Cisco started developing the Nexus switching platform, they decided to use SAN-OS as the basis for the operating system, as it already contained much of the code that would be needed to allow networking and storage protocols to interoperate on the device, a necessity for a converged data center switch. Eventually, the new OS became known as NX-OS.

NX-OS looks similar to the IOS Classic interface that most engineers have become accustomed to. However, the underlying OS is very different from what you’re used to. First off, not every feature of classic IOS is available on demand. Yes, a lot of the more esoteric feature sets (like the DHCP server) are just plain unavailable. But even the feature sets that are listed as available in the OS may not be in the actual running code. You need to active each of these via use of the feature keyword when you want to enable them. This “opt in” methodology ensures that the running code only contains essential modules as well as the features you want. That should make the security people happy from an exploit perspective, as it lowers the available attack surface of your OS.

Another unique feature of NX-OS is the interface naming convention. In IOS Classic, each interface is named via the speed. You can have Ethernet, FastEthernet, GigabitEthernet, TenGigabit, and even FortyGigabit interfaces. In NX-OS, you have one – Ethernet. NX-OS treats all interfaces as Ethernet regardless of the underlying speed. That’s great for a modular switch because it allows you to keep the same configuration no matter which line cards are running in the device. It also allows you to easily port the configuration to a newer device, say from Nexus 5500 to Nexus 6000, without needed to do a find/replace operation on the config and risk changing a line you weren’t supposed to. Besides, most of the time the engineer doesn’t care about whether an interface is gigabit or ten gigabit. They just want to program the second port on the third line card.

Tom’s Take

No software program can survive without updates. Especially if it is an operating system. The hardware designed to run version 1.0 is never the same as the hardware that version 5.0 or even 10.0 utilizes. Everything evolves to become more efficient and useful. Think of it like seasons of sci-fi shows. Every season tells a story. There may be some similarities, but people overall want the consistency of the characters they’ve come to love coupled with new stories and opportunities to increase character development. Network operating systems like IOS are no different. Engineers want the IOS-like interface but they also want separated control planes, robust sanity checking, and modularized feature insertion. Much like the writers of sci-fi, Cisco will continue to provide new features and functionality while still retaining the things to which we’ve grown accustomed. However, if Cisco ever comes up with a hare-brained idea like the Ori, I can promise there’s no way I’ll ever run IOS-Origin.

Cisco Borderless Idol

Posted on by
1

Cisco Logo

Day one of Network Field Day 5 (NFD5) included presentations from the Cisco Borderless team. You probably remember their “speed dating” approach at NFD4 which gave us a wealth of information in 15 minute snippets. The only drawback to that lineup is when you find a product or a technology that interests you there really isn’t any time to quiz the presenter before they are ushered off stage. Someone must have listened when I said that before, because this time they brought us 20 minute segments – 10 minutes of presentation, 10 minutes of demo. With the switching team, we even got to vote on our favorite to bring the back for the next round (hence the title of the post). More on that in a bit.

6500 Quad Supervisor Redundancy

First up on the block was the Catalyst 6500 team. I swear this switch is the Clint Howard of networking, because I see it everywhere. The team wanted to tell us about a new feature available in the ((verify code release)) code on the Supervisor 2T (Sup2T). Previously, the supervisor was capable of performing a couple of very unique functions. The first of these was Stateful Switch Over (SSO). During SSO, the redundant supervisor in the chassis can pick up where the primary left off in the event of a failure. All of the traffic sessions can keep on trucking even if the active sup module is rebooting. This gives the switch a tremendous uptime, as well as allowing for things like hitless upgrades in production. The other existing feature of the Sup2T is Virtual Switching System (VSS). VSS allows two Sup2Ts to appear as one giant switch. This is helpful for applications where you don’t want to trust your traffic to just one chassis. VSS allows for two different chassis to terminate Multi-Chassis EtherChannel (MLAG) connections so that distribution layer switches don’t have a single point of failure. Traffic looks like it’s flowing to one switch when in actuality it may be flowing to one or the other. In the event that a Supervisor goes down, the other one can keep forwarding traffic.

Enter the Quad Sup SSO ability. Now, instead of having an RPR-only failover on the members of a VSS cluster, you can setup the redundant Sup2T modules to be ready and waiting in the event of a failure. This is great because you can lose up to three Sup2Ts at once and still keep forwarding while they reboot or get replaced. Granted, anything that can take out 3 Sup2Ts at once is probably going to take down the fourth (like power failure or power surge), but it’s still nice to know that you have a fair amount of redundancy now. This only works on the Sup2T, so you can’t get this if you are still running the older Sup720. You also need to make sure that your linecards support the newer Distributed Forwarding Card 3 (DFC3), which means you aren’t going to want to do this with anything less than a 6700-series line card. In fact, you really want to be using the 6800 series or better just to be on the safe side. As Josh O’brien (@joshobrien77) commented, this is a great feature to have. But it should have been there already. I know that there are a lot of technical reasons why this wasn’t available earlier, and I’m sure the increase fabric speeds in the Sup2T, not to mention the increased capability of the DFC3, are the necessary component for the solution. Still, I think this is something that probably should have shipped in the Sup2T on the first day. I suppose that given the long road the Sup2T took to get to us that “better late than never” is applicable here.

UCS-E

Next up was the Cisco UCS-E series server for the ISR G2 platform. This was something that we saw at NFD4 as well. The demo was a bit different this time, but for the most part this is similar info to what we saw previously.


Catalyst 3850 Unified Access Switch

The Catalyst 3800 is Cisco’s new entry into the fixed-configuration switch arena. They are touting this a “Unified Access” solution for clients. That’s because the 3850 is capable of terminating up to 50 access points (APs) per stack of four. This think can basically function as a wiring closet wireless controller. That’s because it’s using the new IOS wireless controller functionality that’s also featured in the new 5760 controller. This gets away from the old Airespace-like CLI that was so prominent on the 2100, 2500, 4400, and 5500 series controllers. The 3850, which is based on the 3750X, also sports a new 480Gbps Stackwise connector, appropriately called Stackwise480. This means that a stack of 3850s can move some serious bits. All that power does come at a cost – Stackwise480 isn’t backwards compatible with the older Stackwise v1 and v2 from the 3750 line. This is only an issue if you are trying to deploy 3850s into existing 3750X stacks, because Cisco has announced the End of Sale (EOS) and End of Life (EOL) information for those older 3750s. I’m sure the idea is that when you go to rip them out, you’ll be more than happy to replace them with 3850s.

The 3850 wireless setup is a bit different from the old 3750 Access Controller that had a 4400 controller bolted on to it. The 3850 uses Cisco’s IOS-XE model of virtualizing IOS into a sort of VM state that can run on one core of a dual-core processor, leaving the second core available to do other things. Previously at NFD4, we’d seen the Catalyst 4500 team using that other processor core for doing inline Wireshark captures. Here, the 3850 team is using it to run the wireless controller. That’s a pretty awesome idea when you think about it. Since I no longer have to worry about IOS taking up all my processor and I know that I have another one to use, I can start thinking about some interesting ideas.

The 3850 does have a couple of drawbacks. Aside from the above Stackwise limitations, you have to terminate the APs on the 3850 stack itself. Unlike the CAPWAP connections that tunnel all the way back to the Airespace-style controllers, the 3850 needs to have the APs directly connected in order to decapsulate the tunnel. That does provide for some interesting QoS implications and applications, but it doesn’t provide much flexibility from a wiring standpoint. I think the primary use case is to have one 3850 switch (or stack) per wiring closet, which would be supported by the current 50 AP limitation. the othe drawback is that the 3850 is currently limited to a stack of four switches, as opposed to the increased six switch limit on the 3750X. Aside from that, it’s a switch that you probably want to take a look at in your wiring closets now. You can buy it with an IP Base license today and then add on the AP licenses down the road as you want to bring them online. You can even use the 3850s to terminate CAPWAP connections and manage the APs from a central controller without adding the AP license.

Here is the deep dive video that covers a lot of what Cisco is trying to do from a unified wired and wireless access policy standpoint. Also, keep an eye out for the cute Unifed Access video in the middle.

Private Data Center Mobility

I found it interesting this this demo was in the Borderless section and not the Data Center presentation. This presentation dives into the world of Overlay Transport Virtualization (OTV). Think of OTV like an extra layer of 802.1 q-in-q tunneling with some IS-IS routing mixed in. OTV is Cisco’s answer to extending the layer 2 boundary between data centers to allow VMs to be moved to other sites without breaking their networking. Layer 2 everywhere isn’t the most optimal solution, but it’s the best thing we’ve got to work with the current state of VM networking (until Nicira figures out what they’re going to do).

We loved this session so much that we asked Mostafa to come back and talk about it more in depth.

The most exciting part of this deep dive to me was the introduction of LISP. To be honest, I haven’t really been able to wrap my head around LISP the first couple of times that I saw it. Now, thanks to the Borderless team and Omar Sultan (@omarsultan), I’m going to dig into a lot more in the coming months. I think there are some very interesting issues that LISP can solve, including my IPv6 Gordian Knot.

Tom’s Take

I have to say that I liked Cisco’s approach to the presentations this time.  Giving us discussion time along with a demo allowed us to understand things before we saw them in action.  The extra five minutes did help quite a bit, as it felt like the presenters weren’t as rushed this time.  The “Borderless Idol” style of voting for a presentation to get more info out of was brilliant.  We got to hear about something we wanted to go into depth about, and I even learned something that I plan on blogging about later down the line.  Sure, there was a bit of repetition in a couple of areas, most notably UCS-E, but I can understand how those product managers have invested time and effort into their wares and want to give them as much exposure as possible.  Borderless hits all over the spectrum, so keeping the discussion focused in a specific area can be difficult.  Overall, I would say that Cisco did a good job, even without Ryan Secrest hosting.

Tech Field Day Disclaimer

Cisco 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, Cisco provided me with a breakfast and lunch at their offices.  They also provided a Moleskine notebook, a t-shirt, and a flashlight toy.  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.

Cisco Data Center Duel

Posted on by
4

Cisco Logo

Network Field Day 5 started off with a full day at Cisco. The Data Center group opened and closed the day, with the Borderless team sandwiched in between. Omar Sultan (@omarsultan) greeted us as we settled in for a continental breakfast before getting started.

The opening was a discussion of onePK, a popular topic as of late from Cisco. While the topic du jour in the networking world is software-defined networking (SDN), Cisco steers the conversation toward onePK. This, at its core, is API access to all the flavors of the Internetwork Operating System (IOS). While other vendors discuss how to implement protocols like OpenFlow or how to expose pieces of their underlying systems to developers, Cisco has built a platform to allow access into pieces and parts of the OS. You can write applications in Java or Python to pull data from the system or push configurations to it. The process is slowly being rolled out to the major Cisco platforms. The support for the majority of the Nexus switching line should give the reader a good idea of where Cisco thinks this technology will be of best use.

One of the specific applications that Cisco showed off to us using onePK is the use of Puppet to provision switches from bare metal to functioning with a minimum of human effor. Puppet integration was a big underlying topic at both Cisco and Juniper (more on that in the Juniper NFD5 post). Puppet is gaining steam in the netowrking industry as a way to get hardware up and running quickly with the least amount of fuss. Server admins have enjoyed the flexibility of Puppet for a some time. It’s good to see well-tested and approved software like this being repurposed for similar functionality in the world of routing and switching.

Next up was a discussion about the Cisco ONE network controller. Controllers are a very hot topic in the network world today. OpenFlow allows a central management and policy server to push information and flow data into switches. This allows network admins to get a “big picture” of the network and how the packets are flowing across it. Having the ability to view the network in its entirity also allows admins to start partitioning it in a process called “slicing.” This was one of the first applications that the Stanford wiz kids used OpenFlow to accomplish. It makes sense when you think about how universities wanted to partition off their test networks to prevent this radical OpenFlow idea from crashing the production hardware. Now, we’re looking at using slicing for things like multi-tenancy and security. The building blocks are there to make some pretty interesting leaps. The real key is that the central controller have the ability to keep up with the flows being pushed through the network. Cisco’s ONE controller not only speaks OpenFlow, but onePK as well. This means that while the ONE controller can talk to disparate networking devices running OpenFlow, it will be able to speak much more clearly to any Cisco devices you have lying around. That’s a pretty calculated play from Cisco, given that the initial target for their controller will be networks populated primarily by Cisco equipment. The use case that was given to us for the Cisco ONE controller was replacing large network taps with SDN options. Fans of NFD may remember our trip to Gigamon. Cisco hadn’t forgotten, as the network tap they used as an example in their slide looked just like the orange Gigamon switch we saw at a previous NFD.

After the presentations from the Borderless team, we ended the day with an open discussion around a few topics. This is where the real fun started. Here’s the video:

The first hour or so is a discussion around hybrid switching. I had some points in here about the standoff between hardware and software people not really wanting to get along right now. I termed it a Mexican Standoff because no one really wants to flinch and go down the wrong path. The software people just want to write overlays and things like and make it run on everything. The entrenched hardware vendors, like Cisco, want to make sure their hardware is providing better performance than anyone else (because that’s where their edge is). Until someone decides to take a chance and push things in different directions, we’re not going to see much movement. Also, around 1:09:00 is where we talked a bit about Cisco jumping into the game with a pure OpenFlow switch without much more on top of it. This concept seemed a bit foreign to some of the Cisco folks, as they can’t understand why people wouldn’t want IOS and onePK. That’s where I chimed in with my “If I want a pickup truck, I don’t take a chainsaw to a school bus.” You shouldn’t have to shed all the extra stuff to get the performance you want. Start with a smaller platform and work your way up instead of starting with the kitchen sink and stripping things away.

Shortly after this is where the fireworks started. One of Cisco’s people started arguing that OpenFlow isn’t the answer. He said that the customer he was talking to didn’t want OpenFlow. He even went so far as to say that “OpenFlow is a fantasy because it promises everything and there’s nothing in production.” (about 1:17:00) Folks, this was one of the most amazing conversations I’ve ever seen at a Network Field Day event. The tension in the room was palpable. Brent and Greg were on this guy the entire time about how OpenFlow was solving real problems for customers today, and in Brent’s case he’s running it in production. I really wonder how the results of this are going to play out. If Cisco hears that their customers don’t care that much about OpenFlow and just want their gear to do SDN like in onePK then that’s what they are going to deliver. The question then becomes whether or not network engineers that believe that OpenFlow has a big place in the networks of tomorrow can convince Cisco to change their ways.

If you’d like to learn more about Cisco, you can find them at
http://www.cisco.com
/go/dc.  You can follow their data center team on Twitter as @CiscoDC.

Tom’s Take

Cisco’s Data Center group has a lot of interesting things to say about programmability in the network. From discussions about APIs to controllers to knock down, drag out aruguments about what role OpenFlow is going to play, Cisco has the gamut covered. I think that their position at the top of the network heap gives them a lot of insight into what’s going on. I’m just worried that they are going to use that to push a specific agenda and not embrace useful technologies down the road that solve customer problems. You’re going to hear a lot more from Cisco on software defined networking in the near future as they begin to roll out more and more features to their hardware in the coming months.

Tech Field Day Disclaimer

Cisco 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, Cisco provided me with a breakfast and lunch at their offices.  They also provided a Moleskine notebook, a t-shirt, and a flashlight toy.  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 NFD5 Blog Posts

NFD5: Cisco onePK – Terry Slattery

NFD5: SDN and Unicorn Blood – Omar Sultan

Network Field Day 5

Posted on by
3

NFD-Logo-wpcf_400x400

It’s time again for more zany fun in San Jose with the Tech Field Day crew!  I will be attending Network Field Day 5 in San Jose March 6-8.  This time, I was honored to be included as a member of the organizing committee for the event.  There were lots of discussions about timing of the event, sessions that would be interesting to the delegates and the viewers, and even a big long list of delegates to evaluate.  That last part is never fun.  There are so many great people out there that would be a great fit at any Field Day event.  Sadly, there are only so many people that can attend.  The list for Network Field Day 5 includes the following wonderful people:

http://techfieldday.com/wp-content/uploads/2012/08/Carroll-wpcf_60x60.jpeg Brandon Carroll @BrandonCarroll
CCIE Instructor, Blogger, and Technology Enthusiast
http://techfieldday.com/wp-content/uploads/2012/08/brent-salisbury1-wpcf_60x60.jpeg Brent Salisbury @NetworkStatic
Brent Salisbury works as a Network Architect, CCIE #11972.
http://techfieldday.com/wp-content/uploads/2012/08/cmcnamara-headshot-2011-color-scaled-wpcf_42x60.jpg Colin McNamara @ColinMcNamara
Colin McNamara is a seasoned professional with over 15 years experience with network and systems technologies.
http://techfieldday.com/wp-content/uploads/2012/08/ethan-banks-headshot-500x667-wpcf_44x60.jpg Ethan Banks @ECBanks
Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions, and technology corporations.
http://techfieldday.com/wp-content/uploads/2012/08/Ferro-wpcf_60x39.jpg Greg Ferro @EtherealMind
Over the last twenty odd years, Greg has worked Sales, Technical and IT Management but mostly he delivers Network Architecture and Design. Today he works as a Freelance Consultant for F100 companies in the UK & Europe focussing on Data Centres, Security and Operational Automation.
http://techfieldday.com/wp-content/uploads/2012/09/johnherbert-wpcf_60x60.jpeg John Herbert @MrTugs
John has worked in the networking industry for 14 years, and obtained his CCIE Routing & Switching in early 2001.
http://techfieldday.com/wp-content/uploads/2012/08/OBrien-wpcf_60x60.jpeg Josh O’Brien @JoshOBrien77
Josh has worked in the industry for 14 years and is now serving as CTO in the Telemedicine sector.
http://techfieldday.com/wp-content/uploads/2012/08/IMG_0264-002-wpcf_60x60.jpg Paul Stewart @PacketU
Paul Stewart is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work.
http://techfieldday.com/wp-content/uploads/2012/08/Slattery-wpcf_60x50.jpg Terry Slattery
Terry Slattery, CCIE #1026, is a senior network engineer with decades of experience in the internetworking industry.

There’s likely to be a couple more people on that list before all is said and done.  I really wish that we could have an event with all the potential delegates.  Maybe one day after I finally buy my own 747 we’ll have enough airline seats to fly everyone to Silicon Valley.

Network Field Day 5 Sponsors

There will be an extra full lineup of sponsors this time around.  A few of the details are still being finalized, but here’s the lineup so far:

http://techfieldday.com/wp-content/uploads/2012/08/Juniper-wpcf_100x28.gif http://techfieldday.com/wp-content/uploads/2013/01/Secret-Company-wpcf_100x30.png http://techfieldday.com/wp-content/uploads/2012/08/solarwinds_RGB-300x84-wpcf_100x28.jpg

That “secret company” sounds nice and mysterious, doesn’t it? I can’t wait until they’re revealed.  I am always pleased with the lineup of sponsors at each Field Day event.  The leadership and vision provided by these vendors gives us all a great idea of where technology is headed.

What’s Field Day Like?

Network Field Day is not a vacation.  This event will involve starting a day early first thing Wednesday morning and running full steam for two and a half days.  We get up early and retire late.  Wall-to-wall meetings and transportation to and from vendors fill the days.  When you consider that most of the time we’re discussing vendors and presentations on the car ride to the next building, there’s very little downtime.  We’ve been known to have late night discussions about OpenFlow and automation until well after midnight.  If that’s your idea of a “vacation” then Tech Field Day is a paradise.

Tech Field Day – Join In Now!

Everyone at home is as much a participant in Tech Field Day as the delegates on site.  At the last event we premiered the ability to watch the streaming video from the presentations on mobile devices.  This means that you can tune in from just about anywhere now.  There’s no need to stay glued to your computer screen.  If you want to tune out to our last presentations of the day from the comfort of your couch with your favorite tablet device then feel free by all means.  Don’t forget that you can also use Twitter to ask questions and make comments about what you’re seeing and hearing.  Some of the best questions I’ve seen came from the home audience.  Use the hashtag #NFD5 during the event.  Note that I’ll be tagging the majority of my tweets that week with #NFD5, so if the chatter is getting overwhelming you can always mute or filter that tag.

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 delegates are in this for the truth, the whole truth, and nothing but the truth.

Lightening The Linksys Load

Posted on by
1

If you’re in the mood to pick up an interesting present for someone this holiday season, you may be in luck. Rumor has it that Cisco is looking to offload Linksys. Again. According to the rumors, Cisco is shopping Linksys to manufacturers of TVs for a lot less than the $500 million they paid for it a decade ago. This isn’t the first time that there have been rumors about the demise of Linksys. A year and a half ago, I even had something to say about it. My opinion of the situation hasn’t really changed from that previous blog post. What has changed is the way that Linksys has been marketed.

Cisco has known for a while that it’s fighting a losing battle in the consumer market. Cheaper vendors have been attacking them on price. Premium vendors have been offering significantly more advanced devices. It also doesn’t help that the Linksys brand itself has been murky for the past several months. Cisco has attached the Linksys name not only to the shrink wrapped boxes you find in your favorite dying big box retailer but also to many of their small business products as well. You can now buy a Linksys phone system, switches, wireless APs, and routers. Many of these products used to carry a Cisco SMB brand but were rebranded in order to give Linksys a bit more robust feel. This was probably a bad decision on Cisco’s part. No matter which piece of equipment you choose to carry the Linksys logo, most of your SMB customer base is going to have visions of trying to buy a wireless router at Best Buy. I had a very similar conversation a few years ago with D-Link. One of their reps came in to try and sell me on their enterprise line of switches. At this point I said to myself, “D-Link makes enterprise gear?!?” I was informed they were a large vendor of this type of gear. They were rather popular in Europe, according to the rep. My response? “So is David Hasselhoff.” No matter what you build with that brand, you’re still going to conjure images of your consumer brand. Linksys shares that same fate.

Cisco has made no secret that they want to start moving toward software as the core of their network offerings. When John Chambers finally retires in a couple of years, he wants to be sure that he hit his last market transition. In order to make the voyage to the Land of Software he’s going to have to shed some weight. I think Linksys is the biggest piece of that weight. After the Flip and ümi closures last year, Chambers needed some breathing room before turning the lights out in other areas. Linksys still holds enough value to fetch a fair price on the open market. Seeing as it’s being shopped to TV manufacturers this would be an excellent opportunity for a mid-market player to catch up to Samsung or Vizio in terms of network offerings. All these devices are going to need to be networked. Most of them come with wireless cards today. With 802.11ad still too far off to be of useful impact today for short-range high speed networking, manufacturers are going to need a stop-gap solution today. Likewise, Cisco has to make the decision whether or not to invest the R&D in the brand to get to those new protocols and devices. Most consumers today own an 802.11n wireless router of some kind. Those people are unlikely to buy a new device until there’s a protocol change or some kind of massive increase in throughput. And even when it does come time to make that upgrade, users are unlikely to spend the kind of money that it would take to recover the cost of development. If Cisco really wants to concentrate on software in the future, doubling down on unprofitable hardware today makes little sense.

Tom’s Take

My Cisco Valet Plus, which is really just a rebranded Linksys WRT310N, now sits on my bookshelf unused. I finally decided to move on to something that fits my usage profile better. I settled on an Apple Airport Extreme. I now have dual band radios, guest access, and a USB port for my Time Machine backups. I might have been able to get a lot of this in a Linksys device, but I grew tired of trying to figure out which one I needed. There was also a lot of feature similarity between the hardware that only seemed to be limited by firmware instead of hardware. For better or worse, I didn’t buy Linksys. Cisco is hoping that someone will buy it from them now. That buyer is going to get an entrenched consumer networking product that has some life left in it. As for Cisco, they get to rid themselves of a peculiar albatross that has weighed heavily on them as of late. Lets hope the Linksys Diet pays off.

Cisco To Buy Meraki?

Posted on by
13

If you’re in the tech industry, it never seems like there’s any downtime. That was the case today all thanks to my friend Greg Ferro (@etherealmind). I was having breakfast when this suddenly scrolled up on my Twitter feed:

After I finished spitting out my coffee, I started searching for confirmation or indication to the contrary. Stephen Foskett (@SFoskett) provided it a few minutes later by finding the following link:


http://blogs.cisco.com/news/cisco-announces-intent-to-acquire-meraki/

EDIT: As noted in the comments below, Brandon Bennett (@brandonrbennett) found a copy of the page in Google’s Webcache. The company in the linked page says “Madras”, but the rest of the info is all about Meraki. I’m thinking Madras is just a placeholder.

For the moment, I’m going to assume that this is a legitimate link that is really going to point to something soon. I’m not going to assume Cisco has a habit of creating “Cisco announces intent to acquire X Company” pages out of habit, like this famous Dana Carvey SNL video. In that case, the biggest question now becomes…

Why Meraki?

I’ll admit, I was shaking my head for a bit on this one. Cisco doesn’t buy companies because of hardware technology. They’ve got R&D labs that can replicate pretty much anything under the sun given enough time. Cisco instead usually purchases for innovative software platforms. They originally bought Airespace for the controller architecture and managment software that originally became WCS. The silicon isn’t as important, since Cisco makes their own.

Meraki doesn’t really make anything innovative from a hardware front. Their APs use reference architecture. Their switch and firewall offerings are also pretty standard fare with basic 10/100/1000 connectivity and are likely based on Broadcom reference designs as well. What exactly draws in a large buyer like Cisco? What is unique among all those products?

Cisco’s Got Its Head In The Clouds

The single thing that is similar across the whole Meraki line is the software. I talked a bit about it in my Wireless Field Day 2 post on Meraki. Their single management platform allows them to manage switches, firewalls, and wireless in one single application. You can see all the critical information that your switches are pumping out and program them accordingly. The demo I saw at WFD2 was isolating a hungry user downloading too much data with a combination of user identification and pushing an ACL down to that user limiting their bandwidth for certain kinds of traffic without totally locking that person out of the network. That’s the kind of thing that Cisco is looking for.

With the announcement of onePK, Cisco really wants to show off what they can do when they start plugging APIs into their switches and routers. But simply opening an API doesn’t do anything. You’ve got to have some kind of software program to collect data from the API and then push instructions back down to it to accomplish a goal. And if you can decentralize that control to somewhere in the cloud, you’ve got a recipe for the marketing people to salivate over. For now, I thought that would be some kind of application borne out of the Cisco Prime family.

If the Meraki acquisition comes to fruition, Meraki’s platform will likely be rebranded as a member of the Cisco Prime family and used for this purpose. It will likely be positioned initially towards the SMB and medium enterprise customers. In fact, I’ve got three or four use cases for this management software on Cisco hardware today with my customers. This would do a great job of replacing some of the terrible management platforms I’ve seen in the past, like Cisco Configuration Assisstant (CCA) and the unmentioned product Cisco was pitching as a hands-off way to manage sub 50-node networks. By allowing the Meraki management software to capture data from Cisco devices, you can have a proven portal to manage your switches and APs. Add in the ability to manage other SMB devices, such as a UC 500 or a small 800-series router and you’ve got a smooth package you can sell to your customers for a yearly fee. Ah ha! Recurring, cloud based income! That’s just icing on the cake.

EDIT: 6:48 CST – Confirmed by a Cisco press release and as well by Techcrunch and CRN.

Tom’s Take

Ruckus just had their IPO. It was time for a shake up in the upstart wireless market. Meraki was the target that most people had in mind. I’d been asked by several traditional networking vendors recently who I thought was going to be the next wireless company to be acquired, and every time my money landed on Meraki. They have a good software platform that helps them manage inexpensive devices. All their engineering goes into the software. By moving away from pure wireless products, they’ve raised their profile with their competitors. I never seriously expected Meraki to dethrone Cisco or Brocade with their switch offerings. Instead, I saw the Meraki switches and firewalls as an add-on offering to compliment their wireless deployments. You could have a whole small office running Meraki wireless, wired, and security deployments. Getting the ability to manage all those devices easily from one web-based application must have appealed to someone at Cisco M&A. I remember from my last visit to the Meraki offices that their name is an untranslatable word from Greek that means “to do something with intense passion.” It also can mean “to have a place at the table.” It does appear that Meraki found a place at a very big table indeed.