May 22, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Don't Base Your Design on Vendor Marketing

Remember how Arista promoted VXLAN coupled with deep buffer switches as the perfect DCI solution a few years ago? Someone took Arista’s marketing too literally, ran with the idea and combined VXLAN-based DCI with traditional MLAG+STP data center fabric.

While I love that they wrote a blog post documenting their experience (if only more people would do that), it doesn’t change the fact that the design contains the worst of both worlds.

Here are just a few things that went wrong:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 22, 2019 06:10 AM

May 21, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Data Deduplication in Network Automation Data Models

One of the toughest challenges in the hands-on part of Building Network Automation Solutions online course is the create a data model describing your service exercise.

Networking engineers never had to think about data models describing their networks or services, and the first attempt often results in something that looks like simplified device configuration in YAML or JSON format.

I wrote a long article describing how you can slowly redesign your box-focused data model into a network-focused one. The first parts describing the problem and initial deduplication are already online.

by Ivan Pepelnjak (noreply@blogger.com) at May 21, 2019 06:17 AM

May 20, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Microsoft Azure Networking Slide Deck Is Ready

After a few weeks of venting my frustrations on Twitter I finally completed Microsoft Azure Networking slide deck last week and published the related demos on GitHub.

I will use the slide deck in a day-long workshop in Zurich (Switzerland) on June 12th and run a series of live webinar sessions in autumn. If you’re a (paid) subscriber you can already download the slides and it would be great if you’d have time to attend the Zurich workshop – it’s infinitely better to discuss interesting challenges face-to-face than to type questions in a virtual classroom.

by Ivan Pepelnjak (noreply@blogger.com) at May 20, 2019 06:23 AM

XKCD Comics

May 17, 2019

The Networking Nerd

You Don’t Want To Be A Rock Star

When I say “rock star”, you probably have all kinds of images that pop up in your head. Private planes, penthouse suites, grand stages, and wheelbarrows full of money are probably on that list somewhere. Maybe you’re a purist and you think of someone dedicated to the craft of entertaining the masses and trying to claw their way to fame one note at a time. But I’m also sure in both of those cases you also think about the negative aspects of being a rock star. Like ego. And lack of humility. I want to touch on some of that as it pertains to our jobs and our involvement in the community.

Great Like Elvis. Without The Tassels.

The rock star mentality at work is easy to come by. Perhaps you’re very good at what you do. You may even be the best at your company or even at the collection of companies that are your competitors. You’re the best senior architect there is. You know the products and the protocols and you can implement a complex project with your eyes closed. That’s how people start looking at you. Larger than life. The best. One of a kind.

And that should be the end of it, right? That person is the best and that’s that. Unless you start believing their words more than you should. Unless you think that you really are the best and that there is no one better than you. It’s a mentality I see all the time, especially in sports or in places with small sample sizes. A kid that knows how to pitch a baseball well in the 8th grade thinks he’s the king of the baseball diamond. Until he sees someone that pitches way better than he does or he gets to high school and realizes he’s just the average of everyone else around him.

IT creates rock stars because we have knowledge that no one else does. We also fix issues for users, which creates visibility. No one talks about how accountants or HR reps are rock stars. Even though they have knowledge or solve problems for their users. It’s because IT is so practical. Anyone can do math, right? Or fill out a form? IT is hard. You have to know computer stuff. You have to learn acronyms. It’s like being a doctor or a lawyer. And both of those groups produce their own rock stars. So too does IT. And it causes the exact same issues that it does in the medical or legal fields.

Rock stars know it all. They don’t want to listen because they’ve got this. They can figure this out and they don’t need you telling them what to do. Why call support? I’ll just look up the problem. Go do something else and stop bothering them because they’re not going to fail here. This is what they do. Any of that sound familiar? If you’re on the team with a rock star it probably does.

Trade This Life For Fortune And Fame

The rock star mentality extends into the wider community too. People get vaulted into high esteem for their contributions. They get recognized for what they do and held up as an example for others. For most that are thrust into that rarified air of community fame that’s the end of it. But some take it as an invitation to take more.

You’ve seen them. The prima donnas. The people that take the inch of fame they’ve been given and stretch it into a mile. The people who try to manipulate and cajole the rest of their fellows into outlandish things for no other reason than they can do it. Again, if you’ve ever been around people like this in a community you know how toxic and terrible it can be.

So how do you combat that? How can you keep rock stars from getting an ego the size of Alaska? How do you prevent someone from getting an attitude and poisoning a community? How do you keep things together and on-track?

Sadly, the answer doesn’t lie much in preventing the rock star behavior in the first place. Because it’s going to happen no matter what you do. People that do good things are going to be held above others. It’s the nature of recognition to want to reward people’s outstanding behavior and showcase the attributes and traits that they want to see in others. And that can often cause people to take those traits and run with them or assume that you want to showcase all of their traits, even the bad ones.

Cut My Hair and Change My Name

The key that I’ve found most successful in my time working with communities is to highlight those traits and refer them back to the collective to remind the person they are part of a greater whole. If you praise someone for organizing an event, tell them, “Thank you for giving the community a place to meet and talk.” You’re still holding them up for doing a good job, but you’re referencing the community. For the workplace rock stars, try something like “Thanks for working all night to ensure that the entire office had email service this morning.” It reinforces that Herculean tasks like that have a real payoff but that the work is still referenced to a greater whole and not just the ego of someone working to prove a point.

You have to positively identify the traits you like and tie them to greater success in order to select them out and prevent someone from highlighting negative traits that could be detrimental. It’s easy for some that’s good at organization to take it too far and start running everything for a community without being asked. It’s also likely that someone that has a wealth of knowledge at their fingertips could start interjecting into conversations without permission because they think they know the answer. But if you reinforce the value of those traits to the community you’ll make the members think more carefully about their contributions as they exercise them.


Tom’s Take

I’m no expert on community building. Or rock stars for that matter. I’m just a person that does what I can to help others succeed. And I think that’s the mark of a real servant leader and perfect community mentor. The rock star mentality is the polar opposite of this. Rock stars want personal fame at the expense of the group. Servant leaders want group success even if it means not being recognized. Some of the best people in the community I know prefer to hide in the background and avoid the “fame” of being recognized. We would do well to follow their examples when the time comes for us to step on stage.

by networkingnerd at May 17, 2019 02:17 PM

ipSpace.net Blog (Ivan Pepelnjak)

Programmable Packet Forwarding Pipelines Using P4 on Software Gone Wild

Every time a new simple programming language is invented, we go through the same predictable cycle:

  • Tons of hype;
  • Unbounded enthusiasm when people who never worked in target environment realize they could get something simple done in a short time;
  • Ever-worsening headaches as the enthusiasts try to get a real job done with the shiny new tool;
  • Disappointment;
  • A more powerful language is invented to replace the old one.

A few years ago we experienced the same cycle when OpenFlow was the-one-tool-to-bind-them all.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 17, 2019 05:04 AM

XKCD Comics
Potaroo blog

Expanding the DNS Root: Hyperlocal vs NSEC Caching

The root zone of the DNS has been the focal point of many DNS conversations for decades. One set of conversations, which is a major preoccupation of ICANN meetings, concerns what labels are contained in the root zone. A separate set of conversations concern how this root zone is served in the context of the DNS resolution protocol. In this article I'd like to look at the second topic, and, in particular, look at two proposals to augment the way the root zone is served to the DNS.

May 17, 2019 12:00 AM

More DOH

DOH is not going away. It seems that the previous article on DOH has generated some reaction, and also there is some further development that should be reported, all of which I'll cover here.

May 17, 2019 12:00 AM

May 16, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Stop the Low-Level Configuration Manipulation

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

Imagine a small bank deciding in their infinite wisdom (in reality: because their CIO attended a conference organized by a database vendor) to implement their banking software by teaching bank tellers how to type SQL transactions by hand.

For example, to transfer money from one account to another account, a bank teller could simply type:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 16, 2019 06:39 AM

May 15, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Bathwater and Hyperscalers

Russ White recently wrote an interesting blog post claiming how we should not ignore any particular technology just because it was invented by a hyperscaler illustrating his point with a half-dozen technologies that were first used by NASA.

However, there are “a few” details he glossed over:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 15, 2019 06:45 AM

XKCD Comics

May 14, 2019

Honest Networker

Honestnetworker reacting to “Senior Network Engineers” with two years in the business.

Honestnetworker reacting to

Honestnetworker reacting to “Senior Network Engineers” with two years in the business.

by ohseuch4aeji4xar at May 14, 2019 11:50 AM

ipSpace.net Blog (Ivan Pepelnjak)

Building Fabric Infrastructure for an OpenStack Private Cloud

An attendee in my Building Next-Generation Data Center online course was asked to deploy numerous relatively small OpenStack cloud instances and wanted select the optimum virtual networking technology. Not surprisingly, every $vendor had just the right answer, including Arista:

We’re considering moving from hypervisor-based overlays to ToR-based overlays using Arista’s CVX for approximately 2000 VLANs.

As I explained in Overlay Virtual Networking, Networking in Private and Public Clouds and Designing Private Cloud Infrastructure (plus several presentations) you have three options to implement virtual networking in private clouds:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 14, 2019 06:42 AM

May 13, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Automating Brownfield Environments (Using an 802.1x Example)

This is a guest blog post by Albert Siersema, senior network and cloud engineer at Mediacaster.nl. He’s always busy broadening his horizons and helping his customers in (re)designing and automating their infrastructure deployment and management.


This is the second post in a series focused primarily on brownfield automation principles using 802.1x deployments as an example (you might want to read part 1 first).

Before diving into the specifics of the next 802.1x automation phase, let’s take a step back and think about why we’re going through this effort. Automation is a wonderful tool, but it’s not a goal… and neither is 802.1x a goal - it’s just another tool that can help us realize business benefits like:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 13, 2019 06:39 AM

XKCD Comics

May 11, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Nothing Fails Like Success

I hope I'm still allowed to quote a paragraph from someone else's article (thank you, EU, you did a great job). Here's what Jeffrey Zeldman wrote about startup business models:

A family buys a house they can’t afford. They can’t make their monthly mortgage payments, so they borrow money from the Mob. Now they’re in debt to the bank and the Mob, live in fear of losing their home, and must do whatever their creditors tell them to do.

Read the article and think about how it applies to unicorn-based networking technologies ;)

by Ivan Pepelnjak (noreply@blogger.com) at May 11, 2019 06:19 AM

May 10, 2019

The Networking Nerd

IT And The Exception Mentality

If you work in IT, you probably have a lot in common with other IT people. You work long hours. You have the attitude that every problem can be fixed. You understand technology well enough to know how processes and systems work. It’s fairly common in our line of work because the best IT people tend to think logically and want to solve issues. But there’s something else that I see a lot in IT people. We tend to focus on the exceptions to the rules.

Odd Thing Out

A perfectly good example of this is automation. We’ve slowly been building toward a future when software and scripting does the menial work of network administration and engineering. We’ve invested dollars and hours into making interfaces into systems that allow us to repeat tasks over and over again without intervention. We see it in other areas, like paperwork processing and auto manufacturing. There are those in IT, especially in networking, that resist that change.

If you pin them down on it, sometimes the answers are cut and dried. Loss of job, immaturity of software, and even unfamiliarity with programming are common replies. However, I’ve also heard a more common response growing from people: What happens when the automation screws up? What happens when a system accidentally upgrades things when it shouldn’t? Or a system disappears because it was left out of the scripts?

The exception position is a very interesting one to me. In part, it stems from the fact that IT people are problem solvers. This is especially true if you’ve ever worked in support or troubleshooting. You only see things that don’t work correctly. Whether it’s software misconfiguration, hardware failure, or cosmic rays, there is always something that is acting screwy and it’s your job to fix it. So the systems that you see on a regular basis aren’t working right. They aren’t following the perfect order that they should be. Those issues are the exceptions.

And when you take someone that sees the exceptions all day long and tries to fix them, you start looking for the exceptions everywhere in everything. Instead of wondering how a queue moves properly at the grocery store you instead start looking at why people aren’t putting things on the conveyor belt properly. You start asking whey someone brought 17 items into the 15-items-or-less line. You see all the problems. And you start trying to solve the issues instead of letting the process work.

Let’s step back to our automation example. What happens when you put the wrong upgrade image on a device? Was there a control in place to prevent you from doing that? Did you go around it because you didn’t think it was the right way to do something? I’ve heard stories of the upgrade process not validating images because they couldn’t handle the errors if the image didn’t match the platform. So the process relies on a person to validate the image is correct in the first place. And that much human interaction in a system will still cause issues. Because people make mistakes.

Outlook on Failure

But whether or not a script is going to make an error doesn’t affect the way we look at them and worry. For IT people that are too focused on the details, the errors are the important part. They tend to forget the process. They don’t see the 99% of devices that were properly upgraded by the program. Instead, they only focus on the 1% that weren’t. They’re only interested in being proved right by their suspicions. Because they only see failed systems they need the validation that something didn’t go right.

This isn’t to say that focusing on the details is a bad thing. It’s almost necessary for a troubleshooter. You can’t figure out where a process breaks if you don’t understand every piece of it. But IT people need to understand the big picture too. We’re not automating a process because we want to create exceptions. We’re doing it because we want to reduce stress and prevent common errors. That doesn’t mean that all errors are going to go away overnight. But it does mean that we can prevent common ones from occurring.

That also means that the need for expert IT people to handle the exceptions is even more important. Because if we can handle the easy problems, like VLAN typos or putting in the wrong subnet range, you can better believe that the real problems are going to take a really smart person to figure out! That means the real value of an expert troubleshooter is using the details to figure out this exception. So instead of worrying about why something might go wrong, you can instead turn your attention to figuring out this new puzzle.


Tom’s Take

I know how hard it is to avoid focusing on exceptions because I’m one of the people that is constantly looking for them. What happens if this redistribution crashes everything? What happens if this switch isn’t ready for the upgrade? What happens if this one iPad can’t connect to the wireless. But I realize that the Brave New World of IT automation needs people that can focus on the exceptions. However, we need to focus on them after they happen instead of worrying about them before they occur.

by networkingnerd at May 10, 2019 02:13 PM

ipSpace.net Blog (Ivan Pepelnjak)

Feedback: Data Center Interconnects

Got this feedback from a networking engineer watching the Data Center Interconnects webinar:

This webinar is an excellent overview regarding current DCI design challenges. I would highly recommend to watch it for anyone working in the networking and datacenter space. Sober networkers should watch it thoughtfully at least two times. L2 DCI fans should watch it once in a month, until reaching a solid grasp.

If only life would be as easy as that ;) Most people prefer to be blissfully ignorant of the infrastructure supporting their business, while at the same time pretending they know an awful lot about other people's jobs (see also: Dunning-Kruger effect)

by Ivan Pepelnjak (noreply@blogger.com) at May 10, 2019 06:54 AM

XKCD Comics

May 09, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Automation Should Prevent Operator Errors

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of the toughest tasks faced by networking engineers attending our Building Network Automation Solutions course is designing a data model describing network infrastructure or services. They usually think in terms of individual devices (nodes) resulting in tons of duplicated data.

I always point that out when reviewing their solutions and suggest how to minimize or eliminate duplicate data. Not surprisingly, doing that is hard, and one of the attendees started wondering whether the extra effort makes sense:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 09, 2019 06:36 AM

May 08, 2019

Honest Networker

Zayo AS6461 Getting directions from the new owners

Zayo AS6461 Getting news from the new ownership.

Zayo AS6461 Getting directions from the new owners

EQT, Digital Colony to Buy Zayo

<iframe title="“EQT, Digital Colony to Buy Zayo” — Telecom Ramblings" class="wp-embedded-content" sandbox="allow-scripts" security="restricted" style="position: absolute; clip: rect(1px, 1px, 1px, 1px);" src="https://www.telecomramblings.com/2019/05/eqt-digital-colony-buy-zayo/embed/#?secret=ffdF0wEQdk" data-secret="ffdF0wEQdk" width="600" height="338" frameborder="0" marginwidth="0" marginheight="0" scrolling="no"></iframe>

by ohseuch4aeji4xar at May 08, 2019 09:53 PM

ipSpace.net Blog (Ivan Pepelnjak)

Real-Life Data Center Meltdown

A good friend of mine who prefers to stay A. Nonymous for obvious reasons sent me his “how I lost my data center to a broadcast storm” story. Enjoy!


Small-ish data center with several hundred racks. Row of racks supported by an end-of-row stack. Each stack with 2 x L2 EtherChannels, one EC to each of 2 core switches. The inter-switch link details don’t matter other than to highlight “sprawling L2 domains."

VLAN pruning was used to limit L2 scope, but a few VLANs went everywhere, including the management VLAN.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 08, 2019 05:43 AM

Building Automation Device Inventory with Open Source Tools

This blog post was initially sent to subscribers of my SDN and Network Automation mailing list. Subscribe here.

One of the common questions we get in the Building Network Automation Solutions online course is “how do I create device inventory if I don’t know (exactly) what devices are in my network?”… prompting one of the guest speakers to reply “could it really be that bad?” (yes, sometimes it is).

Some of the students tried to solve the challenge with Ansible. While that might eventually work (given enough effort), Ansible definitely isn’t the right tool for the job.

What you need to get the job done is a proper toolchain:

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 08, 2019 05:27 AM

Ethan Banks on Technology

The Mythical Eight Hour Workday

I haven’t tracked my time in many years. I’ve always felt the practice was a nuisance. Hey, I’m busy. I have a lot to do. I’m working on it. Don’t distract me with a time sheet. You know what I do, boss, right? Do I really have to document my daily doings?

Working for myself means I don’t have to perform such trivial tasks, and of course, I don’t. However, I have been wondering over the last month where my workday goes. Often, it feels like I park my tush in my office chair, begin working on tasks, and then the day is suddenly over.

Except that often, the day isn’t over. My workday ends when I’ve accomplished everything I need to for that day. Eight hours gone by? Whatever. Head down. Keep at it. Get everything done. The list won’t get shorter tomorrow. If I want to get paid, I have to get my work done.

The Final Countdown

With more days than I want falling into a pattern of working more hours than I’d like, I’ve gotten serious about determining what the problem is. Do I need to turn away projects? Should I hire someone to handle some of the load? Am I not embracing the life of a stereotypical small business owner?

Or is this just a matter of being inefficient?

I’ve tried something simple to sort out where the time is going, and it’s not a time sheet, as I don’t like seizures. Instead, I’m using a countdown timer.

When I sit down in the morning, I start the eight hour timer counting down. The goal? Complete everything I need to on a given day in eight hours or less. Why eight hours? Why not? That’s a standard number of daily working hours for many folks, so it feels like the right place to start.

Observations

1. Eight hours feels like less time than it is as soon as the countdown timer rolls over to 7:59:59. Similarly, 5:45:00 left on the timer (mid-morning), feels like a distressingly short amount of time to get things done.

A sense of urgency rises up. Instead of feeling like I have many hours ahead of me to get things done, I feel like time is slipping away from me, so I’d best get a move on.

The countdown timer doesn’t stop, slow, or negotiate. The timer inexorably marches on. A countdown timer is an impactful visual aid that a normal wall clock, even with a second hand sweep, somehow lacks.

2. With the sense of urgency comes focus. Unnecessary busy tasks that usually seem work-related instead feel like they are stealing my day when I see the clock ticking down.

For instance, reading that interesting article I spotted on LinkedIn. Oh…and checking LinkedIn in the first place. Checking a spreadsheet I don’t really need to check to review some stat I really don’t need to review. Getting sidetracked in a Slack conversation. Etc.

3. I have discovered that I waste time by putting off distasteful tasks. A distasteful task I don’t want to do just sits there on my list, and I make myself unproductively busy with other things to avoid it. The entire time I am unproductively busy, I make no progress on my task list.

By putting off the inevitable, I anchor myself to my desk. I’m like a little kid whose Mom insists I eat my veggies, but I push cold peas around the dinner plate instead of pushing them into my mouth to get it over with. I can’t go outside and play. I’m stuck at the dinner table.

Procrastination prolongs the work day.

4. Here’s where it gets weird–or maybe obvious. The more I ponder the following point, the more obvious it seems. With fear of the countdown timer driving my day, I am sometimes finishing daily tasks before eight hours is up.

Instead of not getting done as much as I wanted to and working additional time to complete my tasks, I’ve created more desirable options. I can get some exercise. I can work ahead on tasks due later in the week. I can consider other projects I might want to take on. I can research something new.

Admittedly, not every day is a successful time management experience. But when it is, I feel like I’ve created more time.

Illusions

A wise man once said, “Time is an illusion. Lunchtime doubly so.” My experiment with the countdown timer has made me realize that eight hours is a time span I’ve been trapped in because decades of traditional work environments ingrained the habit. Eight hours is an illusion.

There’s nothing magical about eight hours. If I’m diligent, I can sometimes complete my necessary tasks in less than eight hours and make better use of the remaining time. I work for myself, so I have the luxury of choosing to do more work, or to do something else entirely that I believe will enrich my life.

I’m in my 40’s. Time has become more important to me, since I’ve likely used up about half of what statistics suggest I’m allotted. Morbid? A little, but let’s be practical. Life is too short to be wasting time. A sense of urgency is appropriate. I want to spend my time well.

Sometimes, time well-spent will be eight hours of work. But often, time well-spent can be something else.

by Ethan Banks at May 08, 2019 03:42 AM

XKCD Comics

May 07, 2019

My Etherealmind

May 06, 2019

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Now Boarding: Autumn 2019 Network Automation Online Course

Ladies and gentlemen, our Autumn 2019 Building Network Automation Solutions online course is now ready for boarding. Please make sure you have your boarding passes ready, board at your convenience, and start enjoying the pre-flight perks like over hundred hours of self-study materials.

Our flight will depart on September 3rd with subsequent sessions on September 26th, October 24th and November 12th. The guest speakers will focus on security, inventory managements, and describe their production deployments. More in a few days…

The only thing you have to do at this moment is to register (if you want to get the Enthusiast price… otherwise please feel free to wait ;)

And just in case you’re wondering: yes, I was sitting at an airport while writing this blog post ;))

by Ivan Pepelnjak (noreply@blogger.com) at May 06, 2019 06:21 AM

XKCD Comics

May 04, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Top Ten Things Executives Should Know About Software

Tom Limoncelly wrote another must-read ACM Queue article: Top Ten Things Executives Should Know About Software. If only someone as eloquent as Tom would write a networking equivalent...

by Ivan Pepelnjak (noreply@blogger.com) at May 04, 2019 06:15 AM

May 03, 2019

The Networking Nerd

Cisco’s Catalyst for Change

You’ve probably heard by now of the big launch of Cisco’s new 802.11ax (neé Wi-Fi 6) portfolio of devices. Cisco did a special roundtable with a group of influencers from the community called Just The Tech. Here’s a video from that event covering the APs that were released, the 9120:

<iframe allowfullscreen="true" class="youtube-player" height="329" src="https://www.youtube.com/embed/DWNbNtugwLo?version=3&amp;rel=1&amp;fs=1&amp;autohide=2&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;wmode=transparent" style="border:0;" type="text/html" width="584"></iframe>

Fred always does a great job of explaining the technical bits behind the APs. But one thing that caught my eye here is the name of the AP – Catalyst. Cisco has been using Aironet for their AP line since they purchased Aironet Wireless Communications back in 1999. The name was practically synonymous with wireless technologies for many people in the industry that worked exclusively with Cisco technologies.

So, is the name change something we should be concerned about?

A Rose Is a Rose Is An AP

Cisco moving toward a unified naming convention for their edge solutions makes a lot of sense. Ten years ago, wireless was still primarily 802.11g-based with 802.11n still a few months away from being proposed and ratified. Connectivity hadn’t quite yet reached the ubiquitous levels of wireless that we see today. The iPhone was only about to be on its third revision.

Cisco Catalyst devices were still the primary method of getting users connected to the network. Even laptop users hunted for Ethernet ports everywhere instead of just connecting to wireless. Ethernet was more reliable and faster than 54Mbps (at best) and fighting contention with all the other devices around. Catalyst stood for reliability.

In the time since, wireless has become the new edge device connectivity. No longer do we hunt for Ethernet ports unless we have a specific need for one. Laptops don’t come with dedicated wired networking options any longer. In 2019, wireless is king. And Aironet is the wireless name that Cisco has built. So why the change?

In short, because edge connectivity isn’t wired versus wireless any longer. Instead, it’s unified. Whether it was because of the idiotic decisions made by Gartner to required wired switching for their wireless Magic Quadrant (TM) or because people stopped thinking about Ethernet except to power wireless access points, the fact is that the edge no longer has wires. For Cisco, this means that Catalyst switches aren’t the edge any longer. So the name doesn’t have the same power as it once did.

However, the Aironet name has also lost its luster. Why? Because Aironet is a remnant of Cisco’s pre-controller AP past. The line of APs that most people are likely using in their office right now aren’t from the Aironet heritage. Instead, they are based on technology acquired by Cisco from Airespace that Cisco bought in 2005 to add controller-based technology to their portfolio. And, aside from references to Airespace in the code of the Wireless LAN Controllers (WLC), the line never really had a brand like Catalyst or Aironet.

Today, Cisco has started the move away from using Airespace technology in their controllers. As this video from 2018 shows, Cisco has begun to migrate their controller OS to a more modern platform instead of relying on modifying the old Airespace code again and again. This means that development going forward should be more rapid and less resultant on the whims of keeping everything running properly on a codebase over a decade old.

Branding New

So, that explains the reasons why Cisco might want to refresh everything. But why the naming of the APs? Why not just rely on Aironet and keep that branding going forward?

Well, because they want to make end users believe that the network is the same no matter if it’s wired or wireless. They want buyers to believe that Catalyst stands for edge connectivity, no matter where that edge might be. And, unless they really screw up and start making us think these new APs are switches they’ll be able to pull off this branding exercise fairly well.

That’s because users have stopped caring about the wired versus wireless debate. Instead, they only care about speed and reliability. 802.11ax will help on both fronts, and Cisco wants to capitalize on that by making these new APs feel different. And the best way to do that is by rebranding them.

Wireless professionals don’t care about the name. Most of the time they just refer to the model number anyway. And while Cisco’s model numbering strategies seem to be getting a bit crowded in the 9000-level of things, this makes a lot of sense to distance themselves from their past. The old 802.11ac APs are still very viable and will likely be useful all they way until the end of their life. But when the time comes to pull them out, you’ll be retiring Aironet and Airespace along with them. Even if you didn’t realize those were the branding names of those APs.


Tom’s Take

Branding matters. Or it doesn’t. Either you love the name of the thing you’ve been using or you couldn’t care less. Whether it’s an iPhone or a car or an access point, everything has a name and a number attached to it. Cisco has decided, for better or worse, to unify the edge under the Catalyst name. Maybe it will stick and reduce confusion with customers. Maybe it will be hated enough that they’ll bring back the Aironet name in a couple of cycles to “get back to basics” as it were. But for now, the catalyst for change at Cisco leads to a unified edge solution.

by networkingnerd at May 03, 2019 04:32 PM

My Etherealmind
XKCD Comics

May 02, 2019

Honest Networker

Trying to fit all your packet actions & QoS mappings onto a fixed pipeline Jericho ASIC

58729722_366909353921184_9199554364434284544_n

Trying to fit all your packet actions & QoS mappings onto a fixed pipeline Jericho ASIC

by ohseuch4aeji4xar at May 02, 2019 11:17 AM

Networking Now (Juniper Blog)

World Password Day: We Need to Talk

Passwords are the foundation upon which much of modern IT security is built, and what better day to discuss the topic than World Password Day, an event which occurs on the first Thursday of May every year. World Password Day is a day in which companies around the world post blogs with advice, sometimes questionable, the obligatory XKCD comic and talk about the importance of Multi-Factor Authentication (MFA). At Juniper Networks, we thought instead we'd have "the talk" about the foundation of password protection as a foundation of security itself.

by Trevor_Pott at May 02, 2019 10:45 AM

ipSpace.net Blog (Ivan Pepelnjak)

Automation Solution: Find Source of STP Topology Changes

Topology changes are a bane of large STP-based networks, and when they become a serious challenge you could probably use a tool that could track down what’s causing them.

I’m sure there’s a network management tool out there that can do just that (please write a comment if you know one); Eder Gernot decided to write his own while working on a hands-on assignment in the Building Network Automation Solutions online course. Like most course attendees he published the code on GitHub and might appreciate pull requests ;)

Wonder what else course attendees created in the past? Here’s a small sample.

by Ivan Pepelnjak (noreply@blogger.com) at May 02, 2019 06:24 AM

May 01, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Commentary: We’re stuck with 40 years old technology

One of my readers sent me this email after reading my Loop Avoidance in VXLAN Networks blog post:

Not much has changed really! It’s still a flood/learn bridged network, at least in parts. We count 2019 and talk a lot about “fabrics” but have 1980’s networks still.

The networking fundamentals haven’t changed in the last 40 years. We still use IP (sometimes with larger addresses and augmentations that make it harder to use and more vulnerable), stream-based transport protocol on top of that, leak addresses up and down the protocol stack, and rely on technology that was designed to run on 500 meters of thick yellow cable.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at May 01, 2019 07:32 AM

XKCD Comics

April 30, 2019

My Etherealmind
ShortestPathFirst

Interview with John Kindervag, the Godfather of Zero Trust Networking

Last month, I had the pleasure of spending a few minutes with John Kindervag, the industry-described “Godfather” and thought leader behind Zero Trust Networking. John developed these concepts during his tenure as Vice President and Principal Analyst at Forrester Research. Zero Trust, rooted in the principle of “never trust, always verify,” is primarily designed to …

by Stefan Fouant at April 30, 2019 05:25 PM

April 29, 2019

XKCD Comics

April 26, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Must Watch: History of Cisco IOS CLI

My first Cisco router was a blade for a Cabletron modular hub (anyone remembers what hubs were or a company named Cabletron?). We plugged it in, I read the documentation, figured out I had to type conf t and was faced with a blinking cursor staring back at me from an empty line.

A few years later I was invited to beta test Cisco software release 9.21 (it wasn’t called IOS yet). The best feature it had was the awesome configuration CLI with context-sensitive prompts and on-demand help.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at April 26, 2019 06:43 AM

The Networking Nerd

Increasing Entropy with Crypto4A

Have you ever thought about the increasing disorder in your life? Sure, it may seem like things are constantly getting crazier every time you turn around, but did you know that entropy is always increasing in the universe? It’s a Law of Thermodynamics!

The idea that organized systems want to fall into disorder isn’t too strange when you think about it. Maintaining order takes a lot of effort and disorder is pretty easy to accomplish by just giving up. Anyone with a teenager knows that the amount of disorder that can be accomplished in a bedroom is pretty impressive.

One place where we don’t actually see a lot of disorder is in the computing realm. Computers are based on the idea that there is order and rationality in everything that we do. This is so prevalent that finding a way to be random is actually pretty hard. Computer programmers have tried a number of ways to come up with random number generators that take a variety of inputs into the formula and come up with something that looks sufficiently random. For most people just wanting the system to guess a number between 1 and 100 it’s not too bad. But when it comes to really, really large numbers like the ones used in cryptography, those pseudorandom numbers aren’t good enough.

This All Looks So Familiar…

One of the reasons for this comes down to good old fashioned efficiency. In the old days computers programmers could rely on people to generate pseudorandom input. By sampling mouse clicks or delay between computer keyboard keystrokes you could easily come up with a number that looks nice and random. However, we’ve taken people out of the loop now. Thanks to the cloud and automation and any one of a number of new ways to reduce human input we’ve managed to remove mouse clicks and keystrokes.

That’s fine for running scripts and programs. It’s even good for building things at a huge scale. But it’s really bad when you need something that looks relatively random. And it’s really, really bad when your program relies on that randomness to keep you secure. Kind of like key generation in Public Key Cryptography (PKI).

A group of security researchers working for the National Institute of Standards and Technology (NIST) found out a few years ago that public keys were starting to collide at greater rates than random chance. The study, conducted in 2012, found that 5% of HTTPS and 10% of SSH public keys were duplicates. A collision in a hashing algorithm is when two inputs produce the same output, which renders that hashing function broken. In PKI, having a two different inputs output the same public key is really bad, because it could lead to key collisions that impact a variety of service.

What caused it? As it turns out, lack of orderly disorder. Because automation and non-human interaction have led to other pseudorandom inputs being used in key generation it appeared to the researchers that the same inputs were being used all over the place. That meant that a lot of the public keys that were being generated were being done in such as way as to make collisions more likely. When you look at how many things are relying on automated sources to generate keys it can be quite scary. Think about a smart lightbulb or other IoT device that’s trying to generate pseudorandom input from a CPU that’s just big enough to turn things on. Now imagine that CPU multiplied by the number of smart lightbulbs out there. Not a pleasant thought, is it?

Disorder In The Court

This fascinating discussion came from an interview I had with Bruno Couillard, the President and CTO of Crypto4A. Crypto4A is a company that provides Entropy-as-a-Service. What exactly does that mean?

Crypto4A has an appliance they call QAOS. QAOS is designed to give you the best possible disorder that you can get. It does this the old fashioned way. Instead of trying to use software as a Random Number Generator (RNG) QAOS instead uses hardware sources to generate entropy for their RNG. This includes a quantum RNG, which produces high quality disorder that’s difficult to fake any other way.

QAOS is designed to feed software with entropy to generate randomness sufficient to prevent PKI public key collisions. The software developers can follow the NIST guidelines on EaaS to have the program call an entropy source. QAOS, acting as that entropy source, will seed the RNG on the target system with good randomness and allow it to generate good keys. This could also be configured in the kernel of the OS to call a system like QAOS on boot and start the seed value with a good amount of random entropy in the case of old programs that can’t be modified to call anything other than a system-based RNG source like /dev/random/.


Tom’s Take

The NIST guidelines around EaaS are constantly evolving, but the idea that companies are already racing to fill the void that has been created by insufficient randomness in cryptography is telling. When you think about nth the number of devices that are going to be using PKI for secure communications, the need for something like Crypto4A QAOS is pretty clear. If we are going to rely on automated systems to run our daily lives, we need to have the resources in place to ensure they have a solid foundation of randomness to build on.

by networkingnerd at April 26, 2019 04:33 AM

XKCD Comics

April 25, 2019

ipSpace.net Blog (Ivan Pepelnjak)

Automation Solution: Create Switch Stack Reports

Have you ever wondered how many free ports you have on your stackable campus switches? I’m sure there must be a wonderful network management tool that creates that reports with a click of a button… but what if the tool your PHB purchased based on awesome PowerPoint and glitzy demo can’t do that?

Nadeem Lughmani decided to solve this challenge as a hands-on assignment in the Building Network Automation Solutions online course and created an Ansible playbook and a Python plugin that counts the total number of ports and number of free ports for each switch stack specified in the device inventory.

Wonder what else course attendees created in the past? Here’s a small sample.

by Ivan Pepelnjak (noreply@blogger.com) at April 25, 2019 06:41 AM

April 24, 2019

My Etherealmind

Insider Threats and Facebook’s Poor Password Management

Storing passwords in clear text is a bonanza for insider threats. Who knows what they got ?

The post Insider Threats and Facebook’s Poor Password Management appeared first on EtherealMind.

by Greg Ferro at April 24, 2019 06:17 PM

RSS and Medium blogs

Because RSS is best way to get information

The post RSS and Medium blogs appeared first on EtherealMind.

by Greg Ferro at April 24, 2019 01:46 PM

IPEngineer.net

IaC – unit tests with jSNAPy and Ansible

JSNAPY is an open source tool released by Juniper Networks circa 2015 that is the Python version of the Juniper Snapshot Administrator. This tool in the most simplest sense gives us the ability to have unit-tests when working with Junos, much in the same way a developer would write tests against their code. JSNAPy creates snapshots of a device’s operational or configurational state, the content of which depends on tests. JSNAPy then can diff and check these snapshots, which when combined with your test logic, means you can detect when things change or don’t change as per your desire. It’s a simple but effective tool when working with Junos. In fact, if you have another system to take the snapshot, JSNAPy is really an XML snippet checking tool and thus, it can be used for multi-vendored environments!!!

JSNAPy is a great tool for not only dealing with operational changes, but also also for steady state change operations too through the use of both

pre
and
post
tests and the logical operators JSNAPy supports. It’s worth mentioning you can call the snaps and tests anything you want. Bob and Alice are both valid examples of a snap name, but the advice here is to use meaningful naming.

All tests and configuration are written in YAML and are quite simple providing you spend five minutes to get acquainted with the keywords.

Here are the installation instructions in case you haven’t installed it yet: https://github.com/Juniper/jsnapy/wiki/1.-Installation

Just in case you didn’t know, JSNAPy can also be used in Ansible directly, the gains of which need to be said. Here is a link to an Ansible example to help shortcut the ramp-up time! https://github.com/arsonistgopher/Juniper5StepDemos/tree/master/Ansible

Here are the logical test operators supported by JSNAPy at the time of writing.

- Execute Tests Over Elements with Numeric or String Values
    1. all-same: Check if all content values for the specified element are the same. It can also be used to compare 
                 all content values against another specified element.
           - all-same: flap-count
             checks if all values of node <flap-count> in given Xpath is same or not.

    2. is-equal: Check if the value (integer or string) of the specified element matches a given value.
           - is-equal: admin-status, down
             check if value of node <admin-status> in given Xpath is down or not.  

    3. not-equal: Check if the value (integer or string) of the specified element does not match a given value.
           - not-equal: oper-status, down
             check that value of node <oper-status> should not be equal to down.  

    4. exists:  verifies the existence of an XML element in the snapshot.
           - exists: no-active-alarm 
             checks if node </no-active-alarm> is present or not  
 
    5. not-exists: verifies xml element should not be present in snapshot
           -not-exists: no-active-alarm 
            checks </no-active-alarm> node should not be present in snapshot.  

    6. contains: determines if an XML element string value contains the provided test-string value.
           - contains: //package-information/name[1], jbase
           checks if jbase is present in given node or not. 

    7. not-contains: determines if an XML element string value does not contain the provided test-string value.
           - not-contains: //output, sync_alarm
           checks if sync_alarm is present in given node or not.

 - Execute Tests Over Elements with Numeric Values
    1. is-gt: Check if the value of a specified element is greater than a given numeric value.
            - is-gt: cpu-total, 2
              checks value of <cpu-total> should be greater than 2  

    2. is-lt: Check if the value of a specified element is lesser than a given numeric value.
            - is-lt temperature, 55
              checks value of <temperature> is 55 or not.  

    3. in-range: Check if the value of a specified element is in the given numeric range.
            - in-range memory-buffer-utilization, 20, 70 
              check if value of <memory-buffer-utilization> is in range of 20, 70  

    4. not-range: Check if the value of a specified element is outside of a given numeric range.
              - not-range: memory-heap-utilization, 5 , 40
                checks if value of <memory-heap-utilization> is not in range of 5 to 40

 - Execute Tests Over Elements with String Values: 
    1. contains: determines if an XML element string value contains the provided test-string value.
           - contains: //package-information/name[1], jbase
             checks if jbase is present in given node or not.

    2. not-contains: determines if an XML element string value does not contain the provided test-string value.
           - not-contains: //output, sync_alarm
           checks if sync_alarm is present in given node or not.

    3. is-in: Check if the specified element string value is included in a given list of strings.
           - is-in: oper-status, down, up
             check if value of <oper-status> in is list (down, up)  

    4. not-in: Check if the specified element string value is NOT included in a given list of strings.
           - not-in :oper-status, down, up
             check if value of <oper-status> in not in list (down, up)

*Taken from https://github.com/Juniper/jsnapy/wiki*

JSNAPy is great for use in upgrade & update scenarios. The aim is to ‘finger print’ the pre change state and then take another fingerprint of the post state for comparison.

Junos Upgrade

You want to update Junos on a production device in the quickest and most reliable way possible. JSNAPy can be used to snapshot the state of interfaces, routing protocols and general health from both an operational and configuration perspective. Anywhere we can access XML data (everywhere on Junos), we can use JSNAPy to snapshot and run checks!

  1. Take

    pre
    snapshots of test hotspot areas, for example:
    -Number of routes in
    inet.0
    routing table
    -Number of interfaces in physical up state
    -Number of BGP peers in the established state

  2. Upgrade Junos

  3. Take new post snapshots after some settling1 time

  4. Run JSNAPy checks to ensure the

    post
    state is the same as the
    pre
    state

This is a pretty straight forward example and the

is-equal
test operator will suffice here. The trickiest thing will be to find the correct XML xpath statement with regards to pinning the data described in the short list.

Addition of an Interface

This one isn’t so straight forward as ensuring the pre state matches the post state and so examples are included! Also the pre test is being used as a collision check to make sure that the network attribute isn’t being used before we intend to use it! If you’re familiar with Junos, you’ll also understand that if an interface isn’t configured, you just won’t see it in the configuration XML. If it’s an SFP based line card or fixed-form device, chances are you also won’t see it in the operational XML if the SFP is missing. All the fun of the circus with this example and exactly why I chose to write about it.

The way to deal with JSNAPy in this scenario is based on the logic of XML elements missing for pre-tests and on the logic of XML elements being present and correct for the post checks.

First of all, we need device configuration files for JSNAPy which are here:

Pre configuration

# Pre-Test for basic automation
hosts:
  - device: demo01
    username: tf
    passwd: Passw0rd
tests:
  - ./tests/pre.yml

Post configuration

# Post-Test for basic automation
hosts:
  - device: demo01
    username: tf
    passwd: Passw0rd
tests:
  - ./tests/post.yml

Github link for pre config here
Github link for post config here

The workflow for the set of pre tests looks like below:
1. Check that interface

ge-0/0/42
isn’t configured
2. Check that
irb.42
isn’t configured
3. Check that the VLAN
DT
isn’t configured – DT for DeepThought, a large and beefy server that likes watching TV

We could take this further and ensure that the VLAN number isn’t in use, so let’s assume we have one source-of-truth and name/number is tightly coupled.
Also, we could add another test in the style of the existing ones if you’re paranoid!

Here are the actual pre tests. Note we iterate through the list of interfaces and check that all of them are not equal. Take the

test_phy
test as an example, here we check that each name of the interface in the interface list is NOT equal to
ge-0/0/42
. Simple but effective logic.

test_phy:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - iterate:
      id: ./name
      xpath: 'interfaces/interface'
      tests:
        - not-equal: name, ge-0/0/42
          info: "Interface does not exist"
          err: "-"

test_irb:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - iterate:
      id: ./name
      xpath: 'interfaces/interface[name="irb"]/unit'
      tests:
        - not-equal: name, 42
          info: "Interface does not exist"
          err: "-"

test_vlan:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/vlans
  - iterate:
      id: ./vlan
      xpath: 'vlans/vlan'
      tests:
        - not-equal: name, DT
          info: "VLAN does not exist"
          err: "-"

GitHub link for pre test here

The workflow for the post test is a little different to the pre. We’ll check for direct matches and do not iterate through the list.

  1. Check that interface
    ge-0/0/42
    exists
  2. Check that
    irb.42
    exists
  3. Check that VLAN
    DT
    exists

test_phy:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - item:
      id: ./name
      xpath: 'interfaces/interface[name="ge-0/0/42"]'
      tests:
        - is-equal: name, ge-0/0/42
          info: "Interface exists"
          err: "-"

test_irb:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/interfaces
  - item:
      id: ./name
      xpath: 'interfaces/interface[name="irb"]/unit[name="42"]'
      tests:
        - is-equal: name, 42
          info: "Interface exists"
          err: "-"

test_vlan:
  - rpc: get-config
  - kwargs:
      filter_xml: configuration/vlans
  - item:
      id: ./vlan
      xpath: 'vlans/vlan[name="DT"]'
      tests:
        - is-equal: name, DT
          info: "VLAN exists"
          err: "-"

GitHub link for post test here

Executing Tests

JSNAPy tests are super easy to run providing you have it installed and the credentials to the device under test are correct.

The below example shows running both the

pre
and
post
tests using the
--snapcheck
switch. This switch makes JSNAPy do a
snapshot
and also perform a check against the tests referenced by the
x.yml
file the command line call references.

JSNAPy --snapcheck pre -f pre.yml
JSNAPy --snapcheck post -f post.yml

Close

Whilst this post doesn’t serve as a full blown guide with install, it does deliver some “how-to” logic if you’re wondering about the tool.

Hopefully this post has proved to be a useful view into a use of JSNAPy and has delivered some value in payment for your time.

You may want to trigger these tests within a CI/CD pipeline as separate stages to really get the value out of the tool and tests. This way, tests that fail can prevent the pipeline from progressing any further in the case of pre tests and failed post tests can be used to trigger revert workflows.

Useful Links
– Matt Oswalt wrote about JSNAPy here.
– NRELabs has a JSNAPy lesson which means you can use it for free and extremely quickly in a browser session. That can be found here
https://github.com/Juniper/jsnapy/blob/master/README
https://github.com/Juniper/jsnapy/wiki/2.-Writing-test-and-config-file
https://github.com/Juniper/jsnapy/wiki/3.-Command-Line-Tool


  1. Settling time is required because of routing protocol activation and steady-state operational times etc.

The post IaC – unit tests with jSNAPy and Ansible appeared first on ipengineer.net.

by David Gee at April 24, 2019 12:47 PM

ipSpace.net Blog (Ivan Pepelnjak)

How Common Are Data Center Meltdowns?

We all know about catastrophic headline-generating failures like AWS East-1 region falling apart or a major provider being down for a day or two. Then there are failures known only to those who care, like losing a major exchange point. However, I’m becoming more and more certain that the known failures are not even the tip of the iceberg - they seem to be the climber at the iceberg summit.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at April 24, 2019 07:07 AM