Building network automation solutions

The netlab tool will help you be more proficient once you decide to drop GUI-based network simulators and build your labs using CLI and infrastructure-as-code principles.

In September 2020, Matthias Luft wrote an introductory article describing host-based firewalls (traffic filtering functionality deployed on end-hosts). His article triggered numerous questions including:

• Why don’t we have dynamic firewall policies where the end-hosts could specify which TCP/UDP ports they need?
• Can we use traffic flow analysis to reverse-engineer firewall rules?
• Is there any chance of fixing this problem?

Networking vendors love promoting novel overly complex technologies instead of solving their customers' challenges with good network design. High-availability switching (the ability to continue packet forwarding during a control plane failure) is no exception.

Multi-Chassis Link Aggregation (MLAG) is a solution that allows you to terminate a link aggregation group (sometimes also known as etherchannel) on multiple devices.

It’s often used to implement redundant server connections; it was also popular in the days of layer-2 fabrics built with Spanning Tree Protocol (STP). The latter use case is mostly obsolete in the VXLAN/EVPN world.

What Is Multi-Chassis Ling Aggregation?

• Multi-Chassis Link Aggregation (MLAG) Basics
• Multi-Chassis Link Aggregation (MLAG) and Hot Potato Switching
• MLAG and Load Balancing

Technology Deep Dive

• System Overview
• Dynamic MAC Learning
• Layer-2 Flooding
• Layer-3 Forwarding
• Combining MLAG Clusters with VXLAN Fabric
• Using EVPN/VXLAN with MLAG Clusters
• Running Routing Protocols over MLAG Links

Coming soon

• Replacing Peer-Link with VXLAN Fabric

Design Guidelines

• Don’t Try to Fake Multi-chassis Link Aggregation (MLAG)
• Stackable Data Center Switches? Do the Math!
• vSphere Does Not Need LAG Bandaids – the Network Might
• Is MLAG an Alternative to Stackable Switches?
• Don't Base Your Design on Vendor Marketing
• Should I Go with VXLAN or MLAG with STP?
• BGP AS Numbers on MLAG Members
• EVPN/VXLAN or Bridged Data Center Fabric?

MLAG Implementations

• Multi-chassis Link Aggregation: Stacking on Steroids
• External Brains Driving an MLAG Cluster
• Intelligent Redundant Framework (IRF) – Stacking as Usual
• Auto-MLAG and Auto-BGP in Cumulus Linux

Using MLAG on Server-to-Network Links

• vSwitch in Multi-chassis Link Aggregation (MLAG) environment

Videos

• EVPN Multihoming Taxonomy and Overview
• EVPN Multihoming Deep Dive
• MLAG with EVPN

In release 1.3, we renamed netsim-tools to netlab.

You’ll find the netlab-related blog posts here.

Based on exorbitant claims made by the industry press you might have concluded there must be some revolutionary concepts in the OpenFlow technology. Nothing could be further from the truth – OpenFlow is a very simple technology that allows a controller to program forwarding entries in a networking device.

Did you ever encounter Catalyst 5000 with Route Switch Module (RSM), or a combination of Catalyst 5000 and an external router, using Multilayer Switching (MLS)? Those products used architecture identical to OpenFlow almost 20 years ago, the only difference being the relative openness of OpenFlow protocol.

The blog posts in this section answer a number of basic OpenFlow questions, including:

• What is OpenFlow?
• What can different versions of OpenFlow do?
• How can a controller implement control-plane protocols (like LACP, STP or routing protocols) … and does it have to?
• Can we deploy OpenFlow in combination with traditional forwarding mechanisms?

For more details, watch OpenFlow Deep Dive and other ipSpace.net SDN webinars.

What Is OpenFlow?

• Management, Control, and Data Planes in Network Devices and Systems
• What Exactly Is The Control Plane?
• What is OpenFlow?
• What Is OpenFlow (Part 2)?
• Is OpenFlow Useful?

Using OpenFlow

• OpenFlow Deployment Models
• Forwarding Models in OpenFlow Networks

Does OpenFlow Make Sense?

• You Don’t Need OpenFlow to Solve Every Age-Old Problem
• OpenFlow and Ipsilon: Nothing New Under the Sun
• OpenFlow: BIOS Does Not a Server Make
• SDN Controller Northbound API Is the Crucial Missing Piece
• Is OpenFlow the Best Tool for Overlay Virtual Networks?

Academic researchers were working on OpenFlow concepts (distributed data plane with centralized controller) for years, but in early 2011 a fundamental marketing shift happened: major cloud providers (Google) and Internet Service Providers (Deutsche Telekom) created Open Networking Foundation (ONF) to push forward commercial adoption of OpenFlow and Software Defined Networking (SDN) – or at least their definition of it.

Since then, every networking vendor started offering SDN products. Almost none of them come even close to the (narrow) vision promoted by the Open Networking Foundation (centralized control plane with distributed data plane), the only commercialized exceptions were NEC’s ProgrammableFlow and Big Switch Network’s Big Cloud Fabric.

Most vendors decided it’s easier to SDN-wash their existing products, branding their existing APIs Open, and claiming they have SDN-enabled products.

Initial SDN Hype

• Open Networking Foundation – Fabric Craziness Reaches New Heights
• OpenFlow FAQ: Will the Hype Ever Stop?
• OpenFlow Is Like IPv6
• For the Record: I Am Not Against OpenFlow ...
• Network Field Day 2 and OpenFlow Symposium
• I Apologize, but I’m Excited

Looking Back

• OpenFlow and SDN: Two Years after ONF Launch
• Control and Data Plane Separation – Three Years Later
• Networking Hardware/Software Disaggregation in 2022
• SDN Controller Taxonomy
• Is OpenFlow Still Kicking?

It's Hard to Fight Large Marketing Budgets

• Fallacies of GUI
• Where’s the Revolutionary Networking Innovation?
• Two and a Half Years after OpenFlow Debut, the Media Remains Clueless

Open Networking Foundation (ONF – launched in March 2011) quickly defined Software Defined Networking (SDN) as architecture with centralized control plane that controls multiple physically distinct devices.

That definition perfectly matched the needs of the ONF founding members (Google), but is it relevant to the networking community at large? Or does it make more sense to focus on network programmability and automation, or using existing protocols (BGP) in novel ways?

This section contains my introductory posts on the SDN-related topics, musings on what makes sense, and a few thoughts on career changes we might experience in the upcoming years. You’ll find more details in subsequent sections, including an overview of OpenFlow, in-depth analysis of OpenFlow-based architectures, some real-life OpenFlow and SDN deployments, and alternate approaches to SDN.

For even more details, watch the ipSpace.net SDN webinars, including:

• Introduction to Software Defined Networking
• OpenFlow Deep Dive
• SDN Architectures and Deployment Considerations
• SDN Use Cases

What Exactly Is SDN?

• How Did Software Defined Networking Start?
• What Exactly Is SDN (And Does It Make Sense)?
• Does Centralized Control Plane Make Sense?
• Benefits of SDN (or: SDN is like IPv6)

Tangential Thoughts

• We Had SDN in 1993 … and Didn’t Know It
• Still Waiting for the Stupid Network
• Is CLI In My Way … or Is It Just a Symptom of a Bigger Problem?
• OpenFlow and SDN – Do You Want to Build Your Own Racing Car?
• SDN, Windows and Fruity Alternatives
• Response: SDN’s Casualties
• SDN, Career Choices and Magic Graphs