If you’re like me, you chuckle every time someone tells you that next year is the year of whatever technology is going to be hot. Don’t believe me? Which year was the Year of VDI again? I know that writing the title of this post probably made you shake your head in amusement but I truly believe that we’ve hit the point of adoption of Wi-Fi 6E next year.

Device Support Blooms

There are rumors that the new iPhone 14 will adopt Wi-Fi 6E. There were the same rumors when the iPhone 13 was coming out and the iPhone rumor mill is always a mixed bag but I think we’re on track this time. Part of the reason for that is the advancements made in Wi-Fi 6 Release 2. The power management features for 6ER2 are something that should appeal to mobile device users, even if the name is confusing as can be.

Mobile phones don’t make a market. If they were the only driver for wireless adoption the Samsung handsets would have everyone on 6E by now. Instead, it’s the ecosystem. Apple putting a 6E radio in the iPhone wouldn’t be enough to tip the scales. It would take a concerted effort of adoption across the board, right? Well, what else does Apple have on deck that can drive the market?

The first thing is the rumored M2 iPad Pro. It’s expected to debut in October 2022 and feature upgrades aside from the CPU like wireless charging. One of the biggest features would be the inclusion of a Wi-Fi 6E radio as well to match the new iPhone. That would mean both of Apple’s mobile devices could enjoy the faster and less congested bandwidth of 6 GHz. The iPad would also be easier to build a new chip around compared to the relatively cramped space inside the iPhone. Give the professional nature of the iPad Pro one might expect an enterprise-grade feature like 6E support to help move some units.

The second thing is the looming M2 MacBook Pro. Note for this specific example I’m talking about the 14” and 16” models that would features the Pro and Max chips, not the 13” model running a base M2. Apple packed the M1 Pro and M1 Max models with new features last year, including more ports and a snazzy case redesign. What would drive people to adopt the new model so soon? How about faster connectivity? Given that people are already complaining that the M1 Pro has slow Wi-Fi Apple could really silence their armchair critics with a Wi-Fi 6E radio.

You may notice that I’m relying heavily on Apple here as my reasoning behind the projected growth of 6E in 2023. It’s not because I’m a fanboy. It’s because Apple is one of the only companies that controls their own ecosystem to the point of being able to add support for a technology across the board and drive adoption among their user base. Sure, we’ve had 6E radios from Samsung and Dell and many others for the past year or so. Did they drive the sales of 6E radios in the enterprise? Or even in home routers? I’d argue they haven’t. But Apple isn’t the only reason why.

Oldie But Goodie

The last reason that 2023 is going to be the year of Wi-Fi 6E is because of timing. Specifically I’m talking about the timing of a refresh cycle in the enterprise. The first Wi-Fi 6 APs started coming into the market in 2019. Early adopters jumped at the chance to have more bandwidth across the board. But those APs are getting old by the standards of tech. They may still pass traffic but users that are going back to the office are going to want more than standard connectivity. Especially if those users splurged for a new iPhone or iPad for Christmas or are looking for a new work laptop of the Macintosh variety.

Enterprises may not have been packed with users for the past couple of years but that doesn’t mean the tech stood still. Faster and better is always the mantra of the cutting edge company. The revisions in the new standards would make life easier for those trying to deploy new IoT sensors or deal with with congested buildings. If enterprise vendors adopt these new APs in the early part of the year it could even function as an incentive to get people back in the office instead of the slow insecure coffee shop around the corner.

One other little quirky thing comes from an report that Intel is looking to adopt Wi-Fi 7. It may just be the cynic in me talking but as soon as we start talking about a new technology on the horizon people start assuming that the “current” cutting edge tech is ready for adoption. It’s the same as people that caution you not to install a new operating system until after the first patch or service release. Considering that Wi-Fi 6 Release 2 is effectively Wi-Fi 6E Service Pack 1 I think the cynics in the audience are going to think that it’s time to adopt Wi-Fi 6E since it’s ready for action.

Tom’s Take

Technology for the sake of tech is always going to fail. You need drivers for adoption and usage. If cool tech won the day we’d be watching Betamax movies or HD-DVD instead of streaming on Netflix. Instead, the real winners are the technologies that get used. So far that hasn’t been Wi-Fi 6E for a variety of reasons. However, with the projections of releases coming soon from Apple I think we’re going to see a massive wave of adoption of Wi-Fi 6E in 2023. And if you’re reading this in late 2023 or beyond and it didn’t happen, just mentally change the title to whatever next year is and that will be the truth.

In this final episode of the Ansible For Network Automation course, Josh VanDeraa explores how to gather network information, setting up Meraki VLANs with Ansible, and creating and deleting Meraki SSIDs. You can find the full playlist with all the videos in the course on the Packet Pushers’ YouTube channel. You can subscribe to the […]

The post Ansible For Network Automation Lesson 11: Ansible For Meraki – Video appeared first on Packet Pushers.

Course instructor Josh VanDeraa provides more detail on roles in Ansible, and then shows a practical example by configuring and verifying QoS settings on network devices by taking advantage of roles. You can find the full playlist with all the videos in the course on the Packet Pushers’ YouTube channel. You can subscribe to the […]

The post Ansible For Network Automation Lesson 10: Ansible Configuration And Verification – Video appeared first on Packet Pushers.

My boss stepped into our shared cubicle space and rested his arm on top of the fabric wall. He peered down at me. “Hey.” He always started with a quiet “hey” when he was about to ask me to do something new. I glanced at my whiteboard filled with projects and statuses, and steeled myself for the fresh request.

“Hey. I just got out of a meeting with Lewis.” I groaned inwardly. Lewis was my boss’s boss, and while Lewis was a fantastic human being, meetings with him were usually in the context of projects. Big ones. I put on a fake smile to mask creeping despair. “Oh? How did that go?”

My boss ripped off the band-aid. “Lewis wants a monthly summary from everyone of what they’ve been doing. So, on the last Friday of the month, make sure you have all your project statuses updated, including key milestones. Your whiteboard is great for you and me since we share this space, but now you’re going to need to log your statuses into the project database.” He smirked. “Like a big boy.”

I died a little inside. One of the reasons I’d left consulting to join this company was because of how thoroughly I loathed timesheets. At the consultancy, timesheets were life. Customers bought hours. We billed against those hours. We had to justify the billing in an annoying level of detail. It wasn’t that I didn’t understand the value of timesheets. I did. I just hated the time-sucking tedium of tracking the time and then filling out the sheets, especially if I’d gotten behind. And now a new form of timesheets?!? No, thanks.

I logged my objection, somewhat under my breath to avoid being overheard. “Are you serious? You know what’s on my plate. You know how busy I am–how busy we all are.” I traced a wide arc with an outstretched arm, sweeping across an IT group that was overworked, project-laden, perpetually on-call, and burning out. “Do we really need to be taking time to explain what we’re getting done? Does Lewis not understand what the IT team he leads actually does day to day? I know projects are behind, but we’re doing our best!”

I continued my tirade, my ire rising. “Dude, I was here all Friday night to be ready for the Saturday maintenance. I fell asleep IN THIS CHAIR just so we could get that core switch replacement done. I’m not asking for a medal, but I’m feeling a little unappreciated all of a sudden.”

I stopped, realizing if I didn’t shut up, I was going to say something I’d regret. I was already pushing boundaries.

My unflappable boss stared down at me, arm still propped up on the cubicle wall. He wasn’t upset, but it was clear he had a point to make. “I know what you did Friday, and what you do every day. You know I do. You get good reviews from me. And from Lewis.”

He paused for a moment, collecting his thoughts. “I don’t know that I should share this, but I’m going to anyway. Keep this to yourself.”

He continued. “Logging project statuses and accomplishments is about Lewis building bridges with the rest of senior management across the company. The guy Lewis replaced was so difficult to deal with, that the business still dislikes and distrusts IT even though he’s long gone. Lewis is fixing all of that. He’s mending IT’s relationship with the rest of the business. If he succeeds, we get the headcount we need. You don’t have to be on call 24×7. You can go on vacation and leave your laptop behind. You’ll have time to go to a training class. But it starts with Lewis being able to take all of what this department produces and explaining to the business why it matters.”

He paused again, glancing between me and my project whiteboard. Then he made one final point that brought it all together. “Don’t think of it as a status report. Think of it as…bragging. As advocating for yourself. As an opportunity to be proud of all the cool stuff you get done in a month. What we do in IT matters. Let’s help Lewis tell that story.”

About three months later, I sat on the panel interviewing candidates for our open req. I was going to have a junior network admin to train.

My “network fables” are fictional tales based heavily on my real-life experiences as a network engineer.

Gluware focuses on real-world network automation capabilities in brownfield environments. In this video, part of the Packet Pushers LiveStream with Gluware from June 28, 2022, Greg Ferro talks with Gluware’s Ernest Lefner about the product’s capabilities, as well as new features including Network Robotic Process Automation (RPA) and Gluware Topology. For more information, go to […]

The post Gluware Background And Evolution: Gluware LiveStream June 28, 2022 (7/7) – Video appeared first on Packet Pushers.

In this episode, instructor Josh VanDeraa reviews the use of REST APIs in Ansible, and explores the open-source tool Netbox as a source of truth.

The post Ansible For Network Automation Lesson 9: Working With APIs – Video appeared first on Packet Pushers.

I’m sure by now you’ve probably seen tons of articles telling you about how important it is to travel with location devices in your luggage. The most common one I’ve seen is the Apple AirTag. The logic goes that if you have one in your checked suitcase that you’ll know if there are any issues with your luggage getting lost right away because you’ll be notified as soon as you’re separated from it. The advice is sound if you’re someone that checks your bag frequently or has it lost on a regular basis.

The idea behind using technology to enforce an agreement is a great one. We make these agreements all the time, especially in networking. These service level agreements (SLAs) are the way we know we’re getting what we pay for. Take a leased line, for example. You typically pay for a certain speed and a certain amount of availability. The faster the link or the more available it is the more it costs. Any good consumer is going to want to be sure they’re paying for the right service. How can you verify you’re getting what you’re paying for?

For a long time this was very hard to do. Sure, you could run constant speed tests to check the bandwidth. However, the reliability was the part that was typically the more expensive thing to add to the service. Making a circuit more reliable means adding more resources on the provider side to ensure it stays up. Allocating those resources means someone needs to pay for them and that is usually on the customer side.

It’s easy to tell when a link goes down during working hours. You can see that you’re not getting traffic out of your network. But what about those times when the circuit isn’t being as heavily utilized? What about the middle of the night or holidays? How can you ensure that you’re getting the uptime you pay for?

Trust and Verify

This is actually one of the groundbreaking areas that SD-WAN pioneered for networking teams when it came out years ago. Because you have a more modern way of maintaining the network as well as a way to route application traffic based on more than source and destination address you can build in some fancy logic to determine the reliability of your circuits too.

One of the biggest reasons in the past to use a leased line over a broadband circuit was that reliability factor. You need MPLS because it’s more stable than a cable modem. You get guaranteed bandwidth. It’s way more reliable. Those are the claims that you might hear when you talk to the salesperson at your ISP. But do they really hold water? The issue for years is that you had no way of knowing because your analytics capabilities were rudimentary in most cases. You could monitor the link interface but that was usually from the central office and not the remote branch. And depending on the polling interval you could miss downtime events.

SD-WAN changed that because now you could put an intelligent device on the edge that constantly monitored the link for throughput and reliability. The first thought was to do this for the broadband links to see how congested and unreliable they could be do know when to switch traffic to the more stable link. Over time admins started putting those same monitors on the MPLS and leased line circuits as well. They found that while broadband, such as cable and DSL, was typically more reliable than the sales people would have you believe it was the relatively unreliable leased circuits that surprised everyone.

Much like the above example of lost luggage you previously had to take the airlines at their word when they said something was lost. No details were available. Did your bag ever leave the airport when you flew out? Did it make it to the right location but get stuck somewhere? Did your bag get on the wrong plane and end up in Cleveland instead of Las Vegas? Because the airline reporting systems were so opaque you had no idea. Now, with the advent of Tile and AirTags and many others, you can see exactly where it is at all times.

The same thing happened with SD-WAN analytics. Now, armed with proof that links weren’t as reliable as the SLA, admins could choose to do one of two things. They could either force the provider to honor the agreement and provide better service to meet the agreement. Or the company could reduce their contract to the level of service they are actually getting instead of the one that is promised by not delivered. Having the data and a way to prove the reliability helped with the negotiations.

Once the providers knew that organizations had the ability to verify things they also had to up their game by including ways to monitor their own performance to ensure that they were meeting their own metrics. Overall the situation led to better results because having technology to enforce agreements makes all sides aware of what’s going on.

Tom’s Take

I’ve only had a couple of bags misplaced in my travel time so I haven’t yet had the need to go down the AirTag route. I’ve done it on occasion for international travel because knowing when my bag is about to come out on the carousel helps me figure out how much time it’s going to take me to get through customs. The idea of using technology to make things more transparent is important to me on a bigger scale though. If you can’t verify the promises you make then you shouldn’t make them. Having the AirTag or SD-WAN software to ensure we’re getting what we pay for are just parts of a bigger opportunity to provide better experiences.

The Gluware application suite that includes Device Manager, Config Drift and Audit, OS Manager and Config Modeling provide no-code automation to enable and maintain compliance and enhance security. Now, Network RPA enables defining automated end-to-end processes that ensure policies and procedures are executed manually, scheduled or event-driven providing continuous compliance and improved security posture. Host […]

The post Network RPA Compliance and Security Use Cases: Gluware LiveStream June 28, 2022 (6/7) – Video appeared first on Packet Pushers.

In the previous posts in this series, I concluded that privacy is everyone’s responsibility, that IP addresses (and a lot of other information network engineers handle) are protected information, and while processing packets probably doesn’t trigger any privacy warnings, network logging should and does. In this post, I want to start answering the question—okay, what […]

The post Privacy And Networking Part 5: The Data Lifecycle appeared first on Packet Pushers.

Ages ago when we were building networks using super-expensive 64kbps WAN links, a customer sent us a weird bug report:

Everything works fine, but we cannot transfer one particular file between two locations – the file transfer stalls and eventually times out. At the same time, we’re seeing increased number of CRC errors on the WAN link.

My chat with the engineer handling the ticket went along these lines:

Device Insights, a feature of Cisco's SecureX XDR service, aggregates, normalizes, and visualizes esssential details about all the devices on your network. SecureX can also automate workflows to respond to device-level security problems.

The post An Overview Of Cisco’s SecureX Device Insights appeared first on Packet Pushers.

This lesson covers the concept of idempotency and why it’s essential to Ansible. You can find the full playlist with all 8 videos on the Packet Pushers’ YouTube channel. You can subscribe to the Packet Pushers’ YouTube channel for more videos as they are published. It’s a diverse a mix of content from Ethan and […]

The post Ansible For Network Automation Lesson 8: Ansible And Idempotency – Video appeared first on Packet Pushers.

Gluware is introducing a new feature on its network automation platform, Network RPA, or Robotic Process Automation. Network RPA enables no-code process automation, meaning network engineers can easily stitch together automation workflows using a visual interface. Network RPA integrates with Stackstorm out of the box, meaning engineers can create workflows with everything Stackstorm supports, which […]

The post Introducing Network RPA No-Code Process Automation: Gluware LiveStream June 28, 2022 (5/7) – Video appeared first on Packet Pushers.

This post originally appeared on the Packet Pushers’ now-defunct Ignition site on September 17, 2019.   I have a lot of respect for people who focus on network automation and the people at Network To Code are top notch at helping and giving to open source. However, I do mostly disagree with this take on […]

The post Is Automation A Full-Time Career? appeared first on Packet Pushers.

In the last post on this topic, I concluded that IP addresses are protected information—operators should handle users’ IP addresses according to privacy best practices. But I also concluded that because IP addresses used for forwarding— Are collected (or carried through the network) only for forwarding The user cannot reasonably expect the network to forward […]

The post Privacy And Networking Part 4: Logging appeared first on Packet Pushers.

This video offers a brief introduction to essential Kubernetes networking constructs: ingress and service mesh, including product examples. Ingress is a proxy that manages access to services within a Kubernetes cluster. A service mesh connects applications or services within the cluster. Host Michael Levan brings his background in system administration, software development, and DevOps to […]

The post Kubernetes For Network Engineers – Lesson 5: Ingress And Service Mesh – Video appeared first on Packet Pushers.

When I was a lad in high school I worked for Walmart. I learned quite a bit about retail at my early age but one of the fascinating things I used in the late 1990s was a wireless inventory unit, colloquially known as a Telxon. I was amazed by the ability to get inventory numbers on a device without a cable. Since this was prior to the adoption of IEEE 802.11 it was a proprietary device that only worked with that system.

Flash forward to the 2020s. I went to Walmart the other day to look for an item and I couldn’t find it. I asked one of the associates if it was in stock. They said they could check and pulled out their phone. To my surprise they were able to launch an app and see that it was in stock in the back. As I waited for them to return with the item I thought about how 25 years of progress had changed that hardware solution into something software focused.

Hardware Genesis

All problems start as hardware problems. If there’s a solution to an issue you’re going to build something first. Need to get somewhere fast? Trains or cars. Need to get there faster? Planes. Communcations? Phones or the Internet. All problems start out by inventing a thing that does something.

Technology is all about overcoming challenges with novel solutions. Sometimes those leaps are major, like radio. Other times the tool is built on that technology, like wireless. However they are built they almost always take physical form first. The reasoning is simple in my view. You have to have the capability to build something before it can be optimized.

If you’re sitting there saying to yourself that a lot of our solutions today are software-focused you would be correct. However, you’re also making some assumptions about hardware ubiquity already. Sure, the smartphone is a marvel of software simplicity that provides many technological solutions. It’s also a platform that relies on wireless radio communications, Internet, and cloud computing. If you told someone in 2005 that cellular phones would be primarily used as compute devices they would have laughed at you. Because the hardware at the time was focused on audio communications and only starting to be used for other things, like texting or PDA functions.

Hardware exists first to solve the issue at hand. Once we’ve built something that can accomplish the goal we can then optimize it and make it more common. Servers seem like a mainstay of our tech world today but client/server architecture wasn’t always the king of the hill. Cloud computing seems like an obvious solution today but AWS and GCP haven’t always existed. Servers needed to become commonplace before the idea to cluster them together and offer their capacity as a rentable service emerged.

Software to the Rescue

Software doesn’t like unpredictability. Remember the Telxon example above? Those devices ran proprietary software that interfaced with a single server. There was no variation. If you wanted to use the inventory software on a different device you were out of luck. There was zero flexibility. It was a tool that was designed for a purpose. So many of the things in our lives are built the same way. Just look at your home phone, for example. That is, if you still have one. It’s a simple device that doesn’t even run software as we know it. Just a collection of electrical switches and transistors that accomplish a goal.

However, we have abstracted the interface of a telephone into a device that provides flexibility. Any smart phone you see is a computer running software with a familiar interface to make a phone call. There’s no specialized hardware involved. Just an interface to a system that performs the same functions that a traditional phone would. There are no wires. No switches like an old telecom engineer would recognize. Just a software platform that sends voice over the Internet to a receiving station.

Software becomes an option when we’ve built a hardware environment that is sufficiently predictable as to allow the functions to be abstracted. The Walmart Telxon can function as an app on a smartphone now because we can write an app to perform those same functions. We’ve also created interfaces into inventory systems that can be called by software apps and everyone that works for Walmart either carries a phone or has access to a device that can run the software.

Tom’s Take

Programs and platforms provide us with the flexibility to do things any time we want. But they only have that capability because of the infrastructure we’ve built out. We have to build the hardware before we can abstract the functions into software. The most complicated unsolved problem you can think of today will eventually be solved by a piece of kit that will eventually become a commodity and replicated as a series of functions that run on everything years later. That’s the way that things have always been and how they will always be.

In this lesson, instructor Josh Vanderaa explores how to work with templates to build configuration stanzas. You’ll also see various methods for working with Jinja2 templates, including: Template from a file to a file Template from a file to an IOS device You can find the full playlist of “Ansible For Network Automation” with all […]

The post Ansible For Network Automation Lesson 7: Templating With Ansible – Video appeared first on Packet Pushers.

This post originally appeared on the Packet Pushers’ Ignition site on October 1, 2019.   When a host doesn’t know the IP address for a hostname, what does it do? It asks its configured DNS server to resolve the hostname. (Usually. There are apps, notably browsers, that might do their own thing. But let’s go […]

The post Improving DNS Privacy With QNAME Minimization (RFC7816) appeared first on Packet Pushers.

Positioning Consultant Emily Omier advises the Day Two Cloud podcast audience on how to raise awareness of your open source software project. Just don’t say “marketing”! 😊😬 For the rest of Emily’s insights, listen to episode 118 of Day Two Cloud. https://packetpushers.net/series/day2cloud/ More Emily? https://www.linkedin.com/in/cloud-native-positioning/ You can subscribe to the Packet Pushers’ YouTube channel for […]

The post How Do I Raise Awareness Of My Open Source Software Project? feat. Emily Omier – Video appeared first on Packet Pushers.

Gluware introduces a new Topology feature in its network automation platform. Gluware Topology maps the network using the Gluware model and engine to visualize the network. Benefits of the new capability include improved operations by showing what network devices are where, faster troubleshooting, and streamlining security and audit processes. Packet Pushers host Ethan Banks joins […]

The post Introducing Gluware Topology: Packet Pushers Gluware LiveStream, June 28, 2022 (4/7) – Video appeared first on Packet Pushers.

Network engineers need to make a business case to get an automation project off the ground, and it needs to describe the benefits and value in language that non-techincal executives can understand. This video offers tips and a simple blueprint to help engineers make the case to CIOs. Host Drew Conry-Murray from the Packet Pushers […]

The post Getting Your CIO to Say Yes to Automation: Gluware LiveStream June 28, 2022 (3/7) – Video appeared first on Packet Pushers.

This post originally appeared on the Packet Pushers’ now-defunct Ignition site on October 28, 2019.   I was recently asked a question about the best business outcome of automation. My immediate thought was improved speed of operations by mechanizing operational tasks, like automated software upgrades, creating VLANs, updating ACLs or routing, and so forth. This […]

The post The Best Outcome Of Automation? Visibility appeared first on Packet Pushers.

I’m finishing up Mobility Field Day 7 this week and there’s been some exciting discussion here around a lot of technology. I think my favorite, and something I’m going to talk about more, is the continuing battle between 5G and Wi-Fi. However, there’s a lot going on that I figured I’d bring up to whet your appetite for the videos.

• What is mission critical? When you think about all the devices that are in your organization that absolutely must work every time what does that look like? And what are you prepared to do to make them work every time? If it’s a safety switch or some other kind of thing that prevents loss of life are you prepared to spend huge amounts of money to make it never fail?
• Operations teams don’t need easier systems. They need systems that remove complexity. The difference in those two things is subtle but important. Easier means that things are simplified to the point of almost being unusable. Think Apple Airport or even some Meraki devices. Whereas reduced complexity means that you’ve made the up front configuration easy but enabled the ability to configure other features in different places. Maybe that’s by giving your engineers the ability to log in to an Advanced dashboard or something like that.
• When you’re trying to figure out where your audience is on a subject, always aim slightly above their technical level. If all goes well you will pull them up to where you want them and they’ll appreciate the opportunity to stretch their thinking to meet you there. If not you’ll provide them lots of great material to learn about when they get there later.

Tom’s Take

Technology changes quickly but the way we teach it doesn’t need to if we do it right the first time. By taking the time to aim high and educate instead of retelling something we’ve already said a few times we create content that endures.

A Candlestick Phone (image courtesy of WIkipedia)

This week on the Gestalt IT Rundown, I talked about the plan by Let’s Encrypt to reuse some reserved IP address space. I’ve talked about this before and I said it was a bad idea then for a lot of reasons, mostly related to the fact that modern operating systems are coded not to allow 240/4 as a valid address space, for example. Yes, I realize that when the address space was codified back in the early days of the Internet that decisions were made to organize things and we “lost” a lot of addresses for experimental reasons. However, this is not the only time this has happened. Nor is it the largest example. For that, we need to talk about the device that you’re very likely reading this post on right now: your phone.

By the Numbers

We’re going to be referring to the North American Numbering Plan (NANP) in this post, so my non-US readers are going to want to click that link to understand how phone numbering works in the US. The NANP was devised back in the 1940s by AT&T as a way to assign numbers to the telephone exchanges so they were easy to contact. The first big decision that was made was to disallow a 1 or a 0 digit at the start of the prefix code. On a pulse dialing system that sends electrical pulses instead of the tones we associate with DTMF the error rate for having a 1 as the first digit was pretty high. It was generally ignored by the equipment. A 0 was used as the signal to a switchboard operator to get assistance. So the decision was made to restrict the 1 and the 0 for technical reasons. That’s the first technical debt choice that was made.

Next, the decision was made to make it easier for the CO switchboard operators to memorize numbers using mnemonics. That meant assigning letters to the numbers on the phone rotary dial (later keypad). Every number got three letters, leaving out Q and Z because they’re weird. Every number, that is, except 1 and 0. Because they weren’t used as the start of a prefix code they didn’t get letters assigned as noted above. Every telephone exchange was named based on the numerical prefix, which could have a 0 or a 1 in the first two digits. For example, the exchanges that started with 47x would be named using a letter from the 4 followed by a digit from the 7. Those words started with GR, such as “GRanite”, GReenwood”, and so on. it was handy to remember those as long as the telephone system didn’t get too big. If you ever watch an old movie from the 50s and hear someone asking to talk to a person whose number is KLondike5-6000 that’s why. We’ll come back to KLondike in a minute. The use of words instead of number was slowly phased out starting in 1958 because it was just easy for people to use nothing but numbers.

So what about dialing outside of your local exchange? Well, for that you need an area code right? But that area code looks just like a prefix code. How can you tell someone that you want to dial a different state? Well, AT&T came up with an interesting rule there. Remember how no prefix code started with a 0 or a 1? AT&T said that area codes MUST have a 0 or a 1 as the middle number. That organization allowed for the switchboard operator or signaling equipment to know that the first three digit code was an area code, followed by seven digits for the prefix and handset number. Simple, right? Combined with using the 1 digit to signal a long-distance interchange call you had a system that worked well for a number of years. Almost fifty, in fact, from 1947 all the way to 1995.

What happened in 1995? The telephone administrators realized they were going to run out of room given the explosion of phone numbers. The phone companies, now more than just AT&T, realized all the way back in the 1960s that growth would eventually lead to them needing to do away with the rules about restricting the middle digit of an area code to a 1 or a 0. That’s why area codes created after 1995 have middle digits in the 2-9 range. Thanks to things like mobile phones we doubled or tripled the amount of phone numbers we were going to need. Which meant tearing up all those careful plans about how to use the numbers that were created back in the 1940s to solve technical challenges.

To The Klondike

What about that KLondike number I mentioned earlier? Well, KL is 55 on the dial/keypad, so a KLondike5 number actually starts with 555. Most movie buffs will tell you that any number that has a 555 in the prefix code is a fake number since that’s what you hear in movies all the time. Originally these number were assigned to local exchanges only and used for testing purposes, except for 555-1212 which is a universal directory assistance number in every area code. In 1994, people realized that there were a huge amount of numbers that could be added to the NANP pool by reclaiming those test numbers.

However, if someone gave you a 555 number in a business setting or at a bar or club, how likely would you be to say that it was a fake or invalid number? Likely pretty high given the preponderance of usage in film. In fact, 555-0100 through 555-0199 were still set aside for “fake” number or entertainment purposes, not unlike 192.0.2.0/24 being reserved for documentation purposes.

The 555-XXXX number range is the perfect example of why a plan like Let’s Encrypt and their suggestion to reclaim the space is going to ultimately fail. You’re going to have to do a significant amount of programming to get every operating system to not immediately reject 240/4 as invalid or not immediately assume 127/8 is a loopback address. Because those decisions were made long ago, relatively speaking, and are going to take time and effort to undo. Remember that AT&T knew they were going to need to change area code rules back in the 1960s and it still took 30 years to put it into practice.

Moreover, the plans by Let’s Encrypt and others seeking to implement the Schoen draft in the IETF are ignoring a very simple truth. If we’re going to spend all this time and energy rewriting half the networking stacks in use today, why aren’t we using that energy to implement IPv6 support universally instead? It’s already a requirement if you interface with the US federal government. Why are we going to spend so much time fixing a problem we know is broken and not scalable in the future? Is it because we’re holding on to some idea from the past the IP addresses should be four octets? Is it because we want to exhaust every possible resource before being dragged into the IPv6 future? Or is it because after all these years we don’t want to admit that a better solution exists and we’re just ready to move to the next version of IP after IPv6 and we don’t want to say it out loud?

Tom’s Take

Technical debt is the result of decisions we made at the time to do what needed to be done. It’s not malicious or even petty. It’s usually what had to happen and now we have to live with it. Instead of looking at technical debt as a crushing weight we need to decide how to best fix it when necessary. Like the NANP changes we can modify things to make them work better. However, we also need to examine how much work we’re doing to perpetuate something that needs to be rewritten and why we choose do it the way we do. Phone numbers are something that are going to persist for along time. IP addresses aren’t. Let’s fix the problem the right way instead of the comfortable way.

Advizex, a reseller and Gluware customer, discusses how it uses Gluware for security audits and remediation with its clients. This includes network and device discovery, addressing configuration drift, and managing multiple vendors using the Gluware platform. Packet Pushers host Greg Ferro is joined by Michael Burns, Network Architect at Advizex to discuss real-world use cases. […]

The post Advizex: Automating Security Audits & Remediation with Gluware: LiveStream June 28, 2022 (2/7) – Video appeared first on Packet Pushers.

In this lesson on using Ansible for network automation, Josh VanDeraa looks at how to get started with Ansible Vault, re-using tasks in multiple playbooks with include_tasks, and leveraging loops in your playbooks. Josh has created a GitHub repo to store additional material, including links and documentation: https://github.com/jvanderaa/AnsibleForNetworkAutomation You can find the full playlist of […]

The post Ansible For Network Automation Lesson 6: Ansible Vault And Loops – Video appeared first on Packet Pushers.

The results you can get when you know how to apply proper glue to a bunch of open-source tools never cease to amaze me. The latest entrant in that category: Akvorado, a Netflow/IPFIX collector and analyzer by Vincent Bernat.

Some of the sample graphs (shown in the GitHub repo) are not far off from those that knocked our socks off during the first Kentik Networking Field Day presentation. Definitely a tool worth exploring ;)

When reading marketing literature as an engineer, you must always be careful to parse the words correctly. For example, I was reviewing a vendor’s pitch deck on a new hardware switch. The switch was described as having the following attributes.

• Cloud-native
• AI-driven
• Secure
• Next-generation

From an engineering perspective, nothing of value has been described to you in that list.

I have no idea what they are trying to get at with cloud-native. I can think of no greater antithesis to “cloud-native” than a chunk of hardware you bolt into a rack to do network things. Someone on Twitter suggested that because the switch supports ZTP, it’s cloud-native…which, if so, is comedy gold.

AI-driven means…what, exactly? That there is some AI on the switch itself doing data analysis and changing the network configuration in response to whatever the algorithm thinks is best? It could mean that, although then we’d have to discuss what’s meant by AI, whether or not the “AI” is happening off- or on-box, and why that’s different from software-defined.

Secure is a word you sprinkle over every technology product. Because of course it’s secure. But again, what does secure mean in this context? That the switch was built with supply-chain integrity and cryptographically provable hardware identity? Maybe. Or it might merely mean that the switch has a login prompt when you try to get at the CLI over a console port.

Next-generation? Who knows? Sounds impressive, though–I mean, who wants that crappy last generation stuff? Of course I want the next generation!

These words are not for you, the engineer. The dog whistle is blowing at a frequency your ears are not attuned to. These words are meant to entice folks with purchasing authority. Your boss. Or his boss. Or her boss. Marketing buzzwords echo the terminology popularized in reports by analysis firms such as Gartner, selling the idea that this vendor’s product does all the things the Gartner report says it’s supposed to.

Don’t Infer–Verify

The problem with these vague words is that you might infer a feature that is not actually a product capability. That’s where your job as an engineer comes in. Use these words as a starting point to discover and understand the specific capabilities the product has.

Let’s revisit the claim of cloud-native. You can infer that the vendor is intimating some sort of cloud functionality. What is that functionality, exactly? Once you figure out what the function is, you can decide if it would help the business with, say, IT operations, security posture, bringing a product to market more quickly, etc.

That’s one of your roles as an engineer: translating non-specific buzzwords into specific capabilities so you can make architectural decisions. When you can do that, you bring significant value to your organization, as you become an arbiter of product usefulness.

Long long time ago, we built a multi-protocol WAN network for a large organization. Everything worked great, until we got the weirdest bug report I’ve seen thus far:

When trying to transfer a particular file with DECnet to the central location, the WAN link drops. That does not happen with any other file, or when transferring the same file with TCP/IP. The only way to recover is to power cycle the modem.

Try to figure out what was going on before reading any further ;)

I’ve been hearing a lot of claims recently about how companies are starting to rely more and more on cyberinsurance policies to cover them in the event of a breach or other form of disaster. While I’m a fan of insurance policies in general I think the companies trying to rely on these payouts to avoid doing any real security work is going to be a big surprise to them in the future.

Due Diligence

The first issue that I see is that companies are so worried about getting breached that they think taking out big insurance policies are the key to avoiding any big liability. Think about an organization that holds personally identifiable information (PII) and how likely it is that they would get sued in the event of a breach. The idea is that cyberinsurance would pay out for the breach and be used as a way to pay off the damages in a lawsuit.

The issue I have with this is that companies are expecting to get paid. They see cyberinsurance as a guaranteed payout instead of a last resort. In the initial days of taking out these big policies the insurers were happy to pay out because they were getting huge premiums in return. However, as soon as the flood of payouts started happening the insurers had to come back down to earth and realize they had to put safeguards in place to keep themselves from going bankrupt.

For anyone out there hoping to take out a big insurance policy and get paid when you inevitably get compromised you’re about to face a harsh reality. Gone are the days of insuring your enterprise against cyber threats without doing some form of due diligence on the setup. You’re going to have to prove you did everything you could to prevent this from happening before you get to collect. And if you’ve ever filed an insurance claim for a car or a house you know that it can take weeks for them to investigate everything to find out if there is a way for them to not pay out.

There is a very reasonable chance your policy will exclude certain conditions that could have easily been prevented. It would be potentially embarrassing for your executives to find out you are unable to collect on an insurance policy because it specifically doesn’t cover social engineering or business email compromise (BEC).

Getting Ahead of the Insurance Game

How can you prevent this from happening? What steps can you take today to make sure you’re not going to find yourself on the losing end of a security incident?

1. Check Your Coverage – It’s boring and reads like stereo instructions but you really do need to check your insurance policy completely, especially the parts that mention things that are specifically excluded from coverage. You need to know what isn’t going to be covered in a breach and have a response for those things. You need to know how to respond in areas that are potential weak points and be ready to confirm that you didn’t end up getting attacked there.
2. Look for Suggestions From the Insurer – I know people that will only buy cars based on safety reports from industry groups. They’d rather have something less flashy or cool in favor of a car that is going to keep them protected in the event of an accident. The insurance companies love to publish those reports because it means that more sales of those cars means smaller payouts on claims. Likewise, more companies that provide cyberinsurance are starting to publish lists of software that they would encourage or outright require in an organization in order to have coverage or be eligible for a payout. If your company has such a list you should really get it and make sure you’ve checked the boxes. You don’t want to find yourself in a situation where one missed avenue of attack cost you the whole policy.
3. Make Sure Your Reports Are Working – In the event that everything does go wrong you’re going to need to provide proof to people that you did all you could to prevent it. That means logs and incident reports and even more data about what went wrong and when. You don’t want to go and pull up that reporting data after the worst day of your cybersecurity life only to find the reporting system hasn’t been working properly for months. Then you’re not only behind on getting the incident dealt with but you’re also slowing down the potential recovery on the policy. The insurance company is happy for you to take as much time as you need because every day that they don’t pay you is one more day they’re making money off their investments. Don’t delay yourself any more than you need to.

Tom’s Take

The best insurance is the kind you don’t need. That doesn’t mean you don’t get it, especially if it’s a requirement. However, even if you do have it you need to act like you don’t. Assuming that there’s a safety net to catch you isn’t always the case when that net comes with conditions that could pull the rug out from under you. You need to know what your potential exposure could be and what could prevent you from collecting. You need to be prepared to put new mechanisms in place to protect your enterprise and have a plan for what exactly to do when things go wrong. That should be paramount even without the policy. If you have everything ready to go you won’t need to worry about what happens when disaster strikes.