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:
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.
Also, 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 might be back to business-as-usual after a few months (unlikely), or it could be Ivan working on some interesting stuff (most likely) or ipSpace.net slowly disappearing into the sunset (not impossible).
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 ;))