ESHARP.NET

Technology and life with Eyvonne Sharp

Things to say

By Leave a Comment

I need to write again. I have things to say.

This year has been the best of times and the worst of times. In many ways, I’ve treasured time with family as our home has become the epicenter of our lives. Long-distance friendships have been cultivated in the margins of stay-at-home rules and priorities have been reordered. At the same time, trips were canceled, experiences delayed or denied, graduations missed and opportunities lost. Fortunately, our family has, to date, avoided the worst consequences of the pandemic. We are weathering well.

As 2020 winds down, I experience relief tinged with apprehension. There will be no magic spell when the year advances a single digit. Our world will look the much same on 1-1-2021 as on 12-31-2020 even as the symbolism of a new year buoys our spirits and revives our hopes.

These times have highlighted our need for human connection, even in a field where we take pride in our independence, where many of us are introverts who love working alone and are more comfortable with code than with conversation. I’ve been reminded that the greatest triumphs of my career have not been technical but relational. Solid technology has been merely a backdrop for the most meaningful interactions.

With this in mind, I’m reviving the blog. I hope to synthesize thoughts from technology, life, family, work, and culture to help us think through what we’re doing here, what really matters, and how to live and work as whole people. I’m sure I’ll geek out about technology, especially networking and Google Cloud, from time to time. I’ll talk about what I’m reading and ideas that capture my imagination. Expect a well-placed rant occasionally.

I have a few topics in mind already: how culture shapes our work, how loyalty is used and misused, situations technologists can control and situations they can’t, how we view waste and how that impacts our work and lives, building meaningful relationships in technology work: how to do it and how not to do it, toxicity at work: when to cope and when to run.

Regardless, this will be a place where I preach to myself, where ideas become clearer on paper, and where we think through how to practice our craft in the larger context of life.

9 Easy Ways to Break a Cisco Network

By 4 Comments

We’ve all been there. You make a simple configuration change that should have no impact on production traffic. Suddenly your phone begins to ring, or worse, you lose access to the equipment you were working on.

Here are some common mistakes network engineers make on Cisco gear that cause unexpected outages.

  1. Forget the add command when adding a vlan to a trunk port.
  2. Run no ip access list on a Cisco Router like you would on an ASA firewall.
  3. Issue a global spanning tree command instead of an interface specific command.
  4. Apply an untested ACL on the interface you use to manage the router.
  5. Click OK on an ASDM dialogue box without reading and understanding the impact.
  6. Delete the current flash image from disk without changing the boot command.
  7. Issue the debug all command.
  8. Typo the subnet on a static route when you’re redistributing static.
  9. Forget to cancel the reload in command.

If you’ve worked on Cisco networks for any length of time, you’ve probably made one of these mistakes or been in the proximity of another engineer who has made one of them.

If you can relate to these simple outage-inducing errors, join Jordan Martin, Phil Gervasi, and me as we launch a new live-stream video roundtable called the Network Collective. In our first episode, we’ll hear about some stomach-churning outages caused by each of our guests and lessons learned from those experiences. The live stream begins on April 11th at 7 pm ET. Watch live and comment on Twitter with the hashtag #NetworkCollective. If you can’t watch live, shows will be available in video and audio format.

For more information about the Network Collective visit the web site and follow NetCollectivePC on Twitter.

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

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.