Category: Tags

LISP

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:

add comment

EVPN

EVPN, or Ethernet Virtual Private Network, is like a smart system that helps computers and devices in a network talk to each other better. It’s like having a super organized mail system where each computer has its own address, and EVPN makes sure messages get to the right place quickly and safely. So, it’s kind of like a traffic manager for information on a computer network, making everything run smoothly and securely.

ChatGPT trying (and failing) to explain EVPN

What Is EVPN?

Before going into the technical details, let’s start with the basics: What is EVPN, how does it work, and where can you use it?

EVPN Designs

EVPN was designed to be used in an IBGP environment on top of an IGP. With the eruption of EBGP as better IGP hype, many vendors tried to adapt EVPN to an environment running EBGP instead of OSPF. We covered typical EVPN designs in these blog posts:

EVPN Implementation Details

There are tons of tiny little things that can go wrong when you try to deploy EVPN. I documented them as I stumbled upon them:

Beyond VXLAN

While EVPN is often used with VXLAN today, it was designed to work with the MPLS data plane, resulting in a few quirks:

EVPN Rants

Some vendors’ marketing engineers (or Senior Directors) can’t stand anyone telling them their implementation might be suboptimal, going to great lengths to prove to themselves they’re right, and generating beautiful fodder for rants.

Videos

You can watch numerous videos from the EVPN Technical Deep Dive webinar without an ipSpace.net account:

What Others Wrote About EVPN

Other EVPN Blog Posts

add comment

OSPF

OSPF is like a traffic director for the internet. Imagine a city with many roads - OSPF helps routers (the traffic directors) figure out the best paths for data to travel from one place to another. It’s like a smart GPS for computers, making sure information takes the shortest and fastest routes. OSPF routers talk to each other, share maps of the internet, and decide the best ways to send data. It’s a cool system that keeps the internet running smoothly!

ChatGPT explaining OSPF to a high-school kid

Configuration Tips

This blog started as a collection of (hopefully) helpful configuration tricks, and I documented numerous Cisco IOS configuration tips in the early 2000s.

Implementation Details

Let’s start with the elephant in the room: OSPF areas – a simple concept that got way too convoluted when OSPF started accreting nerd knobs like NSSA areas:

OSPF default routes are another confusing topic. You could have inter-area default routes (used in stub areas) or external default routes that could be conditional or unconditional.

OSPF adjacencies are another fun troubleshooting topic:

The inimitable forwarding address in type-5 LSA will make your head explode when combined with the NSSA areas.

Want even more OSPF details? I documented way too many of them since I started blogging, including:

Deploying OSPF

Creative networking engineers often forget an unpleasant truth: OSPF is a single security domain. You should never run it with less-trusted peers, be it your customers, data center servers, or virtual machines.

OSPF by itself is complex enough, but the real fun starts when you combine it with other protocols (for example, BGP and LDP):

Running OSPF in large hub-and-spoke networks (for example, large DMVPN networks) is another tough challenge:

While you could use OSPF to get unequal-cost multipathing, you might be tripped by numerous caveats; no wonder there are few implementations of this concept.

Finally, you can run OSPF over unnumbered interfaces, be it point-to-point serial links or Ethernet segments:

Rants

Now and then, I couldn’t resist writing an OSPF-related rant:

What Others Are Writing About OSPF

Other OSPF Blog Posts

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:

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 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:

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:

Notable Outages

Finally, here are a few notable outages. TL&DR: it can happen to the big guys and will eventually happen to you.

Other High Availability Blog Posts

2015
2014
2013
2012
add comment
Page 1 of 8
Sidebar