Tag Archives: #CLEUR

Meraki Is Almost An Enterprise Solution

Posted on by
2

You may remember a three or so years ago when I famously declared that Meraki is not a good solution for enterprises. I know the folks at Meraki certainly haven’t. The profile for the hardware and services has slowly been rising inside of Cisco. More than just wireless with the requisite networking components, Meraki has now embraced security, SD-WAN, and even security cameras. They’ve moved into a lot of areas that customers have been asking about while also still trying to maintain the simplicity that Meraki is known for.

Having just finished up a Meraki presentation during Tech Field Day Extra at Cisco Live Europe, I thought it would be a good time to take a look at the progress that Meraki has been making toward embracing their enterprise customer base. I’m not entirely convinced that they’ve made it yet, but the progress is starting to look good.

Playing for Scale

The first area where Meraki is starting to really make strides is in the scalability department. This video from Tech Field Day Extra is all about new security features in the platform, specifically with firewalls. Take a quick look:

Toward the end of the video is one of the big things I got excited about. Meraki has introduced rule groups into their firewall platform. Sounds like a strange thing to get excited about, right? Kind of funny how the little things end up mattering in the long run. The real reason I’m getting excited about it has nothing to do with the firewall or even the interface. It has everything to do with being scalable.

One of the reasons why I’ve always seen Meraki as a solution that is more appropriate for small businesses is the lack of ability to scale. Meraki’s roots as a platform built for small deployments means that the interface has always been focused on making it easy to configure. You may remember from my last post that I wasn’t a fan of the way everything felt like it was driven through deployment wizards. Hand holding me through my first firewall deployment is awesome. Doing it for my 65th deployment is annoying. In enterprise solutions I can easily script or configure this via the command line to avoid the interface. But Meraki makes me use the UI to get it done.

Enterprises don’t run on wizards. They don’t work with assistance turned on. Enterprises need scalability. They need to be able to configure things to run across dozens or hundreds of devices quickly and predictably. They need that to happen quickly, too. Sure, it may only take four minutes to configure something via the firewall. Now, multiply that by 400 devices. Just that one little settings going to take over 26 hours to configure. And that’s assuming you don’t need to take time for a break or to sleep. When you’re working at the magnitude of an enterprise, those little shortcuts matter.

You might be saying right now, “But what about policies and groups for devices?” You would be right that groups can definitely speed up the process. But how many groups do you think the average enterprise would have for devices? I doubt all routers or switches or firewalls would conveniently fit into a single group. Or even ten groups. And there’s always the possibility that a policy change among those groups may get implemented correctly nine times out of those ten. The tenth time it gets an error that could still affect hundreds of devices. You see how this could get out of hand.

That’s why I’m excited about the little things like firewall groups. It means that Meraki is starting to see that these things need to be programmatically done. Building a series of policies in software makes it easy to deploy over and over again through scripting or enhanced device updating. Polices are good for rules. They’re not so good for devices. So the progress means that Meraki needs to keep building toward letting us script these deployments and updates across the entire organization.

Hextuple Option

The other thing that’s neatly buried at the end of the video is courtesy of a question from my friend Jody Lemoine (@GhostInTheNet). He points out that there are IPv6 addresses on the dashboard. The Meraki presenters confirm that they are testing IPv6 support natively and not just in bridged mode. Depending on when you read this post in the future, it may even be out already. You know that I’m an IPv6 fan and I’ve been tough on Meraki in the past about their support for it. So I’m happy to see that it’s in the works.

But more importantly I’m pleased that Meraki has jumped into a complex technical solution with both feet. Enterprises don’t need a basic set of services. They don’t want you to just turn on the twenty most common settings. Enterprises need odd things sometimes. They need longer VPN lifetimes or weird routing LSA support. Sometimes they need to do the really odd things because their thousand-odd devices really have to have this feature turned on to make it work.

Now, I’ve rightfully decried the idea that you should just do whatever your customers want, but the truth is that doing something silly for one customer isn’t the same as doing it for a dozen or more that are asking for a feature. Meraki has always felt shy to me about the way they implement features in their software. It’s almost the opposite of Cisco, in a way. Cisco is happy to include corner-case options on software releases on a whim to satisfy million-dollar customers. Meraki, on the other hand, has seemed to wait until well past critical mass to turn something on. It almost feels like you have to break down their door to get something advanced enabled.

To me, IPv6 is the watershed. It’s something that the general public doesn’t think they need or doesn’t know they really should have. Cisco has had IPv6 support in IOS for years. Meraki has been dragging along until they feel the need to implement it. But implementing it in 2020 makes me feel they will finally start implementing features in a way that makes sense for users. Hopefully that also means they’ll be more responsive to their Make A Wish feature requests and start indexing how many customers really want a certain feature or certain option enabled.

Napoleon Complex

The last thing that I’ll say about the transformation of Meraki is about their drive to embrace complexity. I know that Russ White and I don’t always see eye-to-eye about complexity. But I feel that hiding it is ultimately detrimental to IT staff members. Sure, you don’t want the CEO or the janitor in the wireless system deploying new SSIDs on a daily basis or disabling low data rates on APs. But you also need to have access to those features when the time comes. That was one of my big takeaways in my previous Meraki post.

I know that Meraki prides themselves on having a clean, easy-to-use interface. I know that it’s going to take a while before Meraki starts exposing their interface to power users. But, it also took Microsoft a long time to let people start doing massive modifications via PowerShell. Or Apple letting users go wild under the hood. These platforms finally opened a little and let people do some creative things. Sure, Apple IOS is still about as locked down as Meraki is, but every WWDC brings some new features that can be tinkered with here and there. I’m not expecting a fully complexity-embracing model in the next couple of years from Meraki, but I feel that the right people internally are starting to understand that growth comes in the form of enterprise customers. Enterprises don’t shy away from complexity. They don’t want it hidden. They want to see it and understand it and plan for it. And, ultimately, embrace it.

Tom’s Take

I will freely admit that I’m hard on the Meraki team. I do it because I see potential. I remember seeing them for the first time all the way back at Wireless Field Day 2 in their cramped San Francisco townhome office. In the years since the Cisco acquisition they’ve grown immensely with talent and technology. The road to becoming something more than you start out doing isn’t easy. And sometimes you need someone willing to stop you now and then and tell you where directions make more sense. I don’t believe for one moment that my armchair quarterbacking has really had a significant impact on the drive that Meraki has to get into larger enterprises. But I hope that my perspective has shown them how the practitioners of the world think and how they’re slowly transforming to meet those needs and goals. Hopefully in the next couple of years I can write the final blog post in this trilogy when Meraki embraces the enterprise completely.

Is ACI Coming For The CLI?

Posted on by
4

I’m soon to depart from Cisco Live Barcelona. It’s been a long week of fun presentations. While I’m going to avoid using the words intent and context in this post, there is one thing I saw repeatedly that grabbed my attention. ACI is eating Cisco’s world. And it’s coming for something else very soon.

Devourer Of Interfaces

Application-Centric Infrastructure has been out for a while and it’s meeting with relative success in the data center. It’s going up against VMware NSX and winning in a fair number of deals. For every person that I talk to that can’t stand it I hear from someone gushing about it. ACI is making headway as the tip of the spear when it comes to Cisco’s software-based networking architecture.

Don’t believe me? Check out some of the sessions from Cisco Live this year. Especially the Software-Defined Access and DNA Assurance ones. You’re going to hear context and intent a lot, as those are the key words for this new strategy. You know what else you’re going to hear a lot?

Contract. Endpoint Group (EPG). Policy.

If you’re familiar with ACI, you know what those words mean. You see the parallels between the data center and the push in the campus to embrace SD-Access. If you know how to create a contract for an EPG in ACI, then doing it in DNA Center is just as easy.

If you’ve never learned ACI before, you can dive right in with new DNA Center training and get started. And when you finally figured out what you’re doing, you can not only use those skills to program your campus LAN. You can extend them into the data center network as well thanks to consistent terminology.

It’s almost like Cisco is trying to introduce a standard set of terms that can be used to describe consistent behaviors across groups of devices for the purpose of cross training engineers. Now, where have we seen that before?

Bye Bye, CLI

Oh yeah. And, while you’re at it, don’t forget that Arista “lost” a copyright case against Cisco for the CLI and didn’t get fined. Even without the legal ramifications, the Cisco-based CLI has been living on borrowed time for quite a while.

APIs and Python make programming networks easy. Provided you know Python, that is. That’s great for DevOps folks looking to pick up another couple of libraries and get those VLANs tamed. But it doesn’t help people that are looking to expand their skillset without leaning an entirely new language. People scared by semicolons and strict syntax structure.

That’s the real reason Cisco is pushing the ACI terminology down into DNA Center and beyond. This is their strategy for finally getting rid of the CLI across their devices. Now, instead of dealing with question marks and telnet/SSH sessions, you’re going to orchestrate policies and EPGs from your central database. Everything falls into place after that.

Maybe DNA Center does some fancy Python stuff on the back end to handle older devices. Maybe there’s even some crazy command interpreters literally force-feeding syntax to an ancient router. But the end goal is to get people into the tools used to orchestrate. And that day means that Cisco will have a central location from which to build. No more archaic terminal windows. No more console cables. Just the clean purity of the user interface built by Insieme and heavily influenced by Cisco UCS Director.

Tom’s Take

Nothing goes away because it’s too old. I still have a VCR in my house. I don’t even use it any longer. It sits in a closet for the day that my wife decides she wants to watch our wedding video. And then I spend an hour hooking it up. But, one of these days I’m going to take that tape and transfer it to our Plex server. The intent is still the same – my wife gets to watch videos. But I didn’t tell her not to use the VCR. Instead, I will give her a better way to accomplish her task. And on that day, I can retire that old VCR to the same pile as the CLI. Because I think the ACI-based terminology that Cisco is focusing on is the beginning of the end of the CLI as we know it.

NBase-ing Your Wireless Decisions

Posted on by
8

Cat5

Copper is heavy. I’m not talking about it’s atomic weight of 63 or the fact that bundles of it can sag ceiling joists. I’m talking about the fact that copper has inertia. It’s difficult to install and even more difficult to replace. Significant expense is incurred when people want to run new lines through a building. I never really understood how expensive a proposition that was until I went to work for a company that run copper lines.

Out of Mind, Out of Sight

According to a presentation that we saw at Tech Field Day Extra at Cisco Live Milan from Peter Jones at Cisco, Category 5e and 6 UTP cabling still has a significant install base in today’s organizations. That makes sense when you consider that 5e and 6 are the minimum for gigabit Ethernet. Once we hit the 1k mark with speeds, desktop bandwidth never really increased. Ten gigabit UTP Ethernet is never going to take off outside the data center. The current limitations of 10Gig over Cat 6 makes it impossible to use in a desktop connectivity situation. With a practical limit of around 50 meters, you practically have to be on top of the IDF closet to get the best speeds.

There’s another reason why desktop connectivity stalled at 1Gig. Very little data today gets transferred back and forth between desktops across the network. With the exception of some video editing or graphics work, most data is edited in place today. Rather than bringing all the data down to a desktop to make changes or edits, the data is kept in a cloud environment or on servers with ample fast storage space. The desktop computer is merely a portal to the environment instead of the massive editing workstation of the past. If you even still have a desktop at all.

The vast majority of users today don’t care how fast the wire coming out of the wall is. They care more about the speed of the wireless in the building. The shift to mobile computing – laptops, tablets, and even phones, has spurred people to spend as little time as possible anchored to a desk. Even those that want to use large monitors or docking stations with lots of peripherals prefer to connect via wireless to grab things and go to meetings or off-site jobs.

Ethernet has gone from a “must have” to an infrastructure service supporting wireless access points. Where one user in the past could have been comfortable with a single gigabit cable, that new cable is supporting tens of users via an access point. With sub-gigabit technologies like 802.11n and 802.11ac Wave 1, the need for faster connectivity is moot. Users will hit overhead caps in the protocol long before they bump into the theoretical limit for a single copper wire. But with 802.11ac Wave 2 quickly coming up on the horizon and even faster technologies being cooked up, the need for faster connectivity is no longer a pipe dream.

All Your NBase

Peter Jones is the chairman of the NBaseT Alliance. The purpose of this group is to decide on a standard for 2.5 gigabit Ethernet. Why such an odd number? Long story short: It has to do with splitting 10 gigabit PHY connections in fourths and delivering that along a single Cat 5e/6 wire. That means it can be used with existing cable plants. It means that we can deliver more power along the wire to an access point that can’t run on 802.3af power and needs 802.3at (or more). It means we don’t have to rip and replace cable plants today and incur double the costs for new technology.

NBaseT represents a good solution. By changing modulations and pumping Cat 5e and 6 to their limits, we can forestall a cable plant armageddon. IT departments don’t want to hear that more cables are needed. They’ve spent the past 5 years in a tug-of-war between people saying you need 3–4 drops per user and the faction claiming that wireless is going to change all that. The wireless faction won that argument, as this video from last year’s Aruba Airheads conference shows. The idea of totally wireless office building used to be a fantasy. Now it’s being done by a few and strongly considered by many more.

NBaseT isn’t a final solution. The driver for 2.5 Gig Ethernet isn’t going to survive the current generation of technology. Beyond 802.11ac, wireless will jump to 10 Gigabit speeds to support primary connectivity from bandwidth hungry users. Copper cabling will need to be updated to support this, as fiber can’t deliver power and is much too fragile to support some of the deployment scenarios that I’ve seen. NBaseT will get us to the exhaustion point of our current cable plants. When the successor to 802.11ac is finally ratified and enters general production, it will be time for IT departments to make the decision to rip out their old cable infrastructure and replace it with fewer wires designed to support wireless deployments, not wired users.

Tom’s Take

Peter’s talk at Tech Field Day Extra was enlightening. I’m not a fan of the proposed 25Gig Ethernet spec. I don’t see the need it’s addressing. I can see the need for 2.5Gig on the other hand. I just don’t see the future. If we can keep the cable plant going for just a couple more years, we can spend that money on better wireless coverage for our users until the next wave is ready to take us to 10Gig and beyond. Users know what 1Gig connectivity feels like, especially if they are forced down to 100Mbps or below. NBaseT gives them the ability to keep those fast speeds in 802.11ac Wave 2. Adopting this technology has benefits for the foreseeable future. At least until it’s time to move to the next best thing.