ESHARP.NET

Technology and life with Eyvonne Sharp

Cisco’s Identity Crisis: Complexity, Pride, and SD-WAN

By 11 Comments

Our Cisco team has been reaching out to get feedback on our relationship with Cisco and its products — a healthy practice for any vendor. I’ve tried to be open, honest, and consistent in all our talks.

As I mentally review our conversations, I conclude I’ve been contradictory. On one hand, I’ve talked about how the industry is changing and Cisco’s products need to evolve in a software-defined marketplace. At the same time, I’ve decried their decision to move last-generation data center products to the campus portfolio to make way for newer technology.

My contradictions reveal that I haven’t articulated my true concerns. There’s a problem underneath these problems.

I’ve been watching presentations by Russ White on network architecture and complexity. He makes the point, and I’m paraphrasing, that many of our technological advances don’t solve complexity, they move complexity to a different place in the stack. Engineers and architects must determine if the complexity changes are worth the trade-offs. We must ask if added complexity solves the problem at hand without creating undo stress on the system.

With that in mind consider Cisco, a company in love with complexity. They’ve built their business making complex systems. Their culture breeds nerd knobs. They’ve built certification tracks — through which many network engineers have built their careers — to develop expert level understanding of their products.

At the same time, engineers operate in a culture where we believe configuration and operational complexity have inherent value. We unconsciously embrace the following logic: Networks are complex. One must be smart to understand networks. I understand networks. Therefore, I’m smart.

We extrapolate this logic and believe that complexity, for complexity’s sake, makes us superior. In truth, our pride has tied gordian knot with complexity and we don’t know how to unravel it.

Cisco has fallen into this trap. They don’t have a technology problem, they’re suffering an identity crisis.

Enter SD-WAN

SD-WAN is unravelling the knot. Cisco has insisted that the level of complexity we experience in managing our networks is inherent. If you want multi-path selection, prioritized traffic by application, and quality of service you have to make sacrifices. It’s hard of course, and barely possible. After all, we’re solving difficult problems. There are caveats, bugs, and boundary cases but there is no other way. It’s a pipe dream to expect simplicity in management and operation of a system so complex.

The best SD-WAN vendors are proving these assertions wrong. You can have multi-path selection, prioritized traffic by application, and quality of service with an operational efficiency previously unimagined.

Is there complexity in an SD-WAN enabled network? Sure! But strong centralized management tools significantly reduce configuration and operational complexity.

I’ve heard people say, “SD-WAN technologies are not new.”

Using this logic, you could argue that the iPhone wasn’t really something new. When the iPhone was first announced, we already had mobile phones, mp3 players, web browsers, digital cameras, and touch screens. Apple simply created a management interface and software platform to make all those technologies work well together in one small form factor. You could perform the same functions without an iPhone but you had to use 5 separate devices that weren’t designed to work as a unit. The iPhone married several technologies and sparked a movement, reimagined the internet, and enabled an entire generation to communicate in ways they couldn’t before.

Will SD-WAN have the same mass-market consumer enablement as the iPhone? No. But within the microcosm if network engineering, we may soon discover that SD-WAN has sparked its own movement. At the very least, SD-WAN vendors prove the challenges we face can be met in new ways. They’re forcing the stalwarts to sit up and take notice. They bring a promise that we no longer have to choose between unmanageable complexity and non-functional simplicity. In my book, that’s a win regardless of who wins the WAN.

Want more to think about?

Watch Engineer vs. Complexity, Russ White at NANOG

How to use TCL to script commands on Cisco ISR Routers

By 4 Comments

Network engineers often find themselves in a scenario where the key needed to solve a problem is locked inside the box containing the solution. Scripting tools within Cisco’s IOS can help resolve these issues predictably with minimal interruption.

Locked Box

Recently, I had an issue with Cisco ISR routers that connect to carrier equipment. Our carrier hard codes ethernet ports to 100/full and will not support auto negotiation. When a Cisco router, configured by default to auto negotiate, connects to the carrier equipment the network port comes up half-duplex.

Users call. The network is slow. Utilization graphs do not indicate circuit saturation. It’s a lose-lose situation.

On several router models, including Cisco ISR 4000 series, the CLI interface makes this simple problem difficult to solve. You cannot configure the interface for full-duplex without removing the auto negotiate command. However, when you remove auto negotiate, the interface drops and will not reconnect. On a singly connected router, you lose access before you can complete the configuration change.

To work around this problem, use the integrated TCL shell to batch a set of CLI commands. As always, save your config and then issue the reload in command to reboot the router if you lose access. If required by your organization, coordinate a maintenance window. Even if the change works perfectly, you’ll bounce the port when you change the negotiation settings.

reload in 0:05
tclsh      

set fixinterface {
ios_config "interface gi0/0/2" "no negot auto" "speed 100" "duplex full"
}

eval $fixinterface

If all goes well, after you run the script, the interface will drop and renegotiate at 100/full. Log back into your router, reload cancel, and save your config.

You can use these straight-forward commands to automate much more powerful configurations or to fix equally minor, but difficult to resolve, problems.

Identity Matters, ISE and the Future of Networking

By 5 Comments

The more I work with Cisco ISE (Identity Services Engine), the more possibilities I see. In my opinion, it is the most exciting Cisco product since UCS. It’s the only product I’ve seen that provides such a high level of flexibility, control, and centralized configuration for network edge access.

With ISE, you can authenticate, profile, and posture any wired or wireless device that connects to your network. Policy is configured in a centralized controller and pushed to clients when they connect to the network. Based on a myriad of identity and profiling criteria, you can apply a vlan, push a DACL, or inject a Security Group Tag for each client. Today, all of that information is used only for security purposes, but think about the possibilities!

What if every packet on your network is tagged with an identifier based on an amalgam of criteria including: user identity, device type, AD group, application flow, etc? Consider the opportunities if each packet is proactively encoded with a handle that distinguishes it based on complex criteria. What if this criteria is centrally managed and abstracted into a structure that allows you to make quick decisions in hardware? It’s reasonable to conclude that not only security decisions, but routing, QOS, and optimization could be configured based on this identity tag in the packet. And, all of this policy can be pushed from a centralized controller into a data plane of your network.

Granted, ISE doesn’t do this today. It provides authentication, authorization, profiling, and posture services and is solely a security tool. However, the potential power of the platform is limitless.

Of course, ISE is a proprietary Cisco solution that only works well in an all Cisco environment. Aside from standard radius authentication, all of the great ISE features are Cisco only. However, if the solution were more open and interoperable with other networking vendors, it could become a huge platform to improve the entire networking industry.

For Cisco, ISE should be a huge component to their long-term strategy for centralized network control, automation, and security. For a vendor that receives a lot of flack that they’re not a software company, ISE is a great software product.