If you're an IT professional and you have at least a minimal awareness of what Cisco is doing in the market and you don't live under a rock, you would've heard about the major launch that took place in June: "The network. Intuitive." The anchor solution to this launch is Cisco's Software Defined Access (SDA) in which the campus network becomes automated, highly secure, and highly scalable.
The launch of SDA is what's called a "Tier 1" launch where Cisco's corporate marketing muscle is fully exercised in order to generate as much attention and interest as possible. As a result, there's a lot of good high-level material floating around right now around SDA. What I'm going to do in this post is lift the hood on the solution and explain what makes the SDA network fabric actually work.
This post is the last one I'm planning in this series on Label Switched Multicast (LSM). The questions & answers below are meant to expand on topics from the previous posts or address topics that weren't mentioned in the previous posts at all.
If you're not familiar with LSM yet then this Q&A likely won't make much sense to you and I recommend you go back and read through the previous posts.
Please post a comment if one of the answers isn't clear or you have additional questions!
This post is going to follow a multicast packet as it moves through a sample MPLS network using Label Switched Multicast (LSM). I'll show how the packet moves through the network by looking at the forwarding tables on different routers and also by doing some packet captures.
This post is part of a series I'm writing on LSM and if you're not already familiar with LSM, I recommend you go back and read the previous posts.
After reading this post you will be able to precisely describe how LSM forwarding works in the data plane and will be able to do some basic troubleshooting.
Let's get into the lab!
In the previous post (Label Switched Multicast - An Introduction) in this series on Label Switched Multicast (LSM) I introduced the concepts behind LSM and draft-rosen, the two most poplar methods for transporting multicast traffic through MPLS Layer 3 VPNs.
In this article I will talk through the configuration of LSM on the PE and P routers and get to the point where two CEs are successfully passing multicast traffic via the MPLS network. All of the configuration examples will be relevant to Cisco IOS.
As was the case in the introduction article in the series, it's best if you already have a good understanding of multicast and MPLS before reading this article.
At the end of this article you'll be able to start configuring your own LSM environment using the configuration samples here as a template.
To the CLI!
There are two common methods for transporting multicast packets within an MPLS-based Layer 3 VPN:
- Generic Routing Encapsulation (GRE) with Protocol Independent Multicast (PIM) (also known as "draft-rosen")
- Label Switched Multicast (LSM)
There's also a third method which uses Resource Reservation Protocol-Traffic Engineering (RSVP-TE) but I'm not going to get into that one.
In this first post in a series on LSM, I'll describe how draft-rosen works, how LSM works, and then compare and contrast the two. Subsequent posts will focus solely on LSM.
At the end of this post, you will be able to describe conceptually how the control and data planes work with LSM and what the pros and cons are of LSM as compared to draft-rosen.
I will not be covering any theory on multicast or MPLS and will instead recommend that you be familiar with both topics before reading further.
Here we go!
Let's step back for a minute. So far in this series of blog posts on DCI, I've been focusing on extending the Layer 2 domain between data centers with the goal of supporting hot migrations — ie, moving a virtual machine between sites while it's online and servicing users.
Is that the only objective with DCI?
Here's a topic that comes up more and more now that FabricPath is getting more exposure and people are getting more familiar with the technology: Can FabricPath be used to interconnecting data centers?
For a primer on FabricPath, see my pervious article Five Functional Facts about FabricPath .
FabricPath has some characteristics that make it appealing for DCI. Namely, it extends Layer 2 domains while maintaining Layer 3 — ie, routing — semantics. End host MAC addresses are learned via a control plane, FP frames contain a Time To Live (TTL) field which purge looping packets from the network, and there are no such thing as blocked links — all links are forwarding and Equal Cost Multi-Pathing (ECMP) is used within the fabric. In addition, since FabricPath does not mandate a particular physical network topology, it can be used in spine/leaf architectures within the data center or point-to-point connections between data centers.
Sounds great. Now what are the caveats?
In the previous article in this DCI series (Why is there a "Wrong Way" to Interconnect Datacenters?) I explained the business case for having multiple data centers and then closed by warning that extending Layer 2 domains was a path to disaster and undermined the resiliency of having two data centers.
Why then is stretching Layer 2 a) needed and b) a go-to maneuver for DCI.
Let's look at it from two points of view: technology and business.
There's certainly a lot of focus on data center interconnection (DCI) right now. And understandably so since there are many trends in the industry that are making IT organizations look at data center redundancy. Among these trends are:
- The business is saying to IT that they require their IT services to be available at all times. In effect the business is saying that they want to be shielded from technology issues, maintenance windows, and unplanned downtime because the IT services they consume (not all of them mind you, but certainly some of them) are so critical to running the business that they cannot be without them (or, they cannot be without them for whatever period of time it would take IT to recover the service).
- The technical ability to move workloads between sites thanks to the near ubiquity of features like vMotion and Live Migration. The ability to pick up an application and swing it over to another location makes item #1 above far less daunting to IT shops and lowers the barrier to adoption.
In this post I'm going to talk about how IT can address item #1 above — the business need — in a manner that does not introduce hidden risk into the environment. This is a common conversation that a lot of IT organizations are having right now but unfortunately the easiest and most obvious outcome from those conversations is not always the one with the least risk.
In the second post of this DCI mini series, I'll talk more about item #2 since that's the one that drives a lot of the technical requirements that have to be met when delivering the overall solution to address #1.