Tag Archives: mpls

Label Switched Multicast – Ethernet Header

I got an interesting email from Ying Lu who had read my posts on LSM:

I am curious about the Ethernet DA and codepoint used for multicast MPLS. Previously, I understand that:
– Ethernet DA is unicast MAC of nexthop of each replication leg.
– codepoint is 0x8847
However, looking at RFC5332, I am not so sure…
Quote:
“Ethernet is an example of a multipoint-to-multipoint data link. Ethertype 0x8847 is used whenever a unicast ethernet frame carries an MPLS packet.

Ethertype 0x8847 is also used whenever a multicast ethernet frame carries an MPLS packet, EXCEPT for the case where the top label of the MPLS packet has been upstream-assigned.

Ethertype 0x8848, formerly known as the “MPLS multicast codepoint”, is to be used only when an MPLS packet whose top label is upstream assigned is carried in a multicast ethernet frame.

Interesting question. What is the ethernet destination address (DA) and the value of the ethernet type field (codepoint) when the MPLS packet is being sent on an LSM LSP?

Getting back into the lab, I started a ping from CE1 to a group that CE3 had joined. I then ran a sniff on the segment between P and PE3.

Sample LSM Topology
Sample LSM Topology

Examining the capture shows a unicast address in the ethernet DA field and an ethernet type of 0x8847.

LSM-ethernet-da
LSM Ethernet Dest Address and Type

I started wondering if I could trick the P router into using a multicast ethernet frame so I spun up a fourth PE and attached it to the same segment that P and PE3 are on and had it join the same multicast group.

The P router continued to send unicast ethernet frames with a type of 0x8847 and just started putting two frames on the wire, one for PE3 and one for PE4. It did not, as I had hoped, put a multicast ethernet frame on the wire that would be picked up by both PEs.

So it appears that IOS — and I tested this with a version of IOS 15.4T — sends unicast ethernet frames when sending LSM packets and therefore also uses an ethernet type code of 0x8847.

Label Switched Multicast – Q&A

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! Continue reading Label Switched Multicast – Q&A

Label Switched Multicast – Packet Walk

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!

Continue reading Label Switched Multicast – Packet Walk

Label Switched Multicast – Configuration

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! Continue reading Label Switched Multicast – Configuration

Label Switched Multicast – An Introduction

There are two common methods for transporting multicast packets within an MPLS-based Layer 3 VPN:

  1. Generic Routing Encapsulation (GRE) with Protocol Independent Multicast (PIM) (also known as “draft-rosen”)
  2. 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!

Continue reading Label Switched Multicast – An Introduction

The Correct Mask for a PE’s Loopback0

As I’ve written about previously (The Importance of BGP NEXT_HOP in L3VPNs), the BGP NEXT_HOP attribute is key to ensuring end to end connectivity in an MPLS L3VPN. In the other article, I examine the different forwarding behavior of the network based on which of the egress PE’s IP addresses is used as the NEXT_HOP. In this article I’ll look at the subnet mask that’s associated with the NEXT_HOP and the differences in forwarding behavior when the mask is configured to different values.

There is a lot of (mis-)information on the web stating that the PE’s loopback address — which, as I explain in the previous article, should always be used as the NEXT_HOP — must have a /32 mask. This is not exactly true. I think this is an example of some information that has been passed around incorrectly, and without proper context, and is now taken as a rule. I’ll explain more about this further on in the article.

Continue reading The Correct Mask for a PE’s Loopback0

The Importance of BGP NEXT_HOP in L3VPNs

In an MPLS network with L3VPNs, it’s very easy for the NEXT_HOP attribute of a VPN route to look absolutely correct but be very wrong at the same time. In a vanilla IP network, the NEXT_HOP can point to any IP address that gets the packets moving in the right direction towards the ultimate destination. In an MPLS network, the NEXT_HOP must get the packets moving in the right direction but it must also point to the exact right address in order for traffic to successfully reach the destination.

Continue reading The Importance of BGP NEXT_HOP in L3VPNs

MPLS “No Label” vs “Pop Label”

I like MPLS. And I don’t necessarily mean as a solution to solve a problem, but as something to configure in the lab. It’s fun to build things that do something when you’re done. Setting up OSPF or EIGRP and being able to traceroute across routers is meh. But configuring MPLS with all the associated technologies — an IGP, LDP, MP-BGP, — and then getting all of them working in unison… when you get the traceroute working, it’s rewarding.

Here’s something to keep an eye out for when you’re troubleshooting MPLS: An LFIB entry (that is, the Label Forwarding Information Base) that states “No Label” versus one that states “Pop Label”. These mean very different things and can be the difference between a working Label Switched Path (LSP) and a non-working LSP. Continue reading MPLS “No Label” vs “Pop Label”

Walking with Packets: Traceroute Through MPLS Cloud

Think about this for a minute: An MPLS network with a two Provider Edge (PE) routers and some Provider (P) routers. The P routers have no VRFs configured on them and therefore have no routes whatsoever for any of the customer networks. A customer then does a traceroute from one of their sites, across the MPLS cloud, and into one of their other sites. The traceroute output shows the P routers as hops along the path.

How is it possible for the P routers to reply to the traceroute if they don’t have routes back to the customer network?

Continue reading Walking with Packets: Traceroute Through MPLS Cloud