In previous blog posts in this series we discussed whether it makes sense to invest into fast failover network designs, the topologies you can use in such designs, and the fault detection techniques. I also hinted at different fast failover implementations; this blog post focuses on some of them.

Hardware-based failover changes the hardware forwarding tables after a hardware-detectable link failure, most likely loss-of-light or transceiver-reported link fault. Forwarding hardware cannot do extensive calculations; the alternate paths are thus usually pre-programmed (more details below).

A while ago (eons before AWS introduced Gateway Load Balancer) I discussed the intricacies of AWS and Azure networking with a very smart engineer working for a security appliance vendor, and he said something along the lines of “it shows these things were designed by software developers – they have no idea how networks should work.”

In reality, at least some aspects of public cloud networking come closer to the original ideas of how IP and data-link layers should fit together than today’s flat earth theories, so he probably wanted to say “they make it so hard for me to insert my virtual appliance into their network.”

Tom Hollingsworth wrote another must-read blog post in which he explained what one should do before asking for help:

If someone comes to me and says, “I tried this and it failed and I got this message. I looked it up and the response didn’t make sense. Can you tell me why that is?” I rejoice. That person has done the legwork and narrowed the question down to the key piece they need to know.

In other words (again his), do your homework first and then ask relevant questions.

<figure class="wp-block-image size-large"></figure>

First things first: Go watch this great video on lock-in from Ethan Banks (@ECBanks). We’ll reference it.

<figure class="wp-block-embed is-type-rich is-provider-youtube wp-block-embed-youtube wp-embed-aspect-16-9 wp-has-aspect-ratio"></figure>

Welcome back. Still carrying that pitchfork around screaming about how you want to avoid vendor lock-in? Ready to build the most perfect automation system in history that does multi-cloud, multi-vendor, multi-protocol networking in a seamless manner with full documentation? Nice. How hard was is to build that unicorn farm?

I get it. No one wants to be beholden to a specific vendor. No one likes being forced into buying things. Everyone hates the life of the engineer forced to work on something they don’t like or had to use because someone needed a new boat. Or do they?

Ford and Chevys and Dodge, Oh My!

What kind of car do you drive? Odds are good you’re either ready to get a new one or you’re proud of what you’re driving. I find that the more flashy a car is the more likely people are to talk about how amazing it is. And when there are two dominant manufacturers in a market for cars, you tend to see people dividing into camps to sing the praises of their favorite brands. Ford people love their trucks and won’t hesitate to decorate their bumpers with stickers about the uselessness of a Chevy pickup. Chevy owners will remind you that Ford is an acronym for Found On (the) Road Dead. Ferrari versus Lamborghini. Toyota versus Honda. Tesla versus everyone else. Tell me that car people don’t root for their team.

That’s how it’s always been. However, when you buy a car you are locked in. You have to buy the parts for that car to fix it. Ford starters don’t work in Chevy vehicles. You can’t just pull a motor out of Corvette and drop it into a Mustang. Wanna try to put Lambo tires on your Testarossa? Good luck! You’re locked into a system that has parts for your car. There’s even a specific term for the parts division of Chrysler, which you use when you tell people you drive a MOPAR car.

Why is it that no one cares about lock in when they buy their car? How is it that when making choices between Cisco and Juniper or AWS and Azure that we rail against the need to pick a horse and run with it? How is it that people in IT will go to amazing lengths to over-engineer something to use the most obscure open source routing protocols invented for the sake of making their configs portable only to walk into the parking lot and crawl into a vehicle that has parts that can only be found at the dealer with a 1000% markup on price? How does that compute?

I Take It Back

IT pros see lock-in as a by-product of choices that were made without their input. No one complains about lock-in when they were the ones that got to make the call about which gear to install or which cloud to pick. Lock-in usually becomes a sticking point when the IT contributes were cut out of the decision loop or they didn’t get to voice their opinion for their favorite hobby project on GitHub. The disappointment festers into a feeling that the real problem here is that the evil vendor is just trying to keep us from moving to the solution path that I would have suggested if only they had asked me!

Why do we build networks using standard protocols? Is it so we can rip out huge sections of the network every three years when the incumbent vendor has pissed us off for the last time? Or is it because we want the opportunity to plug in a cheaper device when one fails? Why do we build multi-cloud capable networks? Is it because we hate Bezos or Nadella and we want to stick it to them by moving our workloads whenever we feel like they’ve made a poor strategic decision? Or is it really because some workloads work better in some places and we are trying to keep the rest mobile so we can move them to take advantage of cheaper spot prices like a game of instance whack-a-mole?

Lock-in isn’t a huge problem. It’s the boogeyman we use to cover our real problems: Not feeling heard and valued. We fight back against this by creating more work for ourselves. Instead of paying for the solution with money, we create a solution with an investment of complexity and time spent creating it. You wanna save $10,000 by switching out the gear I suggested for this other model? Fine, I’m going to make it completely open and hard for anyone other than me to use!

Ask yourself honestly: When was the last time you had to completely change your entire setup to a new system or new hardware in less than three months? Pandemic craziness aside, most IT departments can’t even figure out which printers to buy in three months, let alone scrap an entire network or cloud deployment for the competitor. And that’s the technical challenge. Let’s say you’ve used OSPF and open standards and avoided anything proprietary because you’re ready to pull the plug the next time that sales drone comes sniffing for a new motorcycle payment. How is your non-locked-in network going to compete with the power of spiffs? Sure, we could rip this whole $VendorA network out right now and replace it with $VendorB and there’s nothing you can do about it! Until Sales Drone mentions they’ll give you 20% off the next license renewal and throw in four new top-of-the-line switches to “test”. All you hard work sunk because Sales Drone and Executive Team speak the same language: money.

I know this sounds dark and ominous. I realize there are some very valid concerns about vendor lock in, like licensing features behind paywalls that are unreasonable or creating dependence on specific features that can be revoked at any time. But that’s not usually where the lock-in discussions go for IT pros. No, they usually go back to “$VendorA made me mad once and I will never use $ProtocolA again just to spite them!” Lock-in discussions are almost always really about the staff not getting exactly what they want and using their skillsets to create complexity as a panacea for what they perceive as the chance to move away when the executives want to listen to them again. What generally follows is a network that is difficult to maintain and doesn’t hit performance metrics. That means the executives’ decisions are punished. Not through sabotage. Not through malice. But through the decisions by their staff to try and create a system that make things portable when they don’t need to be just in case someone changes their mind sometime in the future.

---

Tom’s Take

I expect the comments section to light up on this one. Yes, lock-in is a thing. Yes, there are some very specific cases where it’s a Bad Thing (TM). I’m just pointing out that, like the car discussion above, most of the time the average person couldn’t care less about lock-in as long as it was their decision. The same people that will put a sticker of Calvin peeing on a Ford logo on their car chafe at the idea of having to use Cisco’s flavor of OSPF because one area they will never configure isn’t 100% standard. Lock-in is an issue. It’s not the world-ending problem we make it out to be. And it’s certainly not the boogeyman that scares us into making things needlessly complicated to the point of absurdity just to prove a point.

In the introductory fast failover blog post I mentioned the challenge of fast link- and node failure detection, and how it makes little sense to waste your efforts on fast failover tricks if the routing protocol convergence time has the same order of magnitude as failure detection time.

Now let’s focus on realistic failure detection mechanisms and detection times. Imagine a system connecting a hardware switching platform (example: data center switch or a high-end router) with a software switching platform (midrange router):

Behold these three different sets of free networking icons for your glorious diagrams! There's something here for you whether you're seeking vector graphics, JPG, PowerPoint, or Visio. And from all of us, thank you for documenting.

The post Free Networking Icons For Diagrams appeared first on Packet Pushers.

After explaining why you should focus on defining the problem before searching for a magic technology that will solve it, I continued the Focus on Business Challenges First presentation with another set of seemingly simple questions:

• Who are your users/customers?
• What do they really need?
• Assuming you’re a service provider, what are you able to sell to your customers… and how are you different from your competitors?

In the blog post introducing fast failover challenge I mentioned several typical topologies used in fast failover designs. It’s time to explore them.

The Basics

Fast failover is (by definition) adjustment to a change in network topology that happens before a routing protocol wakes up and deals with the change. It can therefore use only locally available information, and cannot involve changes in upstream devices. The node adjacent to the failed link has to deal with the failure on its own without involving anyone else.

There are actually quite a few resources out there for a novice programmer to learn about data types like strings, integers, floats, and more. The wikipedia page, as an example, covers a broad spectrum of potential meanings. Just about any book or tutorial focused on a particular programming language will start off by listing the types supported by that language. This makes sense, since they are the fundamental building block of being able to do pretty much anything in that language.

Is vendor lock-in all that bad? Many argue yes. You’re tied to a vendor because you’ve used some of their proprietary technology, and so you’re (apparently) stuck with it forever, limiting your future business agility. I think that’s an incomplete argument, though.

<iframe allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen="allowfullscreen" frameborder="0" height="281" src="https://www.youtube.com/embed/mu2dQCZTYkM?feature=oembed" title="Vendor Lock-In. Maybe Not So Evil." width="500"></iframe>

 

A Network Artist sent me a long list of OSPF-related questions after watching the Routing Protocols section of our How Networks Really Work webinar. Starting with an easy one:

From historical perspective, any idea why OSPF guys invented their own transport protocol instead of just relying upon TCP?

I wasn’t there when OSPF was designed, but I have a few possible explanations. Let’s start with the what functionality should the transport protocol provide reasons:

Shadow IT is a persistent problem. End users, lines of business, and developers have easy access to a host of cloud applications and services they can use at will, even if a set of IT-approved applications or services already exists. The use of unauthorized services can create rifts within an organization. In this excerpt from […]

The post Can Shadow IT Be Stopped? – Video appeared first on Packet Pushers.

Last week we enjoyed the second half of Graph Algorithms lecture by Rachel Traylor, this time focusing on flow- and connectivity challenges.

After an easy start defining flows and walking us through various maximum flow algorithms, Rachel explained circulations and saturating flows, switched into high gear with (supposedly painless) intro to linear programming and minimum cost flow problems, and concluded with dynamic flows and using flows to explore graph connectivity.

You’ll need Standard or Expert ipSpace.net subscription to watch the videos.

From AI is wrestling with a replication crisis (HT: Drew Conry-Murray)

Last month Nature published a damning response written by 31 scientists to a study from Google Health that had appeared in the journal earlier this year. Google was describing successful trials of an AI that looked for signs of breast cancer in medical images. But according to its critics, the Google team provided so little information about its code and how it was tested that the study amounted to nothing more than a promotion of proprietary tech (emphasis mine).

No surprise there, we’ve seen it before (not to mention the “look how awesome we are, but we can’t tell you the details” Jupiter Rising article).

<figure class="wp-block-image size-large"></figure>

With the insanity of the pandemic and the knowledge drain that we’re seeing across IT in general, there’s never been a more important time than right now to help out those that are getting started on this rise. The calls for mentors across the community is heartwarming. I’ve been excited personally to see many recognizable names and faces in the Security, Networking, and Wireless communities reaching out to let people know they are available to mentor others or connect them with potential mentors. It’s a way to give back and provide servant leadership to those that need it.

If you’re someone that’s reading this blog right now and looking for a mentor you’re in luck. There are dozens of people out there that are willing to help you out. The kindness of the community is without bounds and there are those that know what it was like to wander through the wilderness for a while before getting on the right track. They are the ones that will be of the most help to you. However, before you slide into someone’s DMs looking for help, you need to keep a few things in mind.

Make Me One With Everything

The single most important step you can take to increase your chances of being mentored or being set up with someone to help you out is simple in theory but hard in practice:

You NEED to do your homework.

Sound contrite, right? You don’t know what you don’t know. You need to figure out what you have to have, right? Why not ask someone that has been there and have them tell you everything?

Let me give you the perspective of someone who mentors and teaches in all aspects of my life. The scouts, professionals, and students that come to me and say, “Tell me everything I need to know” are usually the ones that listen the least and forget the most. They are the people that haven’t done their homework. They haven’t looked up what interests them or tried to figure out what knowledge they’re missing. They want answers but don’t have questions. Without questions, answers are meaningless.

Moreover, telling someone “everything” is a recipe for disaster. How does a mentor know what to focus on? What areas interest you? In security, are you offensive or defensive? Do you enjoy writing reports or using tools? Do you want to be a per-work consultant or have a steady, if not smaller, paycheck from a single organization? How can a mentor know where to point you if you haven’t done this basic homework?

Let me give you an example that happened to me in the last week. I got a DM from someone I’ve never talked to before. They politely asked if I could answer a couple of questions for them. I said sure with some hesitation. Usually this means they’re looking for some very broad advice or they need help with their homework. When the questions appeared in my inbox, I asked for some clarification. In this instance, it was someone that needed to understand queuing mechanisms. Once I determined I wasn’t doing someone’s CS homework for them, I read up on the topic and explained what I thought was the case. I was pleasantly surprised to get a response that they had read the same paper and it sounded right but they wanted to understand deeper. We talked for a bit and I feel like the person walked away from the exchange with a greater understanding.

What made me happy in this situation is that the person did the work ahead of time instead of just saying, “teach me how this works”. They wanted to understand, not just get the answer to a multiple choice question. They were curious and wanted to learn the right way. These are the kind of people that benefit from mentors. They are self-motivated and willing to do the work to get ahead.

Help Is Always Given To Those Who Ask

You may have heard the phrase, “Help will come to those that help themselves”. It’s another bit of cliche that means you need to be as active in the process as the person you are seeking knowledge from. If you just show up and say, “I need to know everything starting from scratch”, you’re sending the message that you aren’t invested. Mentors don’t want to help those that aren’t invested.

On the other hand, if someone comes to me and says, “I tried this and it failed and I got this message. I looked it up and the response didn’t make sense. Can you tell me why that is?” I rejoice. That person has done the legwork and narrowed the question down to the key piece they need to know. They don’t need to “boil the ocean” so to speak. They have a specific need that can be met.

Mentors are people too. Maybe they enjoy teaching and guiding more than others but they have limits on their energy just like you would. If a mentor spends more time exerting themselves trying to teach someone everything starting from zero, they’re going to burn out. However, teaching someone that just needs a little extra push to get over the hump of a hard problem is a much better use of everyone’s time. The mentor gets the reward of seeing their student understand and the mentee gets the satisfaction of getting it right and doing the work before they ask for help.

Asking someone for help is never easy. It’s an admission that you don’t have all the answers and you need to rely on others. In a profession where being smart and knowing everything is seen as a sign of success it can be humbling to admit you need something from someone. However, I find that those that need the least amount of help from having exhausted their capabilities are usually the ones that learn the most over time and rely on their peers and mentors the least. They know what to do and where to start. They just need a helping hand to get over the line.

---

Tom’s Take

I am always willing to be a mentor for anyone that needs help. I can help you understand protocols, tie tripod lashings, and teach you more than you ever wanted to know about building space probes or speaking in public. That’s the life I’ve chosen for myself. However, I ask that all those that seek my mentoring help also commit to learning. Do the extra work ahead of time. Narrow your focus to what is essential to get over the hump. Realize that the more you do for yourself the more meaningful it is for you. And remember that those that mentor you are also on the learning journey themselves. Just as they help you, so too do others help them. And one day you will find yourself in the position to mentor others. Showing the investment and determination to go the extra mile for yourself is the example that you will set for those that come later.

After (hopefully) agreeing on what routing, bridging, and switching are, let’s focus on the first important topic in this area: how do we get a packet across the network? Yet again, there are three fundamentally different technologies:

• Source node knows the full path (source routing)
• Source node opened a path (virtual circuit) to the destination node and uses that path to send traffic
• The network performs hop-by-hop destination-address-based packet forwarding.

More details in the Getting Packets Across the Network video.

A long while ago I found a great article explaining TLS 1.3 and its migration woes on CloudFlare blog. While I would strongly recommend you read it just to get familiar with TLS 1.3, the real fun starts when the author discusses migration problems, kludges you have to use trying to fix them, less-than-compliant implementations breaking those kludges, and options that were supposed to be dynamic, but turn out to be static (rusted shut) due to middleboxes that implemented protocols as-seen-in-the-wild not as-described-in-RFCs.

Change a few TLAs and you could be reading about TCP, IP stack, IPv6, BGP… I addressed those aspects in the ossification and centralization part of Upcoming Internet Challenges webinar.

When I started creating the How Networks Really Work series I wondered whether our subscribers (mostly seasoned networking engineers) would find it useful. Turns out at least some of them do; this is what a long-time subscriber sent me:

---

How Networks Really Work is great, it’s like looking from a plane and seeing how all the roads are connected to each other. I know networking just enough to design and manage a corporate network, but there are many things I have learned, used and forgotten along the way.

So, getting a broad vision helps me remember why I chose something and maybe solve my bad choices. There are many things that I may never use, but with the movement of all things in the cloud it’s great to know, or at least understand, how things really work.

---

Parts of the webinar are accessible with free ipSpace.net subscription; you need one of the paid subscriptions to watch the whole webinar.

On 23 October 2020, I took and passed the Cisco Certified DevNet Professional Core exam (350-901 DEVCOR) on my first attempt. I explain here the resources I used to study and pass this exam. My background and experience Before I explain what and how I have studied, you need to understand what I already knew, what was my background and experience with some of the topics of the exam before I started to study for it. At the end of April 2018, I already passed a Cisco specialist certification on…

The post My Cisco DevNet Core Exam Journey appeared first on AboutNetworks.net.

Sometimes you’re asked to design a network that will reroute around a failure in milliseconds. Is that feasible? Maybe. Is it simple? Absolutely not.

In this series of blog posts we’ll start with the basics, explore the technologies that you can use to reach that goal, and discover one or two unexpected rabbit holes.

When VMware NSX-T 3.0 came out, I planned to do an update session of the VMware NSX Technical Deep Dive webinar along the lines of what I did for AWS Networking a few weeks ago. However, it turned out that most of the new features didn’t take more than a bullet or two on an existing slide, or at most a new slide.

Covering them in a live session and then slicing-and-dicing the resulting recording simply didn’t make sense, so I updated the videos in summer 2020 (the last batch was published in early August).

Here’s another riff on the “when you’re the smartest person in the room, change the room” theme: The Trap of The Premature Senior by inimitable Charity Majors. Enjoy!

Wanna make your security team’s blood run cold? Remind them that all that time and effort they put in to securing the enterprise from attackers and data exfiltration is currently sitting unused while we all work from home. You might have even heard them screaming at the sky just now.

Enterprise security isn’t easy, nor should it be. We constantly have to be on the offensive to find new attack vectors and hunt down threats and exploits. We have spent years and careers building defense-in-depth to an artform not unlike making buttery croissants. It’s all great when that apparatus is protecting our enterprise data center and cloud presence like a Scottish castle repelling invaders. Right now we’re in the wilderness with nothing but a tired sentry to protect us from the marauders.

During Security Field Day 4, I led a discussion panel with the delegates about the challenges of working from home securely. Here’s a link to our discussion that I wanted to spend some time elaborating on:

Home Is Where the Exploits Are

BYOD was a huge watershed moment for the enterprise because we realized for the first time that we had to learn to secure other people’s devices. We couldn’t rely on locked-down laptops and company-issued phones to keep us safe. Security exploded when we no longer had control of the devices we were trying to protect. We all learned hard lessons about segmenting networks and stopping lateral attacks from potentially compromised machines. It’s all for naught now because we’re staring at those protections gathering dust in an empty office. With the way that commercial real estate agents are pronouncing a downturn in their market, we may not see them again soon.

Now, we have to figure out how to protect devices we don’t own on networks we don’t control. For all the talk of VPNs for company devices and SD-WAN devices at the edge to set up on-demand protection, we’re still in the dark when it comes to the environment around our corporate assets. Sure, the company Thinkpad is safe and sound and isolated at the CEO’s house. But what about his wife’s laptop? Or the kids and their Android tablets? Or even the smart speakers and home IoT devices around it? How can we be sure those are all safe?

Worse still, how do you convince the executives of a company that their networks aren’t up to par? How can you tell someone that controls your livelihood they need to install more firewalls or segment their network for security? If the PlayStation suddenly needs to authenticate to the wireless and is firewalled away from the TV to play movies over AirPlay, you’re going to get a lot of panicked phone calls.

Security As A Starting Point

If we’re going to make Build Your Own Office (BYOO) security work for our enterprise employees, we need to reset our goals. Are we really trying to keep everyone 100% safe and secure 100% of the time? Are we trying for total control over all assets? Or is there a level of insecurity we are willing to accept to make things work more smoothly?

On-demand VPNs are a good example. It’s fine to require them to access company resources behind a firewall in the enterprise data center. But does it need to be enabled to access things in the public cloud? Should the employee have to have it enabled if they decide to work on the report at 8:00pm when they haven’t ever needed it on before? These challenges are more about policy than technology.

Policy is the heart of how we need to rebuild BYOO security. We need to examine which policies are in place now and determine if they make sense for people that may never come back into the office. Don’t want to use the VPN for connectivity? Fine. However, you will need to enable two-factor authentication (2FA) on your accounts and use a software token on your phone to access our systems. Don’t want to install the apps on your laptop to access cloud resources? We’re going to lock you out until we’ve evaluated everything remotely for security purposes.

Policy has an important role to play. It is the reason for our technology and the driver for our work. Policy is why I have 2FA enabled on all my corporate accounts. Policy is why I don’t have superuser rights to certain devices but instead authenticate changes as needed with suitable logging. Policy is why I can’t log in to a corporate email server from a vacation home in the middle of nowhere because I’m not using a secured connection. It’s all relevant to the way we do business.

Pushing Policy Buttons

You, as a security professional, need to spend the rest of 2020 doing policy audits. You’re going to get crosseyed. You’re going to hate it. So will anyone you contact about it. Trust me, they hate it just like you do. But you have to make it happen., You have to justify why you’re doing things the way you’re doing them. “This is how we’ve always done it” is no longer justification for a policy. We’re still trying to pull through a global pandemic that has costs thousands their jobs and displaced thousands more to a home they never thought was going to support actual work. Now is not the time to get squeamish.

It’s time to scrub your policies down to the baseboards and get to cleaning and building them back up. Figure out what you need and what is required. Implement changes you’ve always needed to make, like software updates or applications that enhance security. If you want to make it stick in this new world of working from home you need to put it in place at the deepest levels now. And it needs to stick for everyone. No executive workarounds. No grace extensions for them to keep their favorite insecure apps or allowing them to not have 2FA enabled on everything. They need to lead by example from the front, not lag in the back being insecure.

---

Tom’s Take

I loved the talk at Security Field Day about security at home. We weighed a lot of things that people aren’t really thinking about right now because we haven’t had a major breach in “at home” security. Yet. We know it’s coming and if it happens the current state of network segementation isn’t going to be kind to whomever is under the gun. Definitely watch the video above and tell me your thoughts, either on the video comments or here. We can keep things safe and secure no matter where we are. We just need to think about what that looks like at the lowest policy level and build up from there.

In the last part of his Cumulus Linux 4.0 Update Pete Lumbis talked about using NetQ to capture streaming telemetry and increase network observability, and the new model-driven configuration approach (including all the usual buzzwords like NETCONF, RPC, YAML, JSON, and OpenConfig) coming in 2020.

Got this question from one of the networking engineers “blessed” with rampant clueless-rush-to-the-cloud.

I plan to peer multiple VNet from different regions. The problem is that there is not any consistent deployment in regards to the private IP subnets used on each VNet to the point I found several of them using public IP blocks as private IP ranges. As far as I recall, in Azure we can’t re-ip the VNets as the resource will be deleted so I don’t see any other option than use NAT from offending VNet subnets to use my internal RFC1918 IPv4 range. Do you have a better idea?

The way I understand Azure, while you COULD have any address range configured as VNet CIDR block, you MUST have non-overlapping address ranges for VNet peering.

I've teamed up with Keith Townsend to talk IT Strategy.

One of my readers sent me a question along these lines:

Imagine you have a router with four equal-cost paths to prefix X, two toward upstream-1 and two toward upstream-2. Now let’s suppose that one of those links goes down and you want to have link protection. Do I really need Loop-Free Alternate (LFA) or MPLS Fast Reroute (FRR) to get fast (= immediate) failover or could I rely on multiple equal-cost paths to get the job done? I’m getting different answers from different vendors…

Please note that we’re talking about a very specific question of whether in scenarios with equal-cost layer-3 paths the hardware forwarding data structures get adjusted automatically on link failure (without CPU reprogramming them), and whether LFA needs to be configured to make the adjustment happen.

Even though I’ve developed software for a number of years now, there’s one question that has always been in the back of my mind and I haven’t had the time or patience to really answer, until now: What is a binary executable anyways? For this example, I wrote a brutally simple Rust program that includes a function “sum” to add two integers together, and am invoking it from main(): fn main() { println!

Did you ever experience an out-of-the-blue BGP session flap after you were running that peering for months? As Dmytro Shypovalov explains in his latest blog post, it’s always MTU (just kidding, of course it’s always DNS, but MTU blackholes nonetheless result in some crazy behavior).

When restructuring our online courses we decided to make the video content that was previously part of Ansible online course available with Standard ipSpace.net Subscription.

If you haven’t enrolled into our automation online course (which always included the extra bits) you’ll find the following additional content in our Ansible for Networking Engineers webinar:

John Capobianco, author and IT technical advisor, describes the advantages of RESTful interfaces and YANG models for interacting with network devices. You can listen to the full episode here: Heavy Networking 545: Achieving Automated Network State Validation. Heavy Networking is part of the Packet Pushers network of technical podcasts, including Day Two Cloud, IPv6 Buzz, […]

The post Exploring Network State Via APIs Is Incredible – Video appeared first on Packet Pushers.

This is a technical report on a detailed exploration of the way the Internet’s Domain Name System (DNS) interacts with the network when the size of the application transactions exceeds the underlying packet size limitations of hosts and networks.

What do consultants mean by “shifting left” in terms of cloud adoption and DevOps practices? April Edwards, a Senior Software Engineer at Microsoft, offers a definition, including fixing bugs before they get to production, iterating faster on new products and features, and minimizing technical debt. If you’d like to hear April’s entire conversation with Ethan […]

The post Failing Fast Is Okay If You Shift Left – Video appeared first on Packet Pushers.

Can you hear me? Are you listening to me? Those two statements are used frequently to see if someone is paying attention to what you’re saying. Their connotation is very different though. One asks a question about whether you can tell if there are words coming out of someone’s mouth. Is the language something you can process? The other question is all about understanding.

Taking Turns Speaking

“Seek first to understand,then to be understood.” – Stephen Covey

Listening is hard. Like super hard. How often do you find yourself on a conference call with your mind wandering to other things you need to take care of? How many times have we seen someone shopping online for shoes or camping gear instead of taking notes on the call they should be paying attention to? They answer is more often than we should.

Attention spans are hard for everyone, whether you’re affected by attention disorders or have normal brain chemistry. Our minds hate being bored. They’re always looking for a way to escape to something more exciting and stimulating. You know you can feel it when there’s a topic that seriously interests you and pulls you in versus the same old staff meeting each week when we just run down a list of notes that haven’t changed in weeks.

The second reason why listening is harder for us is because we’re often waiting for our turn to talk. Be honest with yourself on this one. During your last five conversations with people, were you really listening to what they were saying? Or were you just waiting for an opportunity to jump in with a statement or opinion? And, in all honesty, was that statement just something you were going to say to prove that you were paying attention the whole time?

I admit I have huge issues with attention and listening myself. My brain is always racing a thousand miles an hour with the statements people make. If it’s a briefing I’m usually thinking about use cases or applications of technology or where the next steps will go. If it’s a discussion about a topic with opinions I’m listening for their position and formulating my response by taking their arguments and finding counter arguments. If it’s a boring meeting or status update session I’m usually working on my own list or trying to cross tasks off to get ahead with my time.

Whatever your reason for not paying attention, you have to realize that doing it means you’re not focused on the message. In classic communications training, the lesson is that there are three components to a message:

1. The sender
2. The receiver
3. The message

People focus on the first and the third a lot. They optimize how to deliver a speech or how to craft the perfect message. The second part of the list is the one that gets neglected. How does the receiver act in the communication? Do they pay attention actively and summarize the content? Do they ask questions to seek better understanding? Or are they bored? Are they looking for their opportunity to turn things around and make themselves the primary sender?

Seeking Understanding

It’s been a long hard road for me at Tech Field Day and Gestalt IT to learn how to listen and understand and not just hear and hope for a chance to speak or tell a story. Stephen Foskett (@SFoskett) has helped me a lot by making me sit back and listen and get people talking instead of dominating the conversation. My time with the BSA Wood Badge program has also given me a lot of tools to help.

Here are a few ways that I work on listening with the intention to understand:

• Taking Notes – This is something that I work hard on because with every conversation I tell myself I have a great memory and then I remember that I’ve forgotten I don’t. I’m a voracious note-taker. If a piece of paper has a square inch of space and there is a pen in reach I will write on it. Sadly, this means there are notes all over the place with zero context that have been lost to time. My note taking strategy has evolved to embrace things like pre-notes, where I start the notes for a briefing or conversation ahead of time to capture important questions or thoughts to ask, written electronic notes with my iPad and Notability where I can write things down on the fly without having to stop to think about typing, and consolidation of notes, where I go back and add those notes to a program like Agenda. Yes, it’s extra work but that extra work helps me summarize, categorize, and draw conclusions during the consolidation process. It’s like reading your study notes back a second time or rewatching a sports play to catch the nuance of the action.
• Comprehension Questions – When you’re in a briefing, it’s easy to fall into the trap of just repeating back the thing you heard a minute ago to prove you’re paying attention. When I’m teaching my Scouts something and I ask them if they’re paying attention, some of the time they’ll do this to me. I fight back by asking them what that last thing they told me means to them in their own words. I want them to be thinking the whole time and not just listening for their name. Critical thinking is a skill we have to develop just like a fastball or juggling. The way to increase it is to be able to ask a summarizing question in a briefing. Speakers will pause frequently to ask, “Are there any questions? Is this making sense?” This is your chance to jump in with a summary and a question. Quickly summarize the important point – “You said BGP is broken” followed by a question, “Can we fix it with identity validation or something like PKI?” A word of warning on this one: remember to ask a question seeking knowledge. Don’t just state an opinion trying to prove you’re smarter than the speaker and then ask them what they think about your opinion.
• Take The Lead – This one is especially important for people that interview others or podcasters that deal with shy guests. There are times when you realize the person you’re talking to is smart and capable but doesn’t communicate well. If you see that you’re going to need to jump in a take an active role in the conversation, but from the perspective of teasing out their knowledge. Leading them to where they need to be to be comfortable or expressive. My good friend Ethan Banks (@ECBanks) does an amazing job of this on his podcasts. He asks questions in a way that gives the speaker a clear opening to seize on his words to tell their story. It’s like watching an episode of Perry Mason where the star lawyer asks a question in the right way to make the witness tell the story they’re afraid of telling. When you do it right, it seems like you’re just very curious and the speaker does the job of telling the story. If you do it wrong, you’re dominating the conversation and putting words in someone’s mouth. If you really want to practice this part, ask your kids (or someone close to you) how their day went. Don’t let them stop at “fine” or “good”. Encourage them to expand on that by asking very leading questions about specific parts of the day or topics of interest. You’ll be a pro in no time.

---

Tom’s Take

Did all of that make sense to you? Did you hear me? Did you listen? Video content creation and blog posts are hard tools for communication because we’re cutting out the second part of the communication process. I don’t get to see your understanding or ask questions that allow you to consolidate your knowledge. I have to hope that the topics here are things that you enjoy and understand, even if you have to go back and read them a couple more times. I promise that if you work on the things above in the coming months you’re going to find yourself a better, more active listener with a lot of knowledge gained. And that’s a learning lesson worth listening to.

What is network state? John Capobianco, author and IT technical advisor, offers a definition in this discussion on network automation with Ethan Banks. You can listen to the full episode here: Heavy Networking 545: Achieving Automated Network State Validation. Heavy Networking is part of the Packet Pushers network of technical podcasts, including Day Two Cloud, […]

The post Clearly Defining Network State – Video appeared first on Packet Pushers.

The pace of change in software development and operations feels like it’s accelerating so quickly that if you haven’t inculcated a DevOps culture by now, you shouldn’t bother. April Edwards, a Senior Software Engineer at Microsoft, is here to tell you why it’s not too late, in this excerpt from the Day Two Cloud podcast. […]

The post You Are NOT Behind The DevOps Curve – Video appeared first on Packet Pushers.

Automated state validation can give you a critical perspective on your network and its devices that third-party network management systems may miss. Ethan Banks welcomes guest John Capobianco, author and IT technical advisor, to discuss the value of automated state validation in this excerpt from the podcast “Heavy Networking 545: Achieving Automated Network State Validation.” […]

The post Automated State Validation Is So Much More Than SNMP – Video appeared first on Packet Pushers.