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!

Configuring the Provider Network

In order to keep this post on point, I'm going to start on the basis that basic routing, LDP and MP-BGP are already configured and that unicast traffic is successfully flowing between all CEs.

The basic topology being used here is the same as the one in the introduction post:

Sample LSM Topology

Within the provider's network the configuration is really straightforward: there's actually nothing to do. Remember from the introduction post that LSM doesn't use any additional control plane protocols in the MPLS network. LSM also doesn't require any special configuration of LDP or BGP. The only requirement that needs to be met is that the PE and P routers are all running software that supports the multicast extensions to LDP (aka, mLDP).

You can find information on which versions and trains of Cisco IOS support mLDP by using the Cisco Feature Navigator (www.cisco.com/go/fn) and searching for a feature called "MLDP-Based MVPN" or "Label Switched Multicast (LSM) Multicast Label Distribution Protocol (mLDP) based Multicast VPN (mVPN) support".

All configuration related to LSM is actually done on the PEs within the VRF(s) that need to carry multicast traffic.

Configuring a VRF for LSM

Configuring a VRF can be broken down into three steps:

  1. Configuring the VPN ID
  2. Configuring the root of the Default Multicast Distribution Tree (MDT) (aka, the Multipoint-to-Multipoint [MP2MP] tree)
  3. Enable creation of Data MDTs (aka, the Point-to-Multipoint [P2MP] trees)

The VPN ID

The VPN ID is a unique identifier for each VPN in the MPLS network. It's used to build the opaque value_ that PEs use when signaling their intention to join a P2MP tree. When the PE that's initiating the join includes the VPN ID in their LDP messages, the receiving PEs can identify which VPN the sender is interested in.

The VPN ID is configured with the vpn id <em>OUI</em>:<em>index</em> command. The OUI is typically the same value across all VRFs and can be set to the ASN that the PEs belong to. The index is a value that's unique to every VRF, but for any given VRF, has the same value on every PE.

Example:

vrf definition BLUE
 vpn id 65535:10

In this example, I used 65535 as the OUI (which is the same as the ASN in the demo network) and arbitrarily chose 10 as the index for VRF BLUE.

I'm using the vrf definition syntax to define the VRFs in this sample network. The commands in this post work just fine with the ip vrf syntax as well.

The Default Tree Root

The root of the Default MDT needs to be statically defined on all PEs. The root doesn't have to be a PE β€” it could be a P router β€” but all PEs must be configured with the same root IP address. The root node itself doesn't really take on any additional responsibility; it does not hold more multicast state, but it does hold some additional labels in the MPLS LIB/LFIB. Mostly the root just exists because the Default MDT has to be rooted somewhere.

The root is configured on all of the PEs with the mdt default mpls mldp <ip> command. And that's it. Nothing needs to be explicitly configured on the root node itself.

Example:

vrf definition BLUE address-family ipv4
  mdt default mpls mldp 192.168.255.10

In the sample network, the P router (192.168.255.10) is the Default MDT root.

Enabling Data MDTs

The Data MDTs are spawned on demand and are automatically rooted at the PE where the multicast traffic is entering the MPLS network. As such, no explicit root needs to be configured.

By default, IOS will not create any Data MDTs and will leave all traffic on the Default MDT.

To enable Data MDTs, tell IOS the maximum number of trees it's allowed to create:

vrf definition BLUE address-family ipv4
  mdt data mpls mldp 10

In this case I've arbitrarily picked a max number of 10.

General Multicast Config

Aside from the LSM-specific configurations, the PEs also need general multicast configuration, such as:

Enabling multicast in the VRF:

ip multicast-routing vrf BLUE

Configuring the rendezvous point address (assuming PIM-SM or Bidir-PIM):

ip pim vrf BLUE rp-address <ip>

Enabling IGMP on the interfaces towards the CEs (the way you enable IGMP is by enabling PIM on the interface; there is no explicit way to enable just IGMP):

interface ethX/Y
 ip pim passive

Summary

Even though LSM might seem daunting at first, it's really very simple and easy to configure. Since LSM leverages the same control and data plane mechanisms as unicast MPLS, the LSM config just builds on what's already there from a unicast MPLS perspective.

Here is a summary of the LSM/multicast config for the PEs in the sample network:

vrf definition BLUE
 vpn id 65535:10
 address-family ipv4
  mdt default mpls mldp 192.168.255.10
  mdt data mpls mldp 10

ip multicast-routing vrf BLUE
ip pim vrf BLUE rp-address 192.168.254.100

int eth0/0.10
 ip pim passive

In the next article in this series on LSM, I will do a packet walk of multicast traffic entering the MPLS network, crossing the Default MDT and then observing the switchover to a Data MDT.

Update Jan 11 2018: Thanks to a request from a reader, I realized I hadn't posted the full running-config from the topology anywhere. You can now find them here.


Disclaimer: The opinions and information expressed in this blog article are my own and not necessarily those of Cisco Systems.