Segment Routing Segment IDs and MPLS Labels

In one of my introductory Segment Routing videos, I made claims along the lines of “Segment Routing totally simplifies the MPLS control plane, replacing LDP and local labels allocated to various prefixes with globally managed labels advertised in IGP”

It took two years for someone to realize the stupidity over-simplification of what I described. Matjaž Strauss sent me this kind summary of my errors:

You’re effectively claiming that SRGB has to be the same across all devices in the network. That’s not true; routers advertise SIDs and must configure label swap operations in case SRGBs don’t match.

Wait, what? What is SRGB and why could it be different across devices in the same network? Also, trust IETF to take a simple idea and complicate it to support vendor whims.

Segment Routing Segment IDs and MPLS Labels

In one of my introductory Segment Routing videos, I made claims along the lines of “Segment Routing totally simplifies the MPLS control plane, replacing LDP and local labels allocated to various prefixes with globally managed labels advertised in IGP”

It took two years for someone to realize the stupidity over-simplification of what I described. Matjaž Strauss sent me this kind summary of my errors:

You’re effectively claiming that SRGB has to be the same across all devices in the network. That’s not true; routers advertise SIDs and must configure label swap operations in case SRGBs don’t match.

Wait, what? What is SRGB and why could it be different across devices in the same network? Also, trust IETF to take a simple idea and complicate it to support vendor whims.

Feedback: Microsoft Azure Networking

Azure and AWS have decent documentation (I always found it relatively easy to figure out what they’re doing), but what they implemented is sometimes so far away from what we’re used to that it’s hard to bridge the gap. Here’s how Olle Wilhelmsson solved that challenge:

Feedback: Microsoft Azure Networking

Azure and AWS have decent documentation (I always found it relatively easy to figure out what they’re doing), but what they implemented is sometimes so far away from what we’re used to that it’s hard to bridge the gap. Here’s how Olle Wilhelmsson solved that challenge:

RFC 7868: The Definitive EIGRP Guide

Seventeen years after I started working on my EIGRP book, the reverse engineering days were over: RFC 7868 is the definitive guide to modern EIGRP (I’m not familiar with at least half of the concepts mentioned in it).

Just in case you’re interested in a bit of historical trivia:

• My EIGRP deciphering history started a few years before the book was published. In mid-1990s I was asked (as an external trainer) to create an EIGRP course for Cisco EMEA Training.
• I’ve never seen any internal EIGRP documentation or code – everything I knew about EIGRP I’ve learned from trying out crazy stuff and deciphering debugging messages.
• Two of the RFC authors (Russ White and Don Slice) were the technical reviewers for my EIGRP book. Russ copiously rewrote my pidgin English into something understandable – if you like reading my blog posts today, you should (also) thank Russ.

RFC 7868: The Definitive EIGRP Guide

Seventeen years after I started working on my EIGRP book, the reverse engineering days were over: RFC 7868 is the definitive guide to modern EIGRP (I’m not familiar with at least half of the concepts mentioned in it).

Just in case you’re interested in a bit of historical trivia:

• My EIGRP deciphering history started a few years before the book was published. In mid-1990s I was asked (as an external trainer) to create an EIGRP course for Cisco EMEA Training.
• I’ve never seen any internal EIGRP documentation or code – everything I knew about EIGRP I’ve learned from trying out crazy stuff and deciphering debugging messages.
• Two of the RFC authors (Russ White and Don Slice) were the technical reviewers for my EIGRP book. Russ copiously rewrote my pidgin English into something understandable – if you like reading my blog posts today, you should (also) thank Russ.

Katacoda Scenario: netsim-tools with Containerlab and FRRouting

TL&DR: If you’d like to see how easy it is to deploy a full-blown OSPF+BGP network with netsim-tools together with Containerlab and FRRouting, check out this Katacoda scenario.

What is Katacoda? An awesome environment that allows content authors to create scenarios running on Linux VMs accessible through a web browser. I can only hope they’ll fix the quirks and keep going – I have so many ideas what could be done with it.

Why FRR? Not too long ago Jeroen van Bemmel sent me a link to a simple Katacoda scenario he created to demonstrate how to set up netsim-tools and containerlab. His scenario got the tools installed and set up, but couldn’t create a running network as there are almost no usable Network OS images on Docker Hub (that is accessible from within Katacoda) – the only image I could find was FRR.

Blogging Rule#1: Own Your Content

During my interview with David Bombal I made a recommendation I find crucial for anyone serious about blogging:

Make sure you own your content.

There’s a simple reason for that rule: if you want to write quality content, you’ll have to invest a lot of time into it.

Blogging Rule#1: Own Your Content

During my interview with David Bombal I made a recommendation I find crucial for anyone serious about blogging:

Make sure you own your content.

There’s a simple reason for that rule: if you want to write quality content, you’ll have to invest a lot of time into it.

Netsim-tools Release 0.6: BGP, IS-IS, SR-MPLS, FRR

TL&DR: If you want to test BGP, OSPF, IS-IS, or SR-MPLS in a virtual lab, you might build the lab faster with netsim-tools release 0.6.

In the netsim-tools release 0.6 I focused on adding routing protocol functionality:

• IS-IS on Cisco IOS/IOS XE, Cisco NX-OS, Arista EOS, FRR, and Junos.
• BGP on the same set of platforms, including support for multiple autonomous systems, EBGP, IBGP full mesh, IBGP with route reflectors, next-hop-self control, and BGP/IGP interaction.
• Segment Routing with MPLS on Cisco IOS XE and Arista EOS.

You’ll also get:

netsim-tools Release 0.6: BGP, IS-IS, SR-MPLS, FRR

TL&DR: If you want to test BGP, OSPF, IS-IS, or SR-MPLS in a virtual lab, you might build the lab faster with netsim-tools release 0.6.

In the netsim-tools release 0.6 I focused on adding routing protocol functionality:

• IS-IS on Cisco IOS/IOS XE, Cisco NX-OS, Arista EOS, FRR, and Junos.
• BGP on the same set of platforms, including support for multiple autonomous systems, EBGP, IBGP full mesh, IBGP with route reflectors, next-hop-self control, and BGP/IGP interaction.
• Segment Routing with MPLS on Cisco IOS XE and Arista EOS.

You’ll also get:

MUST READ: Deploy AWS Security Rules in a GitOps World with AWS, Terraform, GitLab CI, Slack, and Python

I know the title sounds like a buzzword-bingo-winning clickbait, but it’s true. Adrian Giacometti decided to merge the topics of two ipSpace.net online courses and automated deployment of AWS security rules using Terraform within GitLab CI pipeline, with Slack messages serving as manual checks and approvals.

Not only did he do a great job mastering- and gluing together so many diverse bits and pieces, he also documented the solution and published the source code:

• Part 1: Cloud & Network automation challenge: Deploy Security Rules in a DevOps/GitOps world with AWS, Terraform, GitLab CI, Slack, and Python (special guest FastAPI)
• Part 2: AWS, Terraform and FastAPI
• Part 3: GitLab CI, Slack, and Python
• Source code: aegiacometti/devops_cloud_challenge · GitLab

Want to build something similar? Join our Network Automation and/or Public Cloud course and get started. Need something similar in your environment? Adrian is an independent consultant and ready to work on your projects.

MUST READ: Deploy AWS Security Rules in a GitOps World with Terraform, GitLab CI, Slack, and Python

I know the title sounds like a buzzword-bingo-winning clickbait, but it’s true. Adrian Giacometti decided to merge the topics of two ipSpace.net online courses and automated deployment of AWS security rules using Terraform within GitLab CI pipeline, with Slack messages serving as manual checks and approvals.

Not only did he do a great job mastering- and gluing together so many diverse bits and pieces, he also documented the solution and published the source code:

• Part 1: Cloud & Network automation challenge: Deploy Security Rules in a DevOps/GitOps world with AWS, Terraform, GitLab CI, Slack, and Python (special guest FastAPI)
• Part 2: AWS, Terraform and FastAPI
• Part 3: GitLab CI, Slack, and Python
• Source code: aegiacometti/devops_cloud_challenge · GitLab

Want to build something similar? Join our Network Automation and/or Public Cloud course and get started. Need something similar in your environment? Adrian is an independent consultant and ready to work on your projects.

Everything Is a Graph

One of the viewers of Rachel Traylor’s excellent ‌Graph Algorithms in Networks webinar sent me this feedback:

I think it is too advanced for my needs. Interesting but difficult to apply. I love math and I find it interesting maybe for bigger companies, but for a small company it is not possible to apply it.

While a small company’s network might not warrant a graph-focused approach (I might disagree, but let’s not go there), keep in mind that almost everything we do in IT rides on top of some sort of graph:

Everything Is a Graph

One of the viewers of Rachel Traylor’s excellent ‌Graph Algorithms in Networks webinar sent me this feedback:

I think it is too advanced for my needs. Interesting but difficult to apply. I love math and I find it interesting maybe for bigger companies, but for a small company it is not possible to apply it.

While a small company’s network might not warrant a graph-focused approach (I might disagree, but let’s not go there), keep in mind that almost everything we do in IT rides on top of some sort of graph:

Worth Reading: Understand Your Single Points of Failure

I’ve been saying the same thing for years, but never as succinctly as Alastair Cooke did in his Understand Your Single Points of Failure (SPOF) blog post:

The problem is that each time we eliminated a SPOF, we at least doubled our cost and complexity. The additional cost and complexity are precisely why we may choose to leave a SPOF; eliminating the SPOF may be more expensive than an outage cost due to the SPOF.

Obviously that assumes that you’re able to follow business objectives and not some artificial measure like uptime. Speaking of artificial measures, you might like the discussion about taxonomy of indecision.

Worth Reading: Understand Your Single Points of Failure

I’ve been saying the same thing for years, but never as succinctly as Alastair Cooke did in his Understand Your Single Points of Failure (SPOF) blog post:

The problem is that each time we eliminated a SPOF, we at least doubled our cost and complexity. The additional cost and complexity are precisely why we may choose to leave a SPOF; eliminating the SPOF may be more expensive than an outage cost due to the SPOF.

Obviously that assumes that you’re able to follow business objectives and not some artificial measure like uptime. Speaking of artificial measures, you might like the discussion about taxonomy of indecision.

Worth Reading: The Insider’s Guide To Evangelizing Good Design

Scott Berkun wrote another great article that’s equally applicable to the traditional notion of design (his specialty) and the network design. Read it, replace design with network design, and use its lessons. Here’s just a sample:

• Convincing people is a social process
• Aim for small wins, not conversions of belief systems
• Allies matter more than ideas
• Design maturity grows one step at a time.

Worth Reading: The Insider’s Guide To Evangelizing Good Design

Scott Berkun wrote another great article that’s equally applicable to the traditional notion of design (his specialty) and the network design. Read it, replace design with network design, and use its lessons. Here’s just a sample:

• Convincing people is a social process
• Aim for small wins, not conversions of belief systems
• Allies matter more than ideas
• Design maturity grows one step at a time.

Interview: What New Technologies Should You Aim to Master?

In the last part of my chat with David Bombal we discussed interesting technologies networking engineers could focus on if they want to grow beyond pure packet switching (and voice calls, if you happen to believe VoIP is not just an application). We mentioned public clouds, automation, Linux networking, tools like Git, and for whatever reason concluded with some of my biggest blunders.