In this post, we take a detailed look at the L2 handoff feature in Cisco's SD-Access.
Fair warning - this is going to be a long, long post. Get yourself some coffee because you're going to be here for a while!
We're going to continue working with the following topology for this post, with a legacy network added to the existing infrastructure:
In this post, we look at why SD-Access borders have the anycast IP addresses configured as loopback addresses.
Looking at the some of the configuration that is automatically pushed from DNAC, you should spot some very interesting things in there. This post aims to demystify these and help the reader understand why these were needed in the first place, hopefully giving you a better understanding of how the SDA fabric is built.
Let's consider the following topology for this:
In this post, we look at various DHCP challenges in Cisco's SD-Access fabric and how it is solved.
Remember that in SD-Access, we do not use vanilla LISP. To achieve macro segmentation, multi-instance LISP (VRF-aware LISP) is used. However, this poses a problem for DHCP. Consider the following topology for this (this topology is also a simple example of SD-Access design):
In this post, we look at multi-instance LISP, which is another core construct for Cisco's SD-Access.
We're slowly getting closer to the true implementation of LISP in Cisco's SD-Access. LISP has the capability of being VRF-aware - this is achieved via multi-instance LISP.
The idea is fairly simple - you have multiple instances of LISP (mapped to corresponding VRFs) - all your LISP tables are now maintained per instance.
We will be using the following topology for this:
In this post, we look at SMRs and how these are essential for a host mobility event, within the LISP architecture.
We start this post with the assumption that a host mobility event has occurred (see previous post for details on host mobility) and that the EID 1.1.1.1/24 is moved from behind xTR2 to behind xTR6.
The state of the topology is like so:
In this post, we look at an actual LISP host mobility event and what happens behind the scenes to make this work.
Continuing on from the previous post, we take a look at actual host mobility events and how the LISP infrastructure facilitates this. Our goal for this post is to have the simulated host (1.1.1.1) move from behind xTR2 to behind xTR4 (simulated via R10). A working assumption used in the post is that there is no active traffic destined for the host that is moving (we will look at this in the SMR post).
The topology is a slightly modified version of what we used in the last post:
In this post, we look at LISP dynamic EID - a core construct of LISP host mobility.
One of the most important characteristics of LISP is the mobility it offers - the next few posts aim at helping understand how this functionality is achieved, starting with dynamic EIDs.
We will continue using the same topology as before, with some minor changes to the xTRs. xTR6 is now another xTR and not a PxTR.
In this post, we look at how a LISP site talks to non-LISP sites.
Understanding how a LISP site talks to a non-LISP site (and vice versa) is very crucial to LISP and the bigger picture that we're building towards - SDA.
The topology that we'll work with is a slightly modified version of what we had before - another router has been added that will facilitate conversation between LISP and non-LISP:
In this post, we introduce basic LISP configuration and operation using packet captures and packet walks.
Now that we've covered this new routing paradigm that LISP introduces in the previous post and understood some commonly used terms, we will move on to basic LISP operations.
The topology that we will be using is the following:
This is a new series that will cover Cisco's Software Defined Access architecture/solution over time. There are several moving pieces to this - in this post, we're going to start with a key component, which is LISP.
This is a new series that will cover Cisco's Software Defined Access architecture/solution over time. There are several moving pieces to this - we're going to start with a key component, which is LISP.
LISP stands for Locator/ID Separation protocol. Let's quickly revisit how endpoints are/were identified - with a simple IP address (IPv4/IPv6, what have you). The IP address was both the location and the identity of the endpoint. LISP (which serves as a routing architecture), aims to decouple the identity of an endpoint from its location.
The IP address continues to be the identity of the endpoint however, its location is now advertised as a separate entity (or address space) as well.
A simple visual comparison helps understand this better:
