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:
In this post, we take a look at the interaction of MLAG with an EVPN based VXLAN fabric on Cumulus Linux.
MLAG or MC-LAG (multi-chassis link aggregation) is a fairly common deployment model at the access/leaf layer of both Enterprise and Data Center networks, typically offered by most leading vendors (with different terminologies - vPC, VSS, stackwise-virtual and so on).
The general idea is to offer redundancy at the access layer by pairing together two access/leaf switches into a common logical switch, from the perspective of any devices downstream. Details of Cumulus' implementation can be found here.
For this post, we're going to be using the following topology (tested with Cumulus VX 4.2):
In this post, we look at how route-targets extended communities can be used to control VXLAN BGP EVPN routes in Cumulus Linux.
This post assumes that the reader has a general understanding of L2/L3 VNIs and asymmetric/symmetric IRB.
Cumulus, by default, uses auto RTs for L2 and L3 VNIs. This makes for a very easy experience (almost plug and play like) when building VXLAN BGP EVPN fabrics. But it also doesn't help you understand much of how route-targets are being imported across and how to completely control this.
It's always good to learn to drive a stick, before moving to an automatic. So, the goal of this blog is to help understand how L2/L3 VNI RTs are exported/imported and how you can control what goes into your customer VRF. This will also allow you to control whether you want asymmetric or symmetric IRB (see my previous Cumulus blog posts to understand what is asymmetric and symmetric IRB).
In this post, we look at VXLAN routing with symmetric IRB and multi-tenancy on Cumulus Linux.
Now that we've configured and verified a working asymmetric VXLAN routing solution in the previous post, let's take a look at the greener side of the grass (well, it depends on where you stand) - symmetric IRB. This post is going to introduce VRFs into the picture that pave the way for multi-tenancy in VXLAN solutions.
We continue to use the same topology as our previous post:
In this post, we look at VXLAN routing with asymmetric IRB on Cumulus Linux.
We continue on with the same topology as the last post:
Our goal is to have PC1 talk to PC3 over the VXLAN fabric that we have built out. VXLAN routing can broadly be done using two methods - asymmetric and symmetric IRB. In this post, we will discuss the asymmetric methodology.