Blog Posts in December 2017
Could you believe it? Another year swooshed by… and it’s high time to stop being snarky and cynical, disconnect from the Internet, and spend a few days with people who really matter – our families.
For me, there’s another large group of people that matter: my users.
In December 2017 IETF published RFC 8273 created by the v6ops working group (which means there must have been significant consensus within the working group that we need the solution and that it makes at least marginal sense).
The RFC specifies a mechanism by which the first-hop router allocates a unique /64 IPv6 prefix for every host attached to a subnet and uses unicast and multicast RA responses sent to unicast MAC addresses to give every host the impression that it’s the sole host on its own subnet.
The first thought of anyone even vaguely familiar with how complex IPv6 already is should be “WTF???” Unfortunately, there are good reasons we need this monstrosity.
In the first few sessions of the Building Network Automation Solutions online course we used Ansible as the tool-of-choice because it’s the easiest automation tool to get started with. Now that we’ve established the baseline, it’s time to explore the alternatives.
In a live session on February 27th 2018, Mircea Ulinic will describe Salt, an open source, general-purpose event-driven automation framework that we briefly discussed in Episode 77 of Software Gone Wild podcast.
Every now and then someone looks at a few recent BGP incidents (from fat fingers to more dubious ones) and says “we need a better BGP”.
It’s like being unable to cope with your kids or your team members because you don’t have the guts to tell them NO and trying to solve the problem by implementing new procedures and rules.
Like anything designed on a few napkins BGP has its limit. They’re well known, and most of them have to do with trusting your neighbors instead of checking what they tell you.
As academics, it would be extremely valuable for us to receive feedback from network operators in the industry.
It’s fantastic to see researchers who want to base their work on real-life experience (as opposed to ideas that result in great-looking YouTube videos but fail miserably when faced with reality), so if you’re working for an ISP please take a few minutes and fill out this survey.
I'm involved in a Nexus 9500 (NX-OS) migration project, and one bug recently caused vPC-connected Catalyst switches to err-disable (STP channel-misconfig) their port-channel members (CSCvg05807), effectively shutting down the network for our campus during what was supposed to be a "non-disruptive" ISSU upgrade.
Weird, right? Wait, there’s more…
I haven’t done an update on what Avaya was doing in the data center space for years, so I asked my good friend Roger Lapuh to do a short presentation on:
- Avaya’s data center switches and their Shortest Path Bridging (SPB) fabric;
- SPB fabric features;
- Interesting use cases enabled by SPB fabric.
- Should you use IBGP or EBGP?
- When should you run BGP on the spine switches?
- Should every leaf switch have a different AS number or should they share the same AS number?
A while ago I created an Ansible playbook that creates network diagrams from LLDP information. Ben Roberts, a student in my Building Network Automation Solutions online course used those ideas to create an awesome solution: he’s graphing multicast trees.
Here’s how he described his solution:
One of my readers sent me this question:
One thing that I notice is you mentioned moving the complexity to the upper layer. I was wondering why browsers don't support multiple IP addresses for a single site – when a browser receives more than one IP address in a DNS response, it could try to perform TCP SYN to the first address, and if it fails it will move to the other address. This way we don't need an anycast solution for DR site.
For the first two sessions of the Building Network Automation Solutions online course I got awesome guest speakers, and it seems we’ll have another fantastic lineup in the Spring 2018 course:
Most network automation solutions focus on device configuration based on user request – service creation or change of data model describing the network. Another very important but often ignored aspect is automatic response to external events, and that’s what David Gee will describe in his presentation.
Here’s a quote from one of my friends who spent years working with Ansible playbooks:
Debugging Ansible is one of the most terrible experiences one can endure…
Please note that the Building Network Automation Solutions online course includes all material from the Ansible online course.
This blog post by Ethan Bank totally describes my (bad) Inbox habits. If you're anything like me, you might find Ethan's ideas useful (I do... following them is a different story though).
A while ago (in the time of big-versus-small buffers brouhaha) I asked JR Rivers to do a short presentation focusing on buffering requirements of data center switches. He started by describing typical buffer architectures you might find in data center switches.
I got numerous responses to the “Why Does It Take So Long to Upgrade Network Devices,” the best ones coming from Béla Várkonyi and Frederic Cuiller.
Béla is sick-and-tired of the stuff vendors are shipping:
I have yet to complete the rest of the course and assignments, but the whole package was a tremendous help for me to get our Ansible running. We now deploy whole WAN sites within an hour.
Of course I wanted to know more and he sent me a detailed description of what they’re doing:
Here’s a question I got on one of my ancient blog posts:
How many OSPF process ID can be used in a single VRF instance?
Seriously? You have to ask that? OK, maybe the question isn’t as simple as it looks. It could be understood as:
When I started my ipSpace.net project life was simple: I had a few webinars, and you could register for the live sessions. After a while I started adding recordings, subscriptions, bundles, roadmaps (and tracks), books… and a few years later workshops and online courses.
As you can imagine, the whole thing became a hard-to-navigate mess. Right now you can buy almost 70 different products on ipSpace.net. Time for a cleanup.
Diptanshu Singh wrote a nice explanation of the math behind reliability calculations. Definitely worth reading even if you hated statistics.
Dave Taht sent me a link to IRTT after I published a blog post on measuring end-to-end latency with an Ansible playbook. Definitely looks like a tool worth having in your toolbox.
Not surprisingly, as we started discovering the history behind NETCONF we quickly figured out that all the API and automation hype being touted these days is nothing new – some engineers have been doing that stuff for almost 20 years.