The post Protect Yourself During Amazon Prime Days! appeared first on Netragard.

This post originally appeared on the Packet Pushers’ Ignition site on July 9, 2019. Premise: I would be cautious about a vendor who sells security as a product or a critical/primary feature. Security-as-a-product is coming to an end. We need to return to making the things we already have work efficiently. There is only so […]

The post Is Security A Feature Or A Product? appeared first on Packet Pushers.

If only I had known how hard it was to say “no” to someone. Based on the response that my post about declining things had gotten I’d say there are a lot of opinions on the subject. Some of them were positive and talked about how hard it is to decline things. Others told me I was stupid because you can’t say no to your boss. I did, however, get a direct message from Paul Lampron (@Networkified) that said I should have a follow up post about saying yes in a responsible manner.

Positively Perfect

The first thing you have to understand about the act of asking something is that we’re not all wired the same way when it comes to saying yes. I realize that article is over a decade old at this point but the ideas in it remain valid, as does this similar one from the Guardian. Depending on your personality or how you were raised you may not have the outcome you were expecting when you ask.

Let me give you a quick personal example. I was raised with a southern style mentality that involves not just coming out and asking for something. You may have seen this expressed as excessive small talk when you are trying to ask for help. You may feel frustrated that the person that is asking you for something doesn’t come right out and ask for it. You may not understand that this person is trying to feel out your emotional responses before asking a question so they’re almost assured to get a positive answer.

Apply that knowledge to the opposite situation. What if the person that has a hard time come right out and asking for something is trying to interpret a request from someone else? Are they going to accept it for what it is? Or are they going to apply their own knowledge to the situation and assume that the person must be asking for something very important because they know how hard it is for them to ask in that situation? Can you see how this disconnect can create strife in the workplace because different values are being applied to something as simple as a request for help? Now you can see the undertones of the earlier conversation about saying “no” to people that constantly ask for things.

How To Say Yes

How do we agree to things then? If we’re trying to get things accomplished we need to be able to ask for help or tell our coworkers we need them to do something. How do we say “yes” and make sure that everyone involved knows that we are doing what we can to make it happen? How do we avoid being overwhelmed?

First, don’t just agree to make people happy. This is the number one issue that needs to be resolved in the workplace. It’s one that starts early on in our careers. We need to put limits on what we’re going to agree to do in order to keep from not having any boundaries whatsoever. Imagine a junior admin or a new hire constantly agreeing to work on things or come in on the weekends to do cutovers and the like. Does that style of work appeal to you? Do you think it’s something that show initiative and desire? If you’ve been in your role for a while do you think it’s a good thing to come in on the weekends? Or does it sound more like this person needs to have a little more work life balance?

If you agree to do things because you’re trying to make your boss happy or show your value to the organization you’re setting yourself up for eventual failure. Good managers and leaders don’t want robots that have zero personal time. They want good employees that know when they’re reaching their limits and can respectfully and responsibly decline things that would push them over the edge. When you agree to do something outside the scope of your job or perform extra work, make sure that the person you’re talking to understands that it’s outside the norm for you. If you tell them that this isn’t normally part of your role but you’re doing it to learn or that you’re helping someone out that asked you to come in for a cutover you’re setting the expectation that there is a purpose behind what you’re doing and not just that you agree to anything you’re told.

Second, you need to help people understand what is going on with what you’re doing. If an overworked colleague comes to you to ask you for help with something and you’re overworked too you’re not going to be able to provide them with much help or support. For those out there that think an outright refusal is a bad thing, like me present you with the following statement to clarify what’s going on:

What I need to make my answer “yes” is…

In essence, you’re telling the person that you want to agree to do what they’re asking but you need them to understand what’s going on beyond just agreeing. You’re not putting conditions on your answer so much as you’re telling them what you’re involved with and what needs to change in order to help them out. You’re informing them of the roadblocks that are keeping you from helping. That’s responsible in my book. While I’m sure there are people that will say it feels selfish to phrase answers like that you also have to see that you’re not saying “no” without providing context. You’re telling them you do want to help but that you need these other things to go a certain way too.

Third, you need to make sure you keep track of what happens after you agree. Does the job need to be done frequently and you always get asked to do it? Is it a one-time thing never to be seen or heard from again? Are you recognized for your effort? Even if it’s just a simple “thank you”? It sounds silly to keep track of things like this but it’s important because it provides data for you about how often you’re being pulled away to do other things. If this is a recurring task that your manager is asking you to do then it needs to be included in your job role. If it’s something that gets asked of you all the time and no one ever knows what you’re doing then you need to find out why.

Documenting your extra tasks will help you understand who is always coming to you for help and let you do something to reduce that. Do they need additional training? Are they being tasked with something that someone else should be handling? Do they just have a habit of asking you to help them with things because they’re overwhelmed too? Or, in a more negative light, are they making you do the work so they can take the credit? These are all questions that can only be answered when you have data. If you just have it in your head that you’re always helping a particular coworker or it feels like you’re always getting a phone call to run a particular report for someone you need to keep track of it so you can speak with confidence when it comes up.

Tom’s Take

There’s a lot of effort that goes into agreeing to do something for someone outside of what you normally do at work. It is true that you can’t say “no” to every request. However, you can agree in such a way as to help people understand what you’re working on and under what conditions you will be able to help. Again, I’m pretty sure there are those in the community that will tell me that I’m being prickly when I say that you need to put conditions on your agreement but you also have to see that saying yes to everything without taking your own situation into account is just as bad as saying no to things. Either you’re going to be seen as the person with no boundaries that will just do anything or you’re going to get so overwhelmed with work that you don’t get anything done and you end up in the same mess you’d be if you’d said no.

Bruce Schneier wrote an article on the dangers of cryptocurrencies and the uselessness of blockchain, including this gem:

From its inception, this technology has been a solution in search of a problem and has now latched onto concepts such as financial inclusion and data transparency to justify its existence, despite far better solutions to these issues already in use.

Please feel free to tell me how he’s just another individual full of misguided opinions… after all, what does he know about crypto?

This post originally appeared on the Packet Pushers’ Ignition site on April 22, 2020.   In this post I review what might happen to networking when we return to work. We won’t return to normal, but we will be back at work. To start, here are nine ideas about the pandemic’s impact, divided into two […]

The post Possible Impacts Of Covid-19 On Data Networking appeared first on Packet Pushers.

This post originally appeared on the Packet Pushers’ now-defunct Ignition site on October 1, 2019.   Insurance companies that offer cyberinsurance policies are looking at ways to reduce their risk (and improve profit margins) by discounting for companies that deploy reviewed and approved technologies. Company executives will make decisions about the cost and value of […]

The post Analysis: Will Your Security Infrastructure Be Determined By Your Cyberinsurance? appeared first on Packet Pushers.

This post originally appeared on the Packet Pushers’ Ignition site on January 14, 2020. There is a slow but steady trend for Governements’ to take back control of internet in their countries. For China the “great firewall” is now a rigid access control on content. Russia has been progressing changes to to be isolate itself […]

The post Reading: The Case for a Mostly Open Internet appeared first on Packet Pushers.

This lesson walks through the basics of reaching an application running in a Kubernetes pod. Instructor Michael Levan brings his background in system administration, software development, and DevOps to this series. He has Kubernetes experience as both a developer and infrastructure engineer. He’s also a consultant and Pluralsight author, and host of the “Kubernetes Unpacked” […]

The post Kubernetes For Network Engineers: Lesson 2 – Services, Nodeports, And Load Balancers – Video appeared first on Packet Pushers.

In lesson 3 of this course about Ansible for network automation, Josh VanDeraa covers the lab environment used in this course, reviews the Ansible Network Modules documentation page, and look at the parameters of an Ansible module to know what’s required and what the response will be. Josh has created a GitHub repo to store […]

The post Ansible For Network Automation Lesson 3: Ansible Modules Overview – Video appeared first on Packet Pushers.

In this installment of the series on Ansible and network automation, Josh VanDeraa looks at how to update an Ansible config file, gather data from various devices using command modules including IOS, and use ios_facts to get IOS-specific information from IOS devices. Josh has created a GitHub repo to store additional material, including links and […]

The post Ansible For Network Automation Lesson 4: Gathering Device Information – Video appeared first on Packet Pushers.

Béla Várkonyi left a great comment on a blog post discussing (among other things) whether we need large buffers on spine switches. I don’t know how many people read the comments; this one is too valuable to be lost somewhere below the fold

You might want to add another consideration. If you have a lot of traffic aggregation even when the ingress and egress port are roughly at the same speed or when the egress port has more capacity, you could still have congestion. Then you have two strategies, buffer and suffer jitter and delay, or drop and hope that the upper layers will detect it and reduce the sending by shaping.

This post originally appeared on the Packet Pushers’ Ignition site on January 9, 2020.   This slide from the Cisco Live BRKOPT-2006 presentation on “Preparing for 400 GbE” jumped out at me. I recommend you download the whole presentation and keep it for future reference. It’s an excellent resource with lots of useful information. Optics […]

The post Optics Are More Important Than Your Switches At 400G appeared first on Packet Pushers.

I stumbled upon an interesting article in one of my RSS feeds: should we build smart highways or smart cars?

The article eloquently explains how ridiculous and expensive it would be to put the smarts in the infrastructure, and why most everyone is focused on building smart cars. The same concepts should be applied to networking, but of course the networking vendors furiously disagree – the network should be as complex, irreplaceable, and expensive as possible. I collected a few examples seven years ago, and nothing changed in the meantime.

This post is overdue. Perhaps by a few years. Finally, earlier this week, I saw a few posts on Reddit that made me thumb through stacks of papers to find my initial draft. What comes here, at its finest, is merely personal experience. I would call the lesson “established rules” if I had enough scientific […]

The post Six Coaching Principles That Took Me Years to Learn appeared first on Packet Pushers.

Cisco Live 2022 Attendees by the big sign

Cisco Live was last week and it was an event full of both relief and worry. Having not seen any of my friends and colleagues during the Geek Summer Camp for since 2019 I was excitedly anticipating how things would go this year. While I was thrilled to see everyone in real life again there were also challenges that presented themselves by the end of the event that we need to discuss as well.

I could spend volumes detailing every little thing that went on but no one really wants to read that kind of discussion. I’ll just summarize some the stuff that I liked, some of it that I didn’t, and some bigger things that everyone needs to think about.

What Worked for Me

I was happy to once more be a part of the CCIE Advisory Council. We have been meeting via Webex for the entire pandemic but there’s just something about being in a room together that fosters conversation and sharing. The ideas that we discussed are going to have a positive impact on the program as we look at what the future of certifications will be. There’s a lot more to this topic than I can cover in just a quick summary paragraph.

I was a bit confused about the Social Media Hub hours on Sunday, so I resurrected my original tweet about meeting people right outside registration:

I had lots of people stop by that morning and say hello. It warmed my heart to see everyone before the conference even started. Thankfully, the Cisco Live social team came out to tell me that you could get to the Social Media Hub even though the show floor wasn’t open yet. I went in and grabbed a comfy chair to await the opening tweetup.

The tweetup itself was a good one. Lots of new faces means lots of people that are getting introduced to the social side of Cisco. That means the community is going to continue to grow and prosper. One point of weirdness for me was when people would introduce me to their friends and such by pointing at the Social Media Hub and saying, “Tom is the reason we have all this.” While that’s technically true it still makes me feel weird because the community it was keeps driving Cisco Live forward. No one person defines it for everyone else.

I enjoyed the layout of the World of Solutions this year because I wasn’t packed in with everyone else elbowing my way through crowded alleys trying to visit a booth. It felt like Cisco put some thought into having ample space for people to spread out instead of trying to maximize space usage. I know that this is partially a result of the COVID pandemic (which we’ll cover more of in a bit) but I wouldn’t be sad to see this layout stick around for a few more years. Less crowded means better conversations.

The keynote was fun for me, mostly because of where I enjoyed watching it. We put together a watch party for the Tech Field Day Extra delegates and it was more fun than I realized. We were able to react live to the presentation without fear of making a calamitous noise in the arena. I had forgotten how much fun the MST3K style of keynote commentary could be.

Lastly, the social media team knocked it out of the park. They were on top of the tweets and answering questions throughout the event. I have some issues with the social media stuff in general but the team did a top notch job. They were funny and enjoyed bantering back and forth with everyone. Social media is hard and doing it as a job is even harder. I just hope we didn’t scar anyone with our tweets.

What I Was Concerned About

Not everything is perfect at events. As someone that runs them for a living I can tell you little things go wrong all the time and need to be addressed. Here are some of the things that happened that made me take a few notes.

The communication across the whole event felt a bit rushed. Like certain things were announced at the last minute or were only announced in certain places. Nailing down the best way to share information is always difficult but when in doubt you need to share it everywhere. If you have access to social media, email, digital signage, and other avenues use them all. It’s better to overshare and remove doubt than undershare and end up fielding questions anyway.

There was some grumbling about the way that some of the social media aspects were handled this year. I think that sentence gets typed every year. Some of it comes down to the focus that stakeholders want to put on certain aspects of the event. If they want more video content that’s going to favor folks that are comfortable recording videos. If they want more long-form written items that naturally prioritizes those that are good at writing. No one is ever going to find the perfect mix but, again, communication is key. If we know what you want to see we can help make more of it.

The other thing that annoys me a bit, specifically about Las Vegas, is the land rush of sponsored parties. On Monday evening I was walking back to the Luxor to my room to drop my backpack and more than half the restaurants and bars I walked past all had banners out front and signs stating they were closed for a special event or booked until a certain time. While I appreciate that the sponsors of the event are willing to go out of their way to spend money and entice attendees to go to their party and hear about how awesome their products are it also creates an artificial crunch for other things. If half the bars are closed then the other half have to pick up the remainder of the hungry people. That means that a half-full exclusive party causes a two-hour wait at a restaurant next door. While this is nothing new in the conference community the lack of other options at the south end of the Las Vegas strip means you’re pretty much stuck taking a taxi to another hotel if you don’t want to wait to have a burger or pizza. In full transparency one of those parties on Monday was one that I attended for the Cisco Champions program but there were also two other parties booked in Ri Ra that night concurrently.

What We Should All Be Asking

Now it’s time for the elephant in the convention center. The reason why we haven’t had an in-person Cisco Live in three years is COVID. We were locked down during the pandemic and conference organizers erred on the side of caution in 2021. 2022 was a hopeful year and many conferences were back to being live events. RSA happened in San Francisco the week before Cisco Live. There were thousands of people there and a reported 16,000 people at Cisco Live.

The reports coming out of Cisco Live were that a lot of people tested positive for COVID after returning home. Cisco had a strict policy of requiring proof of vaccination to attend. Yet people were testing positive as early as Sunday before the conference even started. The cases started rising throughout the week and by the time folks got home on Thursday evening or Friday my Twitter feed was full of friends and colleagues that came back with the extra strength conference crud.

Thankfully no one has been seriously affected as of this writing. Most everyone that I spoke with has said they feel like they have a cold and are tired but are powering through and should be clear to leave quarantine at home by today. I, amazingly, managed to avoid getting infected. I tested every day and each time it came back clear. I’m not actually sure how I managed to do that, as I wasn’t wearing a mask like I really should have been and I was around people for most of the day. I could attribute it to luck but the logical side of my brain says it’s more likely that I caught it sometime in May and didn’t realize it so my body had the latest antibody patch to keep me from coming down with it.

Between RSA and Cisco Live there are a lot of people asking questions about how in-person conferences of size are going to happen in the future with COVID being a concern. RSA was tagged as a “super spreader” event. Cisco Live is on the verge of being one as well. There are lots of questions that need to be asked. Can a conference ensure the safety of the attendees? Are there measures that should be mandatory instead of encouraged? What value do we get from face-to-face interaction? And will the next event see fewer people now that we know what happens when we get a lot of them in one place?

Tom’s Take

I could go on and on about Cisco Live but the important thing is that it happened. No last minute cancelations. No massive outbreaks leading to serious health problems. We all went and enjoyed the event, even if the result was coming home to quarantine. I went fully expecting to get infected and I didn’t. Maybe I should have done it a little differently but I think a lot of people are saying the same thing now. I hope that Cisco and other companies are encouraged by the results and continue to have in-person events going forward. Not everyone is going to attend for a variety of reasons. But having the option to go means building back the community that has kept us going strong through difficult times. And that’s a reason to see a silver lining.

Would you like to stand out from your peers? Would you like to impress the people you work for, or perhaps the people you’d like to work for? Put in the work. Putting in the work to achieve a goal is a form of self-sacrifice. To get the thing you want, you need to give up something else.

The post Put In The Work appeared first on Packet Pushers.

We're hosting the "Real World Enterprise Automation" live stream with sponsor Gluware on June 28, 2022. Gluware is a network automation vendor that's especially good at taking your existing, multi-vendor network and adding automation to it. We'd like it if you'd register to attend this hour-or-so event in real-time via https://packetpushers.net/live. Thanks!

The post Join The Packet Pushers For A Live Stream With Gluware June 28, 2022 appeared first on Packet Pushers.

This post originally appeared in the Packet Pushers’ Ignition site on March 10, 2020. When getting data back from API queries in Python, the data is often delivered in JSON format. Python libraries such as requests will convert that JSON data structure into a Python-native data structure you can work with. That Python data structure […]

The post How To Reference Nested Python Lists & Dictionaries appeared first on Packet Pushers.

One of the last things I did before starting the 2022 summer break was to push out the next release of netsim-tools.

It includes support for routed VLAN subinterfaces (needed to implement router-on-a-stick) and routed VLANs (needed to implement multi-hop VRF lite), completing the lengthy (and painful) development of the VLAN configuration module. Stefano Sasso added VLAN support for Mikrotik RouterOS and VyOS, and Jeroen van Bemmel completed VLAN implementation for Nokia SR Linux. Want to see VLANs on other platforms? Read the contributor guidelines and VLAN developer docs, and submit a PR.

I’ll be back in September with more blog posts, webinars, and cool netsim-tools features. In the meantime, automate everything, get away from work, turn off the Internet, and enjoy a few days in your favorite spot with your loved ones!

This post originally appeared on the Packet Pushers Ignition site on December 10, 2019.   DNS is sometimes used to optimize traffic between client and server. That is, a client needs to connect to a server. Resolving the IP address of the server’s hostname is the first thing the client must do before making the […]

The post Embedding Client IP In DNS Requests: EDNS Client Subnet (ECS) appeared first on Packet Pushers.

This post originally appeared on the Packet Pushers’ Ignition site on June 10, 2020. Introduction In many automation scripts, you’ll be retrieving information via some sort of interface and then doing something with the data. The interface is often an API–application programmatic interface. For folks new to APIs, they might seem daunting, but they need […]

The post Your First REST API Call In Python appeared first on Packet Pushers.

The layer-2 forwarding and flooding in an MLAG cluster are intricate but still reasonably easy to understand. Layer-3 gets more interesting; its quirks depend heavily on layer-2 implementation. While most MLAG implementations exhibit similar bridging behavior, expect interesting differences in routing behavior.

We’ll have to expand by-now familiar network topology to cover layer-3 edge cases. We’ll still work with two switches in an MLAG cluster, but we’ll have an external router attached to both of them. The hosts connected to the switches belong to two subnets (red and blue).

I really do like Microsoft’s Visual Studio Code for editing code, so much so that I can forgive it for being an electron app. However when I code in go, the way the go’s syntax validation works means that each app folder needs to be opened in its own Visual Studio Code window – and as somebody supremely lazy I find this to be an irritating thing to have to do.

Opening a Folder in a New Window

It’s not actually that big of a deal, but having to execute File->New Window, then File->Open Folder…, then browsing to the folder I want to open often feels clunky and superfluous when half the time I’ve already browsed to that folder in the shell. So here’s the dumb shortcut which makes my life easy on MacOS:

/usr/local/bin/vsc:
#!/bin/zsh
# 
"/Applications/Visual Studio Code.app/Contents/Resources/app/bin/code" --new-window "`pwd`"

So now if I’m in a folder I can just enter the command vsc and a new Visual Studio Code window opens focused on my current directory.

Stupidly simple, yes, yet I use it multiple times a day and I’m remarkably happy about it. It takes all sorts, I guess.

If you liked this post, please do click through to the source at CLI Shortcut for Visual Studio Code on MacOS and give me a share/like. Thank you!

Almost exactly a decade ago I wrote that VXLAN isn’t a data center interconnect technology. That’s still true, but you can make it a bit better with EVPN – at the very minimum you’ll get an ARP proxy and anycast gateway. Even this combo does not address the other requirements I listed a decade ago, but maybe I’m too demanding and good enough works well enough.

However, there is one other bit that was missing from most VXLAN implementations: LAN-to-WAN VXLAN-to-VXLAN bridging. Sounds weird? Supposedly a picture is worth a thousand words, so here we go.

There are (at least) two steps to get new functionality (like VLANs) implemented in netsim-tools:

• We have to develop a data transformation module that takes high-level lab-, node-, link- or interface attributes and transforms them into device data.
• Someone has to create Jinja2 templates for each supported device that transform per-device netsim-tools data into device configurations.

I usually implement new features on Cisco IOSv and Arista EOS¹, Stefano Sasso adds support for VyOS, Dell OS10, and Mikrotik RouterOS, and Jeroen van Bemmel adds Nokia SR Linux and/or SR OS support. That’s less than half of the platforms supported by netsim-tools, and anything you could do to help us increase the coverage would be highly appreciated.

In the previous blog post of the MLAG Technology Deep Dive series, we explored the intricacies of layer-2 unicast forwarding. Now let’s focus on layer-2 BUM¹ flooding functionality of an MLAG system.

Our network topology will have two switches and five hosts, some connected to a single switch. That’s not a good idea in an MLAG environment, but even if you have a picture-perfect design with everything redundantly connected, you will have to deal with it after a single link failure.

ED, HIS TLS COURSE, AND THE FREE OPENSSL CHEATSHEET Twitter @ed_pracnet https://practicalnetworking.net Practical TLS course: https://pracnet.net/tls OpenSSL Cheatsheet: https://pracnet.net/openssl FILES FOR THE CERT/KEY MATCHING EXERCISE: ZIP VERSION: packetpushers-pracnet-openssl.zip https://ln5.sync.com/dl/1f1f63d90/kqztwkp9-hkcz3yvq-tuzx79ke-aewxgaip TAR.GZ VERSION: packetpushers-pracnet-openssl.tar.gz https://ln5.sync.com/dl/0791b8d50/q973jpyb-qrmz3cpd-xeiar9zn-qu99gi5w FOR MORE INFO Hashing, Hashing Algorithms, and Collisions – Cryptography Symmetric Encryption vs Asymmetric Encryption Public & Private Keys – Signatures & […]

The post Using OpenSSL With Ed Harmoush 6/6 Troubleshooting: Client Side Certificate Issues – Video appeared first on Packet Pushers.

In a recent blog post, Donal O Duibhir claims IPv6 is faster than IPv4… 39% of the time, which at a quick glance makes as much sense as “60% of the time it works every time”. The real reason for his claim is that there was no difference between IPv4 and IPv6 in ~30% of the measurements.

Unfortunately he measured only the Wi-Fi part of the connection (until the first-hop gateway); I hope he’ll keep going and measure response times from well-connected dual-stack sites like Google’s public DNS servers.

One of the things that I spend a lot of my time doing it teaching and training. Not the deeply technical stuff like any one of training programs out there or even the legion of folks that are doing entry-level education on sites like Youtube. Instead, I spend a lot of my time bringing new technologies to the fore and discussing how they impact everyone. I also spend a lot of time with youth and teaching them skills.

One of the things that I’ve learned over the years is that it’s important to not only learn something but to reinforce it as well. How much we practice is just as important as how we learn. We’re all a little guilty of doing things just enough to be proficient without truly mastering a skill.

Hours of Fun

You may have heard of the rule proposed by Malcolm Gladwell that it takes 10,000 hours to become an expert at something. There’s been a lot of research debunking this “rule of thumb”. In fact it turns out that the way you practice and your predisposition to how you learn has a lot do to with the process as well.

When I’m teaching youth, I see them start a new skill and keep going until they get their first success. It could be tying a knot or setting up a tent or some other basic skill. Usually, with whatever it is, they get it right and then decide they are proficient in the skill. And that’s the end of it until they need to be tested on it or something forces them to use it later.

For me, the proficiency aspect of basic skills is maddening. We teach people to do things like tying knots or programming switch ports but we don’t encourage them to keep practicing. We accept that proficiency is enough. Worse yet, we hope that the way they will gain expertise is by repetition of the skill. We don’t set the expectation of continued practice.

That’s where the offhanded Gladwell comment above really comes from. The length of time may have been completely arbitrary but the reality is that you can’t really master something until you’ve done it enough that the skill becomes second nature. Imagine someone riding a bicycle for the first time. If they stopped when they were able to pedal the bike they’d never be able to ride it well enough to maneuver in traffic.

Likewise, we can’t rely on simple proficiency for other tasks either. If we just accept that an operations person just learns VLAN configuration once and then we hope they’ll know it well enough that they can do it again later we’re going to either be frustrated when they have to keep looking up the commands for the task or, worse yet, when they bring down the network because they didn’t remember that you needed to use the add keyword on a trunk port and they wipe out a chunk of the network core.

Right vs. Wrong

For all those reasons above I ask my students to take things a little further. Rather than just doing something until you have an initial success I ask them to practice until they have it ingrained into their motor pathways. Put more simply:

Don’t practice until you get it right. Practice until you can’t get it wrong.

The shift in thinking helps people understand the importance of repeated practice. Getting it right is one thing. Understanding all the possible ways something can be done or every conceivable situation is something entirely different. Sure, you can configure a VLAN. Can you do it on every switch? Do you know what order the commands need to be done in? What happens if you switch them? Do you know what happens when you enable two contradictory features?

Obviously there are things you’re not going to need to practice this much all the time. One of my favorites is the people in CCIE study groups that spend way more time working on things like BGP leak maps or the various ways that one could configure QOS on a frame relay circuit. Are these important things to know? Yes. Are they more important to know than basic layer 2/3 protocols or the interactions of OSPF and BGP when redistributing? No.

Tom’s Take

When I was younger, I watched the Real Ghostbusters cartoon. One of the episodes featured Winston asking Egon if he could read Summerian. His response? “In my sleep, underwater, and in the dark. Of course I can read Summerian.”

Practice the basics until you understand them. Don’t miss a beat and make sure you have what you need. But don’t stop there. Keep going until you can’t possibly forget how to do something. That’s how you know you’ve mastered it. In your sleep, underwater, and in dark. Practice until you can’t get it wrong.

This post originally appeared in the Human Infrastructure newsletter, a free weekly publication from the Packet Pushers. See back issues and sign up at packetpushers.net/newsletter. As months of work-from-home policies became years, I noticed a pattern in some coworkers and friends (and myself): The longer folks worked from their domestic silos, the more mistrust and […]

The post Lost Connections In The Connected Workplace appeared first on Packet Pushers.

Last week’s IPv6 security video introduced the rogue IPv6 RA challenges and the usual countermeasure – RA guard. Unfortunately, IPv6 tends to be a wonderfully extensible protocol, creating all sorts of opportunities for nefarious actors and security researchers.

For years, the networking vendors were furiously trying to plug the holes created by the academically minded IPv6 designers in love with fragmented extension headers. In the meantime, security researches had absolutely no problem finding yet another weird combination of IPv6 headers that would bypass any IPv6 RA guard implementation until IETF gave up and admitted one cannot have “infinitely extensible” and “secure” in the same sentence.

For more details watch the video by Christopher Werny describing how one could use IPv6 extension headers to circumvent IPv6 RA guard

ED, HIS TLS COURSE, AND THE FREE OPENSSL CHEATSHEET Twitter @ed_pracnet https://practicalnetworking.net Practical TLS course: https://pracnet.net/tls OpenSSL Cheatsheet: https://pracnet.net/openssl FILES FOR THE CERT/KEY MATCHING EXERCISE: ZIP VERSION: packetpushers-pracnet-openssl.zip https://ln5.sync.com/dl/1f1f63d90/kqztwkp9-hkcz3yvq-tuzx79ke-aewxgaip TAR.GZ VERSION: packetpushers-pracnet-openssl.tar.gz https://ln5.sync.com/dl/0791b8d50/q973jpyb-qrmz3cpd-xeiar9zn-qu99gi5w FOR MORE INFO Hashing, Hashing Algorithms, and Collisions – Cryptography Symmetric Encryption vs Asymmetric Encryption Public & Private Keys – Signatures & […]

The post Using OpenSSL With Ed Harmoush 5/6 Inspecting Certificates: Invalid Certificates – Video appeared first on Packet Pushers.

Cisco Live 2022 in Las Vegas kicked off with executive keynotes, including an address from CEO Chuck Robbins. My takeaways from the keynotes from Tuesday, June 14th are: Cisco knows it has to work harder to keep customers Cisco has big cloud ambitions Meraki is one key to Cisco’s cloud & simplicity goals Cisco Has […]

The post Cisco Live 2022: A Kinder, Gentler, Cloudier Monster? appeared first on Packet Pushers.

A few weeks ago I wrote about tradeoffs vendors have to make when designing data center switching ASICs, followed by another blog post discussing how to select the ASICs for various roles in data center fabrics.

You REALLY SHOULD read the two blog posts before moving on; here’s the buffer-related TL&DR for those of you ignoring my advice ;)

ED, HIS TLS COURSE, AND THE FREE OPENSSL CHEATSHEET Twitter @ed_pracnet https://practicalnetworking.net Practical TLS course: https://pracnet.net/tls OpenSSL Cheatsheet: https://pracnet.net/openssl FILES FOR THE CERT/KEY MATCHING EXERCISE: ZIP VERSION: packetpushers-pracnet-openssl.zip https://ln5.sync.com/dl/1f1f63d90/kqztwkp9-hkcz3yvq-tuzx79ke-aewxgaip TAR.GZ VERSION: packetpushers-pracnet-openssl.tar.gz https://ln5.sync.com/dl/0791b8d50/q973jpyb-qrmz3cpd-xeiar9zn-qu99gi5w FOR MORE INFO Hashing, Hashing Algorithms, and Collisions – Cryptography Symmetric Encryption vs Asymmetric Encryption Public & Private Keys – Signatures & […]

The post Using OpenSSL With Ed Harmoush 4/6 Inspecting Certificates: Valid Certificates – Video appeared first on Packet Pushers.

The early October 2021 Facebook outage generated a predictable phenomenon – couch epidemiologists became experts in little-known Bridging the Gap Protocol (BGP), including its Introvert and Extrovert variants. Unfortunately, I also witnessed several unexpected trips to Mount Stupid by people who should have known better.

To set the record straight: everyone’s been there, and the more vocal you tend to be on social media (including mailing lists), the more probable it is that you’ll take a wrong turn and end there. What matters is how gracefully you descend and what you’ve learned on the way back.