September 23, 2020

My Etherealmind
The Networking Nerd

A Decade of Blogging

Today is a milestone for me. Ten years ago I picked up a virtual notepad for the first time and committed my first blog post to the ether. It’s been a wild ride ever since. It also marks the milestone of being the job that I’ve held the longest so far in my career.

Blogging has been a huge boon for me. I’ve become a better writer in the last decade. I’ve learned how to ask the right questions and get good material for a story instead of just putting out what someone wants me to say. I’ve learned that being a pseudo-journalist is a thing you can do and have fun with.

I’ve written a ton over the years. 751 posts, as a matter of fact (counting this one). I’ve always tried to hold myself to a standard of getting something out once a week. Aside from the few times when I’ve tried to push that to twice a week I’ve held up pretty well. Yeah, I’ve slipped and the day job has gotten in the way more than once. However, keeping myself to a strict schedule has ensured that my attention stays focused on this blog and that it doesn’t lapse into irrelevance any more than normal.

It’s also opened up a lot of doors for me. Blogging was how I got introduced to the Packet Pushers and raised my profile from “crazy nerd that writes” to “crazy nerd that is a podcast guest.” That got me involved with Tech Field Day and from there things went all the way to Mars. In fact, it was Tech Field Day that helped me understand the importance of writing and to rededicating myself to what I do. And to the job interviewer that considered my blogging to be a hobby, not unlike restoring cars or fishing, I think I can safely say it’s become way more than either of us could have imagined.

I’m still creating content all over the place. In addition to all the stuff I do for my day job at Tech Field Day, I write coverage from our events and the briefings I take at Gestalt IT. I have started making videos. I am part of a weekly podcast that covers IT news and lets me be a little snarky now and then. I’ve seen the shift of content moving from written words to spoken words to video and beyond. There’s no shortage of information being shared today, even if some of it is shared in formats that favor shorter attention spans.

What more is there to write about at this point? I go back and look at my early posts and laugh at how I originally wanted to get my thoughts down about structured troubleshooting. And then it morphed into CCIE studies. Then SDN. Or maybe engineering woes. All of it has been growth for me. I’ve learned how to argue and not assassinate character. I’ve seen how people can take different sides of the same argument. I’ve even seen how the things we have settled years before come back around for a new generation of networking pros to argue over again and again.

I love this place. It’s one of the reasons why I’m the only writer here. And trust me, the content mills are always emailing me to put up sponsored posts. But I keep turning them down because this is my place for my thoughts. I want those of you that still read along with me to enjoy what I think about something or know that what I’m saying isn’t a post that was compensated. Knowing where I’m coming from hopefully helps you all understand how the forces in the market and the community drive what we see, what we learn, and what we do with it all.


Tom’s Take

I’m glad I made it through my warm up period for blogging. The funny thing about writing is that you just keep getting better and better as you go along. Who I am hasn’t really changed. A few of the certifications are retired or expired. Twitter is still a thing that I do. But this is where I belong. It’s my home and my work and the place where I get to be me. I hope the next decade is as much fun and as meaningful for all of you as it has been for me!

by networkingnerd at September 23, 2020 04:13 PM

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Using Flow Tracking to Build Firewall Rulesets... and Halting Problem

Peter Welcher identified the biggest network security hurdle faced by most enterprise IT environments in his comment to Considerations for Host-based Firewalls (Part 1) blog post:

I have NEVER found a customer application team that can tell me all the servers they are using, their IP addresses, let alone the ports they use.

His proposed solution: use software like Tetration (or any other flow collecting tool) to figure out what’s really going on:

September 23, 2020 06:37 AM

XKCD Comics

September 22, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Accessing Docker Container Services over IPv6

Getting Docker to work with IPv6 is an interesting and under-documented (trying to stay diplomatic) adventure, but there’s a shortcut to the promised land: even if your Docker environment is pure IPv4 morass, you can still reach published container ports over IPv6 thanks to the userland proxy I described last week. The performance is obviously commensurate with traversing kernel-user boundary too many times.

New to this rabbit hole? Start here.

Finally, you don’t have to tell me (again) that Docker is dead and we should all use K8s. It’s as useful as telling me CloudStack is dead and we should all use OpenStack. Different challenges deserve different tools.

September 22, 2020 05:49 AM

September 21, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Vendor Marketectures in Real Life

Remember my rants about VMware and firewall vendors promoting crazy solutions that work best in PowerPoint and cause more headaches than anything else (excluding increased vendor margins and sales team bonuses, of course)?

Here’s another we-don’t-need-all-that-complexity real-life story coming from one of my long-term subscribers:

September 21, 2020 06:32 AM

XKCD Comics

September 20, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Interesting: PyEnv

If you’re like me, you’re probably sick-and-tired of Python versions, environments… Every time I update Python on my MacBook Pro with Homebrew, I lose all packages I installed for the previous version of Python (because I’m installing them system-wide and they’re stored in version-specific directory).

Jon Langemak found a potential solution to this problem: PyEnv. My first reaction was: Great, just what I need… but as he described how it really works, I realized that it’s always possible to add another layer of indirection. RFC1925 strikes again.

September 20, 2020 11:08 AM

September 19, 2020

ipSpace.net Blog (Ivan Pepelnjak)

MUST Read: Blockchain, the amazing solution for almost nothing

One of the weekend reads collected by Russ White contained a pointer to a hilarious description of blockchain - a solution in search of a problem. Here are a few quotes to get you started (and I had a really hard time selecting just a few):

I’ve never seen so much bloated bombast fall so flat on closer inspection.

At its core, blockchain is a glorified spreadsheet.

The only thing is that there’s a huge gap between promise and reality. It seems that blockchain sounds best in a PowerPoint slide.

Someone should use that article as a framework and replace blockchain with OpenFlow or SDN ;)

September 19, 2020 06:59 AM

The Networking Nerd

Solve the Simple Problems

One thing I’ve found out over the past decade of writing is that some problems are easy enough to solve that we sometimes forget about them. Maybe it’s something you encounter once in a great while. Perhaps it’s something that needed a little extra thought or a novel reconfiguration of an existing solution. Something so minor that you didn’t even think to write it down. Until you run into the problem again.

The truth behind most of these simple problems is that the solutions aren’t always apparent. Sure, you might be a genius when it comes to fixing the network or the storage array. Maybe you figured out how to install some new software to do a thing in a way that wasn’t intended. But did you write any of it down for later use? Did you make sure to record what you’ve done so someone else can use it for reference?

Part of the reason why I started blogging was to have those written solutions to problems I couldn’t find a quick answer to. What it became was way more than I had originally intended. But the posts that I write that still get the most attention aren’t my long think pieces on the state of the networking industry or multiplied engineers. It’s the simple solutions to questions or problems that keep driving traffic here day after day.

Look Around

A lot of my great posts come from me asking simple questions. How does BPDUGuard work on a switch? Why does the Apple Watch not unlock my MacBook? What is up with this SFP not working? When you ask the questions you have to figure out the answers. And that’s the hard and rewarding part of the puzzle.

I challenge you to go search out a simple problem. Say it’s an issue with data not being shared between two devices. The search results will almost always turn up a few pages that have a litany of solutions that are basic troubleshooting steps. Things like:

  • Ensure the devices are connected
  • Reset the network settings
  • Unpair and repair the devices
  • Restart everything
  • Call Tech Support

You’ve probably stumbled across these before. And the sad truth is that running down that laundry list of solutions will often fix issues, which is why they keep getting boosted back into the search results. But you know what’s missing? They why of the problem. It’s not enough to just toss things at a problem in the hope that it starts working again.You have to also figure out what went wrong and why it happened.

Networking people always want to know why something went wrong because we want to make sure it doesn’t happen again. Security people are even more stringent about figuring out the why behind a problem. They want to stop a potential breach or plug a hole that needs to be dealt with. So to them a solution is just a temporary fix until you can confirm that something won’t happen again.

This is why the work that writers do is so important. We explain the why behind problems. We figure out what caused something to go off the rails and then how to fix it so it doesn’t happen again. Those are the kinds of posts that get the most attention. Because they’re specific about the fix, enlightening about the education behind the problem, and most importantly aren’t just a laundry list of fixes to throw at something until it works.


Tom’s Take

If you’re someone out there that’s looking to start writing down your solutions to problems, you need to start with the questions behind what’s going on. It’s not enough to just regurgitate the fixes and hope that one of them has some kind of magic that works. You need to investigate, understand, and explain what’s going on. Once you can do that, you will have created something that gets lots of attention and will encourage you to keep up the questions for years to come.

 

by networkingnerd at September 19, 2020 03:33 AM

September 18, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Video: Cisco SD-WAN Routing Goodness

After covering the Cisco SD-WAN components and its architecture in the Cisco SD-WAN Foundations and Design Aspects webinar, David Penaloza focused on the routing capabilities it offers and its control plane characteristics, including types of routes and some scalability recommendations.

You need Free ipSpace.net Subscription to watch the video.

September 18, 2020 06:52 AM

XKCD Comics

September 17, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Are Business Needs Just Excuses for Vendor Shenanigans?

Every now and then I call someone’s baby ugly (or maybe it was their third cousin’s baby and they nonetheless feel offended). In such cases a common resort is to cite business or market needs to prove how ignorant and clueless I am. Here’s a sample LinkedIn comment talking about my ignorance about the need for smart NICs:

The rise of custom silicon by Presando [sic], Mellanox, Amazon, Intel and others confirms there is a real market need.

Now let’s get something straight: while there are good reasons to use tons of different things that might look inappropriate, irrelevant or plain stupid to an outsider, I don’t believe in real market need argument being used to justify anything without supporting technical facts (tell me why you need that stuff and prove to me that using it is the best way of solving a problem).

September 17, 2020 06:48 AM

September 16, 2020

Packet Pushers

Three Reasons Your Data Center Is Still Relevant In An Edge-Cloud World

This guest post is by John Gray, Sr. Product Marketing Manager for Data Center Networking at Aruba, a Hewlett Packard Enterprise company. We thank Aruba for being a sponsor. There is no doubt that the COVID-19 pandemic has impacted society in a myriad of ways, ranging from being a public health crisis to a stalled […]

The post Three Reasons Your Data Center Is Still Relevant In An Edge-Cloud World appeared first on Packet Pushers.

by Sponsored Blog Posts at September 16, 2020 07:43 PM

ipSpace.net Blog (Ivan Pepelnjak)

Why Don't We Have Dynamic Firewall Policies

One of the readers of the Considerations for Host-Based Firewalls blog post wrote this interesting comment:

Perhaps a paradigm shift is due for firewalls in general? I’m thinking quickly here but wondering if we perhaps just had a protocol by which a host could request upstream firewall(s) to open access inbound on their behalf dynamically, the hosts themselves would then automatically inform the security device what ports they need/want opened upstream.

Well, we have at least two protocols that could fit the bill: Universal Plug and Play and Port Control Protocol (RFC 6887).

September 16, 2020 06:20 AM

XKCD Comics

September 15, 2020

ipSpace.net Blog (Ivan Pepelnjak)

How Docker Uses iptables to Implement Published Ports

In early September I explained the difference between exposed and published Docker container ports.

Now let’s peek behind the curtain and explore how Docker uses iptables to publish container ports, and why it runs a userland proxy process for every published port.

For even more details, explore the Docker Networking Deep Dive webinar.

September 15, 2020 06:04 AM

September 14, 2020

SNOsoft Research Team

What You Need to Know About Penetration Testing Liability

Penetration tests are designed to identify potential gaps in an organization’s cybersecurity. With an effective penetration test comes a variety of different risks.  Before engaging a penetration test provider, it is essential to understand the risks of penetration tests, how to minimize them, and why a good penetration testing firm will not be able to accept liability for actions performed in good faith.

Pen Test Risk Reward

A Good Penetration Test Carries the Potential for Damages and/or Outages

Any reputable penetration testing firm will not provide a guarantee that their services are entirely safe.  Any provider that does so is likely either deceptive or using testing tools that are so ineffective as to be essentially worthless.

The reason why safety cannot be guaranteed is that many computing systems and programs are fairly unstable during normal operations.  How many times have you had Microsoft Office or Excel crash and cause data loss during normal use?  If these and other programs were completely reliable, Microsoft wouldn’t have bothered developing Autosave.

If these systems are so unstable during “normal” use, consider the expected impacts of the very unusual conditions that they will be subjected to during a pentesting engagement.  Penetration testing is designed to identify the bugs in software that an attacker would exploit as part of their attacks.  The best way to locate and determine the potential impact of these vulnerabilities is to use the same tools and techniques that a real attacker would.  This poking and prodding, while carried out with the best of intentions, falls outside the definition of “normal” use for this software.

While the probability that a penetration test will cause a significant failure or damage is less than 1%, it is still possible.  For this reason, when undergoing a penetration test designed to provide an accurate assessment of an organization’s systems and cyber risk, it is impossible for the testing provider to accept liability for outages and other damages caused by reasonable testing activities performed in good faith.

The Level of Risk Depends on the Services Provided

All penetration tests carry some risk of outages or other damages to the systems under test.  However, not all penetration tests are created equal, and different types of tests carry varying levels of risk.  Depending on the type of test performed, an organization may need to accept a higher level of risk and different types of risk.

Automated Tests are Higher Risk

One of the main determinants of risk in a penetration test is the type of penetration testing services provided.  Basic tests, which rely heavily upon automation, are much riskier than realistic threat penetration testing.

Some penetration test providers rely heavily upon automated tools such as scanners and exploitation frameworks to reduce the manual work required during a test.  While this may improve the speed, cost, and scalability of the test, it does so at the cost of significantly increased risk.  The scripted tests performed by these tools launch an attack if a system “appears” to be vulnerable without checking for strange or risky conditions.  This dramatically increases the probability that a system will experience a memory error or other issue that will cause the program to crash.

Realistic threat penetration testing, on the other hand, carries a lower level of risk because it realistically emulates what a skilled attacker would do when attempting to exploit the system.  Cybercriminals, when attacking a system, are trying not to be detected and use tools and techniques designed to minimize the probability that they will be detected before they achieve their objectives.  Testing driven by human talent, experience, and expertise is more likely to avoid potential damage and other outages and minimize risk than a penetration test more heavily reliant upon automation.

Basic Tests Carry Long-Term Risk

The risks associated with a penetration test are not limited to potential damages and outages.  A poorly-performed penetration test also carries the potential for long-term risks to an organization.

Companies commonly undergo penetration testing to fulfill regulatory requirements and often select the most basic test available in an attempt to “check the box” for compliance.  While these basic tests may earn a compliant rating, they do little to measure the organization’s true cybersecurity risk.

In the long term, this reliance upon basic tests carries significant cost to an organization.  Companies like Equifax, Target, Sony, Hannaford, and the Home Depot all were tested as compliant with applicable regulations yet suffered damaging data breaches.  In fact, the CEO of Target said, “Target was certified as meeting the standard for the payment card industry in September 2013. Nonetheless, we suffered a data breach.”

The ROI of good security is equal to the cost in damages of a single successful compromise.  You can add the cost of all of the security technologies and testing to the cost in damages as well because those things did not prevent the breach.

Is Your Vendor Delivering Genuine Penetration Testing Services?

Determining whether or not a penetration testing vendor is offering automated or manual testing services may seem difficult.  However, looking at how the provider calculates the cost of an assessment can be an easy way to accomplish this.

Any penetration testing provider will need to scope the size of the project before providing a quote.  The questions that they ask and actions performed during the scoping phase can help to determine the types of services that they provide.

Vendors that provide services dependent upon automation will ask questions like “how many IP addresses do you have?” or “how many pages is your application?”.  These questions are important to them since they determine the number of scans that they expect to perform.

However, these kinds of questions do not provide a realistic assessment of the complexity of the penetration testing engagement.  If a customer tells a vendor that they have 10 IP addresses and a web application with 10 pages the vendor might bill them $500.00 per IP and $1,000.00 per page totaling $15,000.00.  While that price sounds reasonable at face value, what happens if none of the 10 IP addresses hosts any connectable services?  In workload terms that is 0 man-hours.   Despite this the customer in our example would still pay $5,000.00 for 0 hours of work.  Does that sound reasonable?

The inverse is also true and is the exact reason why these types of vendors rely on automated scanning (rather than manual testing) for service delivery.  What happens if each of the 10 IP addresses requires 40 hours of work totaling 400 man-hours?  The cost would still be $5,000.00 as quoted which means that the vendor would need to work at an effective rate of $12.50 an hour!  Of course no vendor will work for that rate and so they compensate for the overage with automation but don’t tell their customer.

The same is true for web pages.  It is entirely possible to have 10 static web pages that cannot be attacked because they take no input.  It is also possible to have 10 web pages each of which takes significant input and could require even more than 40 hours to test per page.  So, as a general rule of thumb, companies looking for penetration testing services should avoid vendors that price based on the count of targets (IP addresses, pages, etc).  These vendors are generally the ones that deliver basic tests packaged as advanced tests.  They also face higher liability as was demonstrated when Trustwave was sued by banks for certifying Target.

Why a Penetration Testing Firm Can’t Accept Liability

A good penetration testing firm cannot accept liability for damages and outages caused by their services.  While a good, manual penetration test does everything that it can to minimize the potential for something to go wrong, unforeseen circumstances can cause unanticipated issues.

Some classic examples of penetration tests that went wrong in unexpected ways are the recent cases of Coalfire and Nissan.

In Coalfire’s case, penetration testers were hired to perform an assessment of the physical security of an Iowa courthouse building.  Due to a misunderstanding in the terms of the engagement, the penetration testers were arrested and faced felony charges when found testing the security of the courthouse after hours.

The Nissan case, on the other hand, is an example of a penetration test that was commissioned under false pretenses.  The VP of the company had the test performed without the knowledge of the CEO or key IT personnel.  The results of the test were used to gain access to the email account of the company chairman and access data used to bring charges against him for financial misconduct.

A penetration testing vendor cannot accept liability for potential damages caused by the test because some aspects are completely outside of their control.  This is why you shouldn’t be alarmed to see a release of liability statement in a penetration testing agreement and might have cause for concern if a vendor provides a contract that lacks such a clause.

<style type="text/css">.fusion-fullwidth.fusion-builder-row-1 a:not(.fusion-button):not(.fusion-builder-module-control):not(.fusion-social-network-icon):not(.fb-icon-element):not(.fusion-countdown-link):not(.fusion-rollover-link):not(.fusion-rollover-gallery):not(.fusion-button-bar):not(.add_to_cart_button):not(.show_details_button):not(.product_type_external):not(.fusion-quick-view):not(.fusion-rollover-title-link):not(.fusion-breadcrumb-link) , .fusion-fullwidth.fusion-builder-row-1 a:not(.fusion-button):not(.fusion-builder-module-control):not(.fusion-social-network-icon):not(.fb-icon-element):not(.fusion-countdown-link):not(.fusion-rollover-link):not(.fusion-rollover-gallery):not(.fusion-button-bar):not(.add_to_cart_button):not(.show_details_button):not(.product_type_external):not(.fusion-quick-view):not(.fusion-rollover-title-link):not(.fusion-breadcrumb-link):before, .fusion-fullwidth.fusion-builder-row-1 a:not(.fusion-button):not(.fusion-builder-module-control):not(.fusion-social-network-icon):not(.fb-icon-element):not(.fusion-countdown-link):not(.fusion-rollover-link):not(.fusion-rollover-gallery):not(.fusion-button-bar):not(.add_to_cart_button):not(.show_details_button):not(.product_type_external):not(.fusion-quick-view):not(.fusion-rollover-title-link):not(.fusion-breadcrumb-link):after {color: #f2b310;}.fusion-fullwidth.fusion-builder-row-1 a:not(.fusion-button):not(.fusion-builder-module-control):not(.fusion-social-network-icon):not(.fb-icon-element):not(.fusion-countdown-link):not(.fusion-rollover-link):not(.fusion-rollover-gallery):not(.fusion-button-bar):not(.add_to_cart_button):not(.show_details_button):not(.product_type_external):not(.fusion-quick-view):not(.fusion-rollover-title-link):not(.fusion-breadcrumb-link):hover, .fusion-fullwidth.fusion-builder-row-1 a:not(.fusion-button):not(.fusion-builder-module-control):not(.fusion-social-network-icon):not(.fb-icon-element):not(.fusion-countdown-link):not(.fusion-rollover-link):not(.fusion-rollover-gallery):not(.fusion-button-bar):not(.add_to_cart_button):not(.show_details_button):not(.product_type_external):not(.fusion-quick-view):not(.fusion-rollover-title-link):not(.fusion-breadcrumb-link):hover:before, .fusion-fullwidth.fusion-builder-row-1 a:not(.fusion-button):not(.fusion-builder-module-control):not(.fusion-social-network-icon):not(.fb-icon-element):not(.fusion-countdown-link):not(.fusion-rollover-link):not(.fusion-rollover-gallery):not(.fusion-button-bar):not(.add_to_cart_button):not(.show_details_button):not(.product_type_external):not(.fusion-quick-view):not(.fusion-rollover-title-link):not(.fusion-breadcrumb-link):hover:after {color: #f2b310;}.fusion-fullwidth.fusion-builder-row-1 .pagination a.inactive:hover, .fusion-fullwidth.fusion-builder-row-1 .fusion-filters .fusion-filter.fusion-active a {border-color: #f2b310;}.fusion-fullwidth.fusion-builder-row-1 .pagination .current {border-color: #f2b310; background-color: #f2b310;}.fusion-fullwidth.fusion-builder-row-1 .fusion-filters .fusion-filter.fusion-active a, .fusion-fullwidth.fusion-builder-row-1 .fusion-date-and-formats .fusion-format-box, .fusion-fullwidth.fusion-builder-row-1 .fusion-popover, .fusion-fullwidth.fusion-builder-row-1 .tooltip-shortcode {color: #f2b310;}#main .fusion-fullwidth.fusion-builder-row-1 .post .blog-shortcode-post-title a:hover {color: #f2b310;}</style>

The post What You Need to Know About Penetration Testing Liability appeared first on Netragard.

by Adriel Desautels at September 14, 2020 05:11 PM

ipSpace.net Blog (Ivan Pepelnjak)

Is Cisco ACI Too Different?

A friend of mine involved in multiple Cisco ACI installations sent me this comment on their tenant connectivity model:

I’m a bit allergic to ACI. The abstraction is mis-aligned with familiar configurations, in particular contracts being independent of and over-riding routing, tenants, etc. You can really make a mess with that, and I’ve seen some! One needs to impose some structure, naming conventions…, and most people don’t seem to get that done.

As I noticed in the NSX-or-ACI webinar, it’s interesting how NSX decided to stay with the familiar VLAN/routing/filtering paradigm (more details), whereas the designers of Cisco ACI decided to go down a totally different path.

September 14, 2020 06:34 AM

XKCD Comics

September 13, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Duty Calls: CPU Is Not Designed for Packet Forwarding

Junhui Liu added this comment to my Where Do We Need Smart NICs? blog post:

CPU is not designed for the purpose of packet forwarding. One example is packet order retaining. It is impossible for a multicore CPU to retain the packet order as is received after parallel processing by multiple cores. Another example is scheduling. Yes CPU can do scheduling, but at a very high tax of CPU cycles.

Duty calls.

September 13, 2020 10:38 AM

September 12, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: The Making of an RFC in today’s IETF

Years ago I was naive enough to participate in writing an IETF document. Three years later we finally managed to turn it into an RFC, and I decided that was enough for one lifetime.

But wait, it gets worse… as Geoff Huston argues in his article, the lengthy review process doesn’t necessarily result in better (or more precise) documents.

Seems like we managed to turn IETF into yet another standard body like IEEE, ISO or ITU/T.

September 12, 2020 08:15 AM

September 11, 2020

The Networking Nerd

A Place for Things and Things in Their Place

This morning I was going to go for a run and I needed to find a rain jacket to keep from getting completely soaked. I knew I had one in my hiking backpack but couldn’t locate it. I searched for at least ten minutes in every spot I could think of and couldn’t find it. That is, until I looked under the brain of the pack and found it right next to the pack’s rain cover. Then I remembered that my past self had put the jacket there for safe keeping because I knew that if I ever needed to use the pack rain cover I would likely need to have my rain jacket as well. Present me wasn’t as happy to find out past me was so accommodating.

I realized after this little situation that I’ve grown accustomed to keeping my bags organized in a certain way both for ease of use and ease of inspection. Whether it’s a hiking backpack or an IT sling bag full of gadgets I’ve always tried to set things up in simple, sane manner to figure out how to find the tools I need quickly and also discover if any of them are missing.

Pocket Protection

I’ve always favored bags with lots of pocket space to keep my tools organized. Places to put things like battery packs, USB-C hubs, console cables, and even laptop power adaptors are important. And when everything has its own spot its easier to find in a pinch. You don’t often have the chance to see what you’re looking for in a dark server room or in a tight airplane seating row. Therefore, having a specified pocket for things makes it quick to search by feel.

It’s also important to locate items near their intended uses. For me, oft-used items like headphones or Lightning cables go nearest the outside for rapid access. My passport goes in a slash pocket for ease of retrieval on international trips. When I have other items that aren’t as necessary or frequently used, such as a first aid kit or an old VGA adapter for a MacBook, I put them in pockets that aren’t as likely to be used often.

Sometimes you have to make your own pockets. I’ve used a variety of organizers and other pouches over the years to help create order from the chaos of a big open space in a bag. Some, like the Grid-It are nice because they are quick and easy to reconfigure. However, the more complicated the organization structure the more likely you are to just chuck the parts back into the void and hope they come out on the other side. I’ve started to use clear bank bags as my primary method of cable organization in my messenger bag and they seem to work much better. They keep the adapters and other odds and ends from flying around everywhere.

Where’s Waldo?

The other reason I like the idea of a specific place for everything in my bag is being able to figure out quickly that something is missing. If I always keep a screwdriver in a specific pocket and it’s not there I can assume I’ve either lent it to someone or left it somewhere I shouldn’t have. It also allows me to do a quick inventory of my bag to figure out if things are out of place between trips or truck rolls.

One example of this is Cisco rollover console cables. When I worked for a VAR I had to carry one of these things to get console access to routers more often then I would like to admit. However, I didn’t just carry one. I always carried two. I liked the idea of having a backup just in case because that’s the kind of person that I am. But I also used it as a learning experience for the techs that I trained. I would carry a spare and then ask them to borrow their console cable. Usually, the response would be a blank look or fumbling in the pockets of their backpack for a cable they knew they didn’t have. I would then explain the importance of having all the tools you needed every time you made the trip. Then I would give them my spare cable to carry around with them. I often remarked, “Now that I’ve given this to you the next time I need one or you need one we both know you’ll have it.”

It was also easy for me to check my bag and make sure I needed to replace items that had gone missing. Maybe I remembered that my other tech had my screwdriver and I needed to go retrieve it. Or perhaps I needed to put another console cable back in my bag after loaning out my first one. I even would check my secret snack compartment from time to time to make sure I replaced my granola bars and almonds that I would invade during late night cutovers without pizza or other food. After all, a functioning brain in IT is just as important as a functioning router.


Tom’s Take

My organization methods may not work best for everyone. But you need to have a method to your madness. If you don’t you won’t know if you have the right tools for the job. If you don’t know which tools you need you wont know if they’re missing. If you don’t know where they are you won’t have them when you need them. It’s all a matter of experience and methodology. Once you build your method, stick to it. Keep up with things and make sure you spend some time every once in a while going through everything just to make sure you have it when you need it. Then you can thank your past self for thinking ahead instead of cursing yourself for leaving your pack a mess.

by networkingnerd at September 11, 2020 07:29 PM

My Etherealmind

DNS Flag Day 2020 – ISC

The DNS protocol needs refreshing but a global, distributed database is not easy to change. The folks leading the DNS architecture are making small but substantial changes once per year. There is a non-zero but small risk that something will break for some people.  This year they are addressing DNS Fragmentation on UDP and required […]

by Greg Ferro at September 11, 2020 04:59 PM

Musing: Hidden Complexity of Dual SIM Phones

It hadn’t occurred to me that having Dual SIMs in a smartphone has hidden aspects of complexity. In this slide, having multiple SIMs means thinking about activity – are both SIMs active at all times ? If so, are you willing to incur the battery and product penalty to have dual radios operating simultaneously.  Or […]

by Greg Ferro at September 11, 2020 10:14 AM

ipSpace.net Blog (Ivan Pepelnjak)

Video: ASICs 101

Earlier this year, Pete Lumbis returned as an ipSpace.net webinar guest speaker with a great presentation describing data center switching ASICs from the perspective of networking engineers. After a brief intro, he started with ASIC Basics… a topic which generated a 25-minute Q&A session.

All of the above-mentioned videos are available with Free ipSpace.net Subscription.

September 11, 2020 05:53 AM

XKCD Comics

September 10, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Disaster Recovery: a Vendor Marketing Tale

Several engineers formerly working for a large virtualization vendor were pretty upset with me when I claimed that the virtualization consultants promotedisaster recovery using stretched VLANs” designs instead of alternatives that would implement proper separation of failure domains.

Guess what… it’s even worse than I thought.

Here’s a sequence of comments I received after reposting one of my “disaster recovery doesn’t need stretched VLANs” blog posts on LinkedIn sometime in late 2019:

September 10, 2020 08:25 AM

Potaroo blog

DNS Query Privacy Revisited

A year has passed since we first looked at the level of use of Query Name Minimisation in the DNS and at the time the results were not impressive. It's time to relook at this topic and see what has changed in the DNS resolution environment over the past 12 months.

September 10, 2020 06:00 AM

September 09, 2020

My Etherealmind

My Thoughts on LinkedIn in 2020

LinkedIn originated with a focus on connecting professionals and contacts were supposed to be people that you know or worked with. The early team worked hard to build a monopoly/network effect around business connections.  Much of LinkedIn’s interface usability stems from that design intention. Now there is tension between what was LinkedIn was 10 years […]

by Greg Ferro at September 09, 2020 07:40 PM

Packet Pushers

Ansible Desired State Configuration & Idempotency Explained – Video

Josh Duffney explains desired state configuration and idempotency in the context of the Ansible automation platform. This video snippet is part of a longer podcast conversation on bringing Ansible into a Windows shop. Head on over to https://daytwocloud.io to find this and many more episodes on cloud, automation, infrastructure, and operations. You can subscribe to […]

The post Ansible Desired State Configuration & Idempotency Explained – Video appeared first on Packet Pushers.

by The Video Delivery at September 09, 2020 03:48 PM

My Etherealmind

Why Routers and Switches Don’t Matter Now

Stop futzing with one device and think about the system.

by Greg Ferro at September 09, 2020 01:39 PM

ipSpace.net Blog (Ivan Pepelnjak)

Where Do We Need Smart NICs?

We did a number of Software Gone Wild podcasts trying to figure out whether smart NICs address a real need or whether it’s just another vendor attempt to explore all potential markets. As expected, we got opposing views from Luke Gorrie claiming a NIC should be as simple as possible to Silvano Gai explaining how dedicated hardware performs the same operations at lower cost, lower power consumption and way higher speeds.

In theory, there’s no doubt that Silvano is right. Just look at how expensive some router line cards are, and try to figure out how much it would cost to get 25.6 Tbps of forwarding performance that we’ll get in a single ASIC (Tomahawk-4) in software (assuming ~10 Gbps per CPU core). High-speed core packet forwarding has to be done in dedicated hardware.

September 09, 2020 06:44 AM

XKCD Comics

September 08, 2020

Packet Pushers

Why Ansible & Chocolatey Package Manager Are Great Together – Video

Josh Duffney explains why the Chocolately package manager is essential for Windows automation. And it goes great with Ansible too!

The post Why Ansible & Chocolatey Package Manager Are Great Together – Video appeared first on Packet Pushers.

by The Video Delivery at September 08, 2020 07:41 PM

My Etherealmind

Virtual Open Office Hours – Mid September 2020

Virtual Open Office is a chance for people to gather and discuss any topics you find interesting. Open to Anyone. No cost or commitment. Just a chance to sit around and talk, like you were in the corridor at a conference.  I’ll be there with a coffee/tea or a beer/cocktail (as appropriate) Tuesday, September 15, […]

by Greg Ferro at September 08, 2020 05:45 PM

ipSpace.net Blog (Ivan Pepelnjak)

Public Cloud Providers and IPv4 Address Space

When planning to move your workloads to a public cloud you might want to consider the minor detail of public IPv4 connectivity (I know of at least one public cloud venture that couldn’t get their business off the ground because they couldn’t get enough public IPv4 addresses).

Here’s a question along these lines that one of the attendees of our public cloud networking course sent me:

September 08, 2020 06:04 AM

September 07, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Networking, Engineering and Safety

You might remember my occasional rants about lack of engineering in networking. A long while ago David Barroso nicely summarized the situation in a tweet responding to my BGP and Car Safety blog post:

If we were in a proper engineering we’d be discussing how to regulate and add safeties to an important tech that is unsafe and hard to operate. Instead, we blog about how to do crazy shit to it or how it’s a hot mess. Let’s be honest, if BGP was a car it’d be one pulled by horses.

September 07, 2020 07:07 AM

XKCD Comics

September 05, 2020

ipSpace.net Blog (Ivan Pepelnjak)

MUST READ: Lessons from load balancers and multicast

Justin Pietsch published another must-read article, this time dealing with operational complexity of load balancers and IP multicast. Here are just a few choice quotes to get you started:

  • A critical lesson I learned is that running out of capacity is the worst thing you can do in networking
  • You can prevent a lot of problems if you can deep dive into an architecture and understand it’s tradeoffs and limitations
  • Magic infrastructure is often extremely hard to troubleshoot and debug

You might find what he learned useful the next time you’re facing a unicorn-colored slide deck from your favorite software-defined or intent-based vendor ;))

September 05, 2020 07:35 AM

September 04, 2020

The Networking Nerd

Fast Friday- Labor Day Eve Edition

It’s a long weekend in the US thanks to Labor Day. Which is basically signaling the end of the summer months. Or maybe the end of March depending on how you look at it. The rest of the year is packed full of more virtual Zoom calls, conferences, Tech Field Day events, and all the fun you can have looking at virtual leaves turning colors.

It’s been an interesting news week for some things. And if you take out all the speculation about who is going to end up watching TikTok you are left with not much else. So I’ve been wondering out loud about a few things that I thought I would share.

  • You need a backup video conferencing platform. If Zoom isn’t crashing on you then someone is deleting WebEx VMs. Or maybe your callers can’t get the hang of the interface. Treat it like a failing demo during a presentation: if it doesn’t work in five minutes, go to plan B. Don’t leave your people waiting for something that may not happen.
  • If you work in the backbone service provider market, you need to do two things next week. First, you need to make sure all your hardware is patched. Some nasty stuff floating around that has the potential to cause memory exhaustion. That’s downtime in a nutshell. The next is that you need to go read up on BGP again and make sure you know how it propagates and what to do when it does something you’re not expecting. You can better believe the people at CenturyLink have bought lots of BGP reference books in the past few days for absolutely no reason at all.
  • Remember how most ISPs told us back at the start of this whole pandemic that they were graciously removing data caps and such to get us through our Netflix binges? Guess what? Those caps are starting to be put back in place now. Guess the start of school means the start of keeping us in check with our data usage. And the fall seasons of popular shows are coming out in a regular cadence now. Check to make sure you’re not going over your limits. And find out what it costs to do that. Don’t be afraid to block Youtube and Twitch if your kids are eating your bandwidth pool alive.
  • Lastly, stand up. Take a deep breath. Let it out. Relax your shoulders. Unclench your teeth. I’m sure you needed that. Now buckle down and get that thing done.

Tom’s Take

Make sure to stay tuned to the rest of March Part 6, otherwise known as September. More cool stuff headed your way before the equinox plunges us into eternal not-spring.

by networkingnerd at September 04, 2020 06:23 PM

ipSpace.net Blog (Ivan Pepelnjak)

Video: Define the Problem Before Searching for a Solution

In December 2019 I finally turned my focus on business challenges first presentation into a short webinar session (part of Business Aspects of Networking Technologies webinar) starting with defining the problem before searching for a solution including three simple questions:

  • What BUSINESS problem are you trying to solve?
  • Are there good-enough alternatives or should you really invest into new technology and/or equipment?
  • Is the problem worth solving?
You need Free ipSpace.net Subscription to watch the video.

September 04, 2020 05:55 AM

XKCD Comics

September 03, 2020

Packet Pushers

Why Microsoft Is Still Chasing TikTok

Microsoft may be nearing a deal to buy TikTok. I speculate on five reasons why the company wants this platform, and potential risks for Microsoft.

The post Why Microsoft Is Still Chasing TikTok appeared first on Packet Pushers.

by Drew Conry-Murray at September 03, 2020 04:06 PM

ipSpace.net Blog (Ivan Pepelnjak)

Considerations for Host-based Firewalls (Part 1)

This is a guest blog post by Matthias Luft, Principal Platform Security Engineer @ Salesforce, and a regular ipSpace.net guest speaker.

Having spent my career in various roles in IT security, Ivan and I always bounced thoughts on the overlap between networking and security (and, more recently, Cloud/Container) around. One of the hot challenges on that boundary that regularly comes up in network/security discussions is the topic of this blog post: microsegmentation and host-based firewalls (HBFs).

September 03, 2020 06:57 AM

September 02, 2020

Packet Pushers

Kong Aims To Be King Of The Service Mesh And API Gateway

Kong Enterprise 2.1 bundles a service mesh, API gateway, and Kubernetes Ingress Controller, all of which can be managed from a unified control plane. The goal is to make it easier for enterprises to meet a variety of application traffic management needs from a common interface.

The post Kong Aims To Be King Of The Service Mesh And API Gateway appeared first on Packet Pushers.

by Drew Conry-Murray at September 02, 2020 09:32 PM

XKCD Comics

September 01, 2020

Packet Pushers

Ansible Or Terraform: Choose One

Ansible and Terraform are both useful tools for network automation. Should network engineers learn both, or is there a reason to focus on one? Ned Bellavance and Josh VanDeraa share their opinions in this excerpt from the Packet Pushers’ Heavy Networking podcast. To hear the full conversation, play episode 537. Josh VanDeraa has an instructional […]

The post Ansible Or Terraform: Choose One appeared first on Packet Pushers.

by The Video Delivery at September 01, 2020 11:00 PM

How Ansible & Terraform Differ – Video

You can use Ansible and Terraform for network automation. Josh VanDeraa and Ned Bellavance explore the differences between these tools on the Packet Pushers’ Heavy Networking podcast. To hear the full conversation, listen to episode 537. Josh VanDeraa has an instructional course “Ansible For Network Automation” at ignition.packetpushers.net. Ned Bellavance blogs at Ned In The Cloud […]

The post How Ansible & Terraform Differ – Video appeared first on Packet Pushers.

by The Video Delivery at September 01, 2020 09:04 PM