Must Read: Routing Will Never Be a Solved Problem

Mark Seery wrote a fantastic must-read article explaining why routing will never be a solved problem.

You might want to enjoy it as a relaxing antidote after a painful exposure to SD-WAN (or SD-something-else) brainwashing.

Video: EVPN Multihoming Deep Dive

After starting the EVPN multihoming versus MLAG presentation (part of EVPN Deep Dive webinar) with the taxonomy of EVPN-based multihoming, Lukas Krattiger did a deep dive into its intricacies including:

• EVPN route types needed to support multihoming
• A typical sequence of EVPN updates during multihoming setup
• MAC multipathing, MAC aliasing, split horizon and mass withdrawals
• Designated forwarder election

Video: EVPN Multihoming Deep Dive

After starting the EVPN multihoming versus MLAG presentation (part of EVPN Deep Dive webinar) with the taxonomy of EVPN-based multihoming, Lukas Krattiger did a deep dive into its intricacies including:

• EVPN route types needed to support multihoming
• A typical sequence of EVPN updates during multihoming setup
• MAC multipathing, MAC aliasing, split horizon and mass withdrawals
• Designated forwarder election

Rant: Cloudy Snowflakes

I could spend days writing riffs on some of the more creative (in whatever dimension) comments left on my blog post or LinkedIn¹. Here’s one about uselessness of network automation in cloud infrastructure (take that, AWS!):

If the problem is well known you can apply rules to it (automation). The problem with networking is that it results in a huge number of cases that are not known in advance. And I don’t mean only the stuff you add/remove to fix operational problems. A friend in one of the biggest private clouds was saying that more than 50% of transport services are customized (a static route here, a PBR there etc) or require customization during their lifecycle (e.g. add/remove a knob). Telcos are “worse” and for good reasons.

Yeah, I’ve seen such environments. I had discussions with a wide plethora of people building private and public (telco) clouds, and summarized the few things I learned (not many of them good) in Address the Business Challenges First part of the Business Aspects of Networking Technologies webinar.

Rant: Cloudy Snowflakes

I could spend days writing riffs on some of the more creative (in whatever dimension) comments left on my blog post or LinkedIn¹. Here’s one about uselessness of network automation in cloud infrastructure (take that, AWS!):

If the problem is well known you can apply rules to it (automation). The problem with networking is that it results in a huge number of cases that are not known in advance. And I don’t mean only the stuff you add/remove to fix operational problems. A friend in one of the biggest private clouds was saying that more than 50% of transport services are customized (a static route here, a PBR there etc) or require customization during their lifecycle (e.g. add/remove a knob). Telcos are “worse” and for good reasons.

Yeah, I’ve seen such environments. I had discussions with a wide plethora of people building private and public (telco) clouds, and summarized the few things I learned (not many of them good) in Address the Business Challenges First part of the Business Aspects of Networking Technologies webinar.

Scalability Aspects of SR-MPLS

Henk Smit left a wonderful comment discussing various scalability aspects of SR-MPLS. Let’s go through the points he made:

When you have a thousand routers in your networks, you can put all of them in one (IS-IS) area. Maybe with 2k routers as well. But when you have several thousand routers, you want to use areas, if only to limit the blast-radius.

Absolutely agree, and as RFC 3439 explained in more eloquent terms than I ever could:

Scalability Aspects of SR-MPLS

Henk Smit left a wonderful comment discussing various scalability aspects of SR-MPLS. Let’s go through the points he made:

When you have a thousand routers in your networks, you can put all of them in one (IS-IS) area. Maybe with 2k routers as well. But when you have several thousand routers, you want to use areas, if only to limit the blast-radius.

Absolutely agree, and as RFC 3439 explained in more eloquent terms than I ever could:

Worth Exploring: NetTowel

A few months ago, Urs Baumann created NetTowel, a very nice CLI wrapper around several popular libraries, including Jinja2, TTP, NetMiko and netaddr. Although it seems he got busy with other things in recent months, and the development stalled a bit, the tool is definitely worth exploring.

Worth Exploring: NetTowel

A few months ago, Urs Baumann created NetTowel, a very nice CLI wrapper around several popular libraries, including Jinja2, TTP, NetMiko and netaddr. Although it seems he got busy with other things in recent months, and the development stalled a bit, the tool is definitely worth exploring.

Could I Use netlab instead of GNS3?

I’m often getting questions along the lines of “I’m using GNS3. Could I replace it with netlab?"

TL&DR: No.

You need a set of functions to build a network lab:

• Virtualization environment (netlab supports VirtualBox, libvirt, Docker, Podman)
• An orchestration tool/system that will deploy network device images in such an environment (netlab supports Vagrant and containerlab)
• A tool that will build orchestration system configuration (netlab core functionality)

Could I Use netlab instead of GNS3?

I’m often getting questions like “I’m using GNS3. Could I replace it with netlab?”

TL&DR: No.

You need a set of functions to build a network lab:

• Virtualization environment (netlab supports VirtualBox, libvirt, Docker, and Podman)
• An orchestration tool/system that will deploy network device images in such an environment (netlab supports Vagrant and containerlab)
• A tool that will build orchestration system configuration (netlab core functionality)

Leave BGP Next Hops Unchanged on Reflected Routes

Here’s the last question I’ll answer from that long list Daniel Dib posted weeks ago (answer to Q1, answer to Q2).

I am trying to understand what made the BGP designers decide that RR should not change the BGP Next Hop for IBGP-learned routes.

Leave BGP Next Hops Unchanged on Reflected Routes

Here’s the last question I’ll answer from that long list Daniel Dib posted weeks ago (answer to Q1, answer to Q2).

I am trying to understand what made the BGP designers decide that RR should not change the BGP Next Hop for IBGP-learned routes.

History of Ethernet Encapsulations

Henk Smit conscientiously pointed out a major omission I made when summarizing Peter Paluch’s excellent description of how bits get parsed in network headers:

EtherType? What do you mean EtherType? There are/were 4 types of Ethernet encapsulation. Only one of them (ARPA encapsulation) has an EtherType. The other 3 encapsulations do not have an EtherType field.

What is he talking about? Time for another history lesson¹.

History of Ethernet Encapsulations

Henk Smit conscientiously pointed out a major omission I made when summarizing Peter Paluch’s excellent description of how bits get parsed in network headers:

EtherType? What do you mean EtherType? There are/were 4 types of Ethernet encapsulation. Only one of them (ARPA encapsulation) has an EtherType. The other 3 encapsulations do not have an EtherType field.

What is he talking about? Time for another history lesson¹.

Network Automation Considered Harmful

Some of the blog comments never cease to amaze me. Here’s one questioning the value of network automation:

I think there is a more fundamental reason than the (in my opinion simplistic) lack of skills argument. As someone mentioned on twitter

“Rules make it harder to enact change. Automation is essentially a set of rules.”

We underestimated the fact that infrastructure is a value differentiator for many and that customization and rapid change don’t go hand in hand with automation.

Whenever someone starts using MBA-speak like value differentiator in a technical arguments, I get an acute allergic reaction, but maybe he’s right.

Network Automation Considered Harmful

Some of the blog comments never cease to amaze me. Here’s one questioning the value of network automation:

I think there is a more fundamental reason than the (in my opinion simplistic) lack of skills argument. As someone mentioned on twitter

“Rules make it harder to enact change. Automation is essentially a set of rules.”

We underestimated the fact that infrastructure is a value differentiator for many and that customization and rapid change don’t go hand in hand with automation.

Whenever someone starts using MBA-speak like value differentiator in a technical arguments, I get an acute allergic reaction, but maybe he’s right.

Use VRFs for VXLAN-Enabled VLANs

I started one of my VXLAN tests with a simple setup – two switches connecting two hosts over a VXLAN-enabled (gray tunnel) red VLAN. The switches are connected with a single blue link.

I configured VLANs and VXLANs, and started OSPF on S1 and S2 to get connectivity between their loopback interfaces. Here’s the configuration of one of the Arista cEOS switches:

Use VRFs for VXLAN-Enabled VLANs

I started one of my VXLAN tests with a simple setup – two switches connecting two hosts over a VXLAN-enabled (gray tunnel) red VLAN. The switches are connected with a single blue link.

I configured VLANs and VXLANs, and started OSPF on S1 and S2 to get connectivity between their loopback interfaces. Here’s the configuration of one of the Arista cEOS switches:

EVPN Multihoming: Taxonomy and Overview

I promised you a blog post explaining the intricacies of implementing MLAG with EVPN, but (as is often the case) it’s taking longer than expected. In the meantime, enjoy the EVPN Multihoming Taxonomy and Overview video from Lukas Krattiger’s EVPN Multihoming versus MLAG presentation (part of EVPN Deep Dive webinar).