I have my +100 hat of irreverence on today so it’s time for a soapbox post. Having recently read a several posts and articles on what seems to be the never-ending cavalcade of assertions that “networking people will be out of jobs and you’d better learn to be a programmer” - or more succinctly put: the “dramatic changes in IT networking”. To this I respond simply: via GIPHY The scorched earth, “there’s a hole in the boat, we’re all going to die!

Configuration management is a critical part of successfully and efficiently run any network. From the early days of networking there have been options for doing configuration backup. Several projects have been around for literally decades, enabling the backup of a myriad of critical network devices and providing historical archives. Many of these projects and platforms require a reasonable amount of unix experience and perhaps some development skills. I’m going to give a quick synopsis of my three favorites, these a all very different in execution but provide the same types of services - configuration backup, diff, and archive (and not much else).

Anyone that looks at this site with any regularity may have noticed that I have been pretty remiss in adding posts - for that I apologize, things have been busy. However, I have not been absent in the tech world…quite the opposite, in fact. I’ve been spending more and more time on podcasts and other forms of tech media which I have not provided links for here. So, to help expose that, here are a few of the other media resources I’ve been popping up in.

Taking politics and putting them aside, what the new administration has been attempting to change with regard to internet privacy is something we should all be informed about. Wether you have a tin foil hat or don’t care, “knowing is half the battle”. The other half is doing - which I will also lend some brief insight to (sorta). What’s changing? Nothing yet (as of the time of this writing). What will likely change?

In the last few years I have moved all of my virtualization to proxmox and docker. Seeing as I like to look at packets because I am a closet security guy, and being as I have been working off-and-on on a security project in recent times, I wanted to be able to span a port not only from a hardware switch, but also within my software switches. I had been using linux bridge, which I am not a fan of, so when I started down this path I did not look hard to find a way to do so under that platform.

Worth Reading: Why I care about Segment Routing - 'net work - Oct 3, 2016 […] As a WAN guy by chance and opportunity, and a service provider engineer and architect by choice (and… […] [Mike Fratto]( “mfratto@techweb.com”) - Oct 4, 2016 Hi Nick, I’m not a WAN routing guy so this may be a ridiculous question but I’m curious how you would compare/contrast segment routing with shortest path bridging. From the little I know, the goals seem awfully similar.

Edit: Going against my normal “just get the content out there” methodology, I’ve been mulling over this blog post since July of 2016. Segment routing is such a beautifully elegant solution I have had trouble articulating that fact. WAN technologies are squarely within my wheelhouse, and this one fits in so well I was going over and over the post never really satisfied with it, continuing to find mistakes and decided to just get it out there.

[SilentLennie]( “disqus@consolejunkie.net”) - May 6, 2016 It’s almost always the organisational part that is the hard part. Look at DNSSEC, the technical part is easy to deploy these days: see PowerDNS for example. Now getting someone in your organisation to deal with DS-record and know what to do when migrating a domain… well, that’s a whole process, that’s the difficult part of the story. I do however believe it could be simpler though.

Image created from SURFNet RPKI page.  I was recently at a meeting where BGP RPKI was the topic de jour. While this has been a topic that I have visited on occasion of the last few years and something I wanted to spend significant time on, I have found that setting aside the time has been difficult and sparse, much like the deployment of BGP RPKI.

The sixth [and arguably very overdue] installment of my NIX4NetEng series, this began as an overly complex diatribe about DNS. As it evolved, I realized that DNS is so complex and far reaching that it could never be contained in one meager post. DNS is a powerful tool. It has existed for so long that many that have never had the responsibility of running an authoritative or recursive resolver may take for granted the extensive reach of a tool so engrained in the fabric of the internet that it is frequently overlooked, much like a utility such as electricity or running water.