Tags « ipSpace.net blog

LISP is a networking technology that has been searching for a relevant problem for a decade and a half (the LISP IETF working group started in the spring of 2009). Initially, I was cautiously optimistic. However, as LISP pivoted from an IPv6-over-IPv4 solution to a multihoming solution, then VM mobility and IP endpoint mobility solution, until it finally landed in Cisco Campus BU as the foundational technology of Software-Defined Access, I lost all hope.

LISP started as a DNS-like cache-based packet forwarding technology. Eventually, reality intervened, and the LISP believers rediscovered the flaws of cache-based forwarding. It looks like LISP pivoted to become a topology-driven PUB-SUB protocol. Assuming that’s correct, there’s little conceptual difference between LISP and EVPN. It’s just a question of defining a suitable set of policy mechanisms and developing an optimal implementation.

Discussing the benefits and drawbacks of LISP or EVPN thus makes as much sense as debating the number of angels dancing on the head of a pin, but that has never stopped people from doing one or the other.

Just in case you want to know more, you will find some details in the LISP-related blog posts I wrote since 2010:

Introduction to LISP (2010)
VXLAN, OTV and LISP (2011)
We Just Might Need NAT66/NPT66 (and Not LISP) (2011)
Networking Tech Field Day #3: First Impressions (2012)
Mobile ARP in Enterprise Networks (2012)
Hot and Cold VM Mobility (2013)
VXLAN and OTV: The Saga Continues (2014)
Why Is Cisco Pushing LISP in Enterprise Campus? (2017)
When All You Have Are Stretched VLANs... (2020)
Grasp the Fundamentals before Spreading Opinions (2020)
Packet Forwarding 101: Header Lookups (2022)
Cache-Based Packet Forwarding (2022)
Repost: LISP Is a False Economy (2022)
Should We Use LISP? (2022)
So-Called Modern VPNs: Marketing and Reality (2022)
Multihoming Cannot Be Solved within a Network (2022)
LISP vs EVPN: Mobility in Campus Networks (2024)
Repost: The Real LISP Mobility Use Case (2024)
Repost: State of Lisp Implementations (2024) (2024)

add comment

firewall

add comment

high availability

High availability refers to the ability of a system or application to keep running even if there is a problem or failure. This is important because if a system or application goes down, it can cause problems for those who rely on it. To achieve high availability, multiple copies of the system or application are set up in different locations so that if one fails, the others can take over and keep things running smoothly. This helps ensure that the system or application is always available when needed.

ChatGPT explaining application high availability to a high school kid

Before going into the details, it’s worth figuring out what the application (or system) users need as opposed to what they think they need:

Fifty Shades of High Availability (2020)
Figure Out What the Customer Really Needs (2017)
Are Business Needs Just Excuses for Vendor Shenanigans? (2020)
Redundancy Does Not Result in Resiliency (2017)
High Availability Planning: Identify the Weakest Link (2016)
Meaningful Availability (2020)
Differential Availability (2020)

Not surprisingly, IT vendors sell magic infrastructure solutions as the high-availability panacea based on the assumption that redundant infrastructure cannot fail. Nothing could be further from the truth:

High Availability Fallacies (2011)
If Something Can Fail, It Will (2012)
How Hard Is It to Think about Failures? (2016)
This Is What Makes Networking So Complex (2013)
Decide How Badly You Want to Fail (2019)
Sometimes You Have to Decide How You Want to Fail (2015)
Some People Don’t Get It: It Will Eventually Fail (2016)
The Network Is Reliable and Other Stories (2016)
Circular Dependencies Considered Harmful (2021)

High Availability Concepts, Technologies, and Solutions

You can use a plethora of approaches depending on your availability targets:

Disaster recovery is the right tool for the job if you’re OK with the system being down for a few hours.
Automatic restart of application instances combined with disaster recovery is acceptable if you can accept your system to be down ~0.1% of the time (99.9% availability)
Availability targets higher than 99.9% can only be reached reliably with proper application design supported by well-designed infrastructure.

I wrote over 130 blog posts on these topics. It would be impossible to list all of them on a single page; major high-availability technologies or concepts thus have dedicated pages:

One of the prerequisites for highly available services is also redundant networking infrastructure:

Redundant Data Center Internet Connectivity – Problem Overview (2013)
Redundant Data Center Internet Connectivity – High-Level Design (2013)
Coping with Byzantine Routing Failures (2014)
Site and Host Multihoming (2023)
High Availability Switching (2024)

Regardless of your approach, the only sustainable way to get highly available services is the correct design of the application stack. For more details, watch the Designing Active-Active and Disaster Recovery Data Centers webinar; I also wrote a few blog posts on the topic: