Blog Posts in January 2021
Arista published a blog post describing the details of forwarding table sizes on 7050QX-series switches. The description includes the base mode (fixed tables), unified forwarding tables and even the IPv6 LPM details, and dives deep into what happens when the switch runs out of forwarding table entries.
Decades ago I understood the intricacies of AAA on Cisco IOS. These days I wing it and keep throwing spaghetti at the virtual wall until something sticks and I can log in (after all, it’s all in a lab, and I’m interested in routing protocols not interactions with TACACS+ server).
This podcast introduction was written by Nick Buraglio, the host of today’s podcast.
In today’s evolving landscape of whitebox, brightbox, and software routing, a small but incredibly comprehensive routing platform called FreeRTR has quietly been evolving out of a research and education service provider network in Hungary.
When I blogged about release 0.2 of my lab-building tool, Kristian Larsson was quick to reply: “now do vrnetlab”. You could guess what my reply was (hint: “submit a pull request”), but I did realize I’d have to add multi-provider support before that would make sense.
Release 0.3 adds support for multiple virtualization providers. You can run six different platforms on vagrant-libvirt (assuming you build the boxes), and I added rudimentary support for Vagrant provider for VirtualBox:
Miha Markočič created sample automation scripts (mostly Terraform configuration files + AWS CLI commands where needed) deploying these features described in AWS Networking webinar:
- IP multicast deployment (video)
- Web Application Firewall deployment (video)
- Network Load Balancer deployment (video)
- Inter-region VPC Peering deployment (video)
To recreate them, clone the GitHub repository and follow the instructions.
In the last weeks I described the challenges you might face when converting XML documents that contain lists with a single element into JSON, be it on device (Nexus OS) or in an Ansible module. Now let’s see how we can fix that.
Blog posts in this series
- Beware XML-to-JSON Information Loss (Junos with Ansible)
- XML-to-JSON Information Loss, Cisco Nexus OS Edition
- Fixing XML-to-JSON Conversion Challenges (this post)
There’s one more thing I feel needs to be done before I go for that coffee break: a webinar focusing on network automation concepts (as opposed to replacing Excel with YAML and Ansible or Becoming a Python Coder). Here’s a rough list of concepts I think should be in there:
- Data models and data stores
- Data model transformations
- Single source of truth
- Abstraction layers
Anyone who spent some time reading cloud providers' documentation instead of watching slide decks or vendor keynotes knows that setting up infrastructure in a public cloud is not much simpler than doing it on-premises. You will outsource hardware management (installations, upgrades, replacements…) and might deal with an orchestration system provisioning services instead of configuring individual devices, but you still have to make the same decisions, and take the same set of responsibilities.
Obviously that doesn’t look good in a vendor slide deck, so don’t expect them to tell you the gory details (and when they start talking about the power of declarative API you know you have a winner)… but every now and then someone decides to point out the state of emperor’s clothes, this time Gerben Wierda in his The many lies about reducing complexity part 2: Cloud.
In December 2020 Ed Horley invited me to a chat about IPv6 in the public cloud. While I usually don’t want to think about a protocol that’s old enough to buy its own beer in US, we nonetheless had interesting discussions (including the need for frequent RA messages in AWS VPC).
Corey Quinn mentioned me in a tweet linking to AWS announcement that they are the biggest user of BGP RPKI (by the size of signed address space) worldwide. Good for them – I’m sure it got their marketing excited. It’s also trivial to do once you have the infrastructure in place. Just saying…
On a more serious front: how important is RPKI and what misuses can it stop?
If you’ve never heard of RPKI, the AWS blog post is not too bad, Nick Matthews wrote a “look grandma, this is how it works” version in 280-character installments, and you should definitely spend some time exploring MANRS resources. Here’s a short version for differently-attentive ;))
Last week I wrote about the interesting challenges you might encounter when using data generated by a Junos device in an Ansible playbook. Unfortunately it’s not just Junos – every system built around XML-based data structures might experience the same issues, including Cisco Nexus OS.
I always claimed that VMware Fault Tolerance makes no sense. After all, the only thing it does is protect a VM against a server hardware failure… in the world where software crashes are way more common, and fat fingers cause most of the outages.
In mid-December I announced a set of tools that will help you build Vagrant-based remote labs much faster than writing Vagrantfiles and Ansible inventories by hand.
In early January I received a nice surprise: Dave Thelen not only decided to use the tool, he submitted a pull request with full-blown (and correctly implemented) ArcOS support. A few days later I managed to figure out what needs to be configured on vSRX to make it work, added Junos support, and thus increased the number of supported platforms to six (spanning five different operating systems).
After discussing the technology options one has when trying to get a packet across the network, we dived deep into two interesting topics:
- How do you combine packet forwarding at multiple layers of OSI stack (multi-layer switching)?
- What happens when you do layer-N forwarding over layer-M transport core where N <= M (example: IPv6 packets over IPv4 packets) aka tunneling?
You’ll find more details (including other hybrids like Loose Source Routing) in Multi-Layer Switching and Tunneling video.
When you want to transport a complex data structure between components of a distributed system you’re usually using a platform-independent data encoding format like XML, YAML, or JSON.
XML was the hip encoding format in days when Junos and Cisco Nexus OS was designed and lost most of its popularity in the meantime due to its complexity (attributes, namespaces…) that makes it hard to deal with XML documents in most programming languages.
JSON is the new cool kid on the block. It’s less complex than XML, maps better into data structures supported by modern programming languages, and has decently fast parser implementations.
Looks like some vendor marketers (you know, the same group of people who brought us the switching/routing/bridging stupidity) felt the need to go beyond the usual SDN and intent-based hype and started misusing the imperative versus declarative concepts. Unfortunately some networking engineers fell for the ploy; here’s a typical feedback along these lines I got from one of my readers:
I am frustrated by most people’s shallow understanding API’s, especially the differences between declarative (“what”) and imperative (“how”) API’s, and how that impacts one’s operations. Declarative APIs are the key pillar of what many vendors call “policy” or “intent-based” networking.
Let’s try to unravel that.
It’s amazing how quickly you can deploy new functionality once you have a solid foundation in place. In his latest blog post Adrian Giacometti described how he implemented a security solution that allows network operators to block source IP addresses (identified by security tools) across dozens of firewalls using a bot listening to a Slack channel.
After deciding to take a slightly longer coffee break I went through the list of outstanding projects trying to figure out which ones I could complete in first half of 2021, which ones I’ll get to “eventually” and what’s a lost cause.
Irena is telling me that I should stop inviting guest speakers – our calendar is full until June 2021. Here’s what we have planned and what we got done at the time of the last update (March 3, 2021).
In January 2018 Rodney Brooks made a series of long-term predictions about self-driving cars, robotics, AI, ML, and space travel. Not surprisingly, his predictions were curmudgeonly and pessimistic when compared to the daily hype (or I wouldn’t be blogging about it)… but guess who was right ;)
He’s also the only predictor I’m aware of who is not afraid to compare what he wrote with how reality turned out years down the line. On January 1st he published the 2021 edition of the predictions scorecard and so far he hasn’t been too pessimistic yet. Keep that in mind the next time you’ll be listening to your favorite $vendor droning about the wonders of AI/ML.
Right after Cisco SD-WAN devices are onboarded, how are the control and data plane tasks started? In this section, David Penaloza covers how Cisco SD-WAN solution makes the most of its SDN nature: single point of policy application and centralized management platform. The types of policies, the plane on which they act, their application and the actions that can performed are the main focus in this part of the series.
A couple of months ago I had the pleasure to publish my first guest post here and, as to be expected from ipspace.net, it triggered some great discussion.
With this input and some open thoughts from the last post, I want to dive into a few more topics.
TL&DR: If you run multiple IGP protocols in your network, and add BGP on top of that, you might get the results you deserve. Even better, the results are platform-dependent.
One of my readers sent me a link to an interesting scenario described by Jeremy Filliben that results in totally unexpected behavior when using too many routing protocols in your network (no surprise there).
Imagine a network in which two edge routers advertise the same (external) BGP prefix. All other things being equal, it would make sense that other routers in the same autonomous system should use the better path out of the autonomous system. Welcome to the final tie-breaker in BGP route selection process: IGP metric.
Long story short: ipSpace.net is going on an extended coffee break on June 24th 2021. You can stop reading; the rest of the blog post is full of details you probably don’t care about.
What exactly does that mean? Honestly, we don’t know yet… but we felt that it’s only fair to let engineers considering our subscriptions know months in advance what might happen. As the ideas are crystalizing, we’re updating this blog post and an overview of changes.
Anyway, after investing two lifetimes into this project, and a few planned changes coming just before our regular summer hiatus (see below) it’s time for a longer break. ipSpace.net will revert back to Ivan working on some interesting stuff.
We had the usual gloomy December weather during the end-of-year holidays, and together with the partial lockdown (with confusing ever-changing rules only someone in Balkans could dream up) it managed to put me in OCD mood… and so I decided to remove broken links from the old blog posts.
While doing that I figured out how fragile our industry is – I encountered a graveyard of ideas and products that would make Google proud. Some of those blog posts were removed, I left others intact because they still have some technical merits, and I made sure to write sarcastic update notices on product-focused ones. Consider those comments Easter eggs… now go and find them ;))