ESHARP.NET

Technology and life with Eyvonne Sharp

SD-WAN Series Part 4: Viptela

By 4 Comments

This week we take a look at another SD-WAN vendor, Viptela.

In this video I highlight:
  • The difference between companies who approach SD-WAN from a WAN Optimization background and those who have a routing background
  • End-to-end segmentation features
  • Encryption and key management
  • Zero-touch provisioning
  • Cloud connectivity
  • Observations from hands-on experience deploying Viptela in a production environment
For full details, watch the video below:

 

For more information about Viptela, check out their presentations from Networking Field Day 13

Cisco Meraki Adds Beta BGP Support to MX Appliances

By Leave a Comment

Cisco Meraki LogoCisco Meraki has introduced beta BGP support in their Meraki MX appliances. According to product documentation, the latest version of Meraki code now supports BGP (IBGP and EBGP) — the caveat, you’ll need to contact your Meraki Sales Rep or Support to enable the features.

If you’re interested in implementing BGP in your existing Meraki environment, you’ll want to read the documentation carefully. It appears that you must run IBGP in the Meraki Site-to-Site VPN in order to redistribute routes via EBGP.

It’s unclear if you can limit redistribution with route filters or influence upstream routes with BGP communities.

BGP support will allow you to eliminate the need for static routes  into a Meraki environment. BGP will also help improve data center redundancy and failover. However, many of the features we’ve come to love (or hate) with BGP appear to be absent.

Check out the product documentation for yourself:
https://documentation.meraki.com/MX-Z/Networks_and_Routing/BGP

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

Network Field Day 14 and the Best Community Ever!

By 1 Comment

This week, I will participate as a first-time delegate for Networking Field Day 14. I’m excited, honored, and a bit intimidated by this great opportunity.

At Tech Field Day, industry vendors present intensely technical product information to network practitioners. The presentations are live-streamed, complete with unscripted question and answer sessions, and later archived over at the Tech Field Day web site. Delegates ask probing questions in a public forum and are often able to separate marketing from reality in ways that were impossible before social media.

Many of the #NFD14 delegates I’ve known through Twitter and have met at Cisco Live. I’ve listened to, and benefited from, Greg Ferro’s Packet Pushers podcast for years. Others will be new faces for me.

The Best Community Ever

Tech Field Day represents the best of the IT community. But I must say the networking community rises above any other, professional or non-professional, community which I’ve endeavored to be a part. They’re welcoming, inclusive, and downright helpful.

In many instances, I’ve reached out to a subject matter expert on Twitter to discuss a particular challenge I’ve faced. In one instance, I exchanged several emails about the benefits and downsides of ASA clustering – when to use it and when to implement a standard HA pair instead. In other cases, I’ve used the networking community to fact-check vendors. For example, Vendor A says Vendor B’s hardware falls down in high-load scenarios. Is that really true? The community has helped clarify.

Beyond these great traits, members of the networking community fulfill and break the stereotype of the “IT Guy” at the same time. Most of them fly their geek fly high — without apology. But at the same time, they’re witty, snarky, funny and more diverse than any stereotype would indicate. In my experience, their snark is lighthearted and rarely directed at one another. Vendors, executive leadership, corporate processes, and horrible applications bear the brunt of community criticism –- and in many instances rightfully so. Anyone, at any skill level, with a legitimate desire to learn their craft and grow as a network practitioner, will be welcomed.

So, if you tune into the live stream of Networking Field Day 14 and have a question, reach out! Use the #NFD14 hash tag or mention one of us in your tweets. I’ve done it in the past. Through the delegates, you’ll have direct access to vendors in ways you may not otherwise enjoy. Take advantage of it. We’re one big community with the same problems and challenges. If you have a question, I’m sure others do too. I hope you’ll join us for the live stream sessions next week. I’ll blog as I’m able but for instant (and often stream-of-consciousness) comments, watch my Twitter stream. We’ll enjoy experiencing networking awesomeness together!

This post wouldn’t be complete without a shout-out to those in the network community who have reached out to me personally, helped me be a part, and encouraged my participation even when I felt clueless and bumbling. Follow these folks on Twitter, you won’t regret it.

Tom Hollingsworth (@networkingnerd)
Amy Renee (@amyengineer)
Chris Church (@layer_3)
Ethan Banks (@ecbanks)
Greg Ferro (@etherealmind)
Scott McDermitt (@ScottM32768)

 

And, check out the Network Field Day 14 delegate page to follow all the #NFD14 delegates.

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.