More than a year ago I was enjoying a cool beer with my friend Nicola Modena who started explaining how he solved the “you don’t need IP address renumbering for disaster recovery” conundrum with production and standby VRFs. All it takes to flip the two is a few changes in import/export route targets.

I asked Nicola to write about his design, but he’s too busy doing useful stuff. Fortunately he’s not the only one using common sense approach to disaster recovery designs (as opposed to flat earth vendor marketectures). Adrian Giacometti used a very similar design with one of his customers and documented it in a blog post.

A long-time reader sent me a series of questions about the impact of WAN partitioning in case of an SDN-based network spanning multiple locations after watching the Architectures part of Data Center Fabrics webinar. He therefore focused on the specific case of centralized control plane (read: an equivalent of a stackable switch) with distributed controller cluster (read: switch stack spread across multiple locations).

Minh Ha left the following rant as a comment on my 5-year-old What Are The Problems with Broadcom Tomahawk? blog post. It’s too good to be left gathering dust there. Counterarguments and other perspectives are highly welcome.

So basically a lot of vendors these days are just glorified Broadcom resellers :p. It’s funny how some of them try to up themselves by saying they differentiate their offerings with their Network OS.

Almost exactly a year ago Miha Markočič joined the ipSpace.net team. He was fresh out of university, fluent in Python, but with no networking or automation background… so I decided to try my traditional method of getting new team members up to speed: throw them into the deep water, observe how quickly they learn to swim, and give them a few tips if it seems like they might be drowning.

It worked out amazingly well. Miha quickly mastered the intricacies of AWS and Azure, and created full-stack automation solutions in Ansible, Terraform, CloudFormation and Azure Resource Manager to support the AWS and Azure webinars, and the public cloud networking online course.

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.

Too bad they’re describing an ancient Trident-2 ASIC (I last mentioned switches using it in 2017 Data Center Fabrics update). Did NDA expire on that one?

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).

If you’re experiencing similar challenges you might appreciate AAA Deep Dive on Cisco Devices by the one and only Daniel Dib.

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. 

Kevin Myers of IPArchitechs brought this to my attention around March of 2019, at which point I went straight to work with it to see how far it could be pushed.

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.

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
• Idempotency

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.

For public cloud networking details, check out our cloud webinars and online course.

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.