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!

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
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 OUI:index 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.

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

2 thoughts on “Label Switched Multicast – Configuration”

  1. A series of very good articles Joel. They are very helpful.
    Do you plan to write something similar using RSVP-TE P2MP at all?
    One more question – where does BGP with address-family ipv4 mvpn and BGP auto-discovery fit in Label Switched Multicast? I have read several post to clarify this confusion but the confusion still remains.

    Thanks a lot in advance.

    1. Hey CK,

      Thanks for the feedback.

      I wrote these articles because I was deeply involved with a customer that was using LSM. If a similar project came up where I had to learn RSVP-TE, then I could see myself writing some new articles.

      Re ipv4 mvpn: it has no bearing on LSM. In fact, the config guide (http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_mvpn/configuration/15-s/imc-mvpn-15-s-book/imc_vpn_bgp_croute.html) explicitly says that MLDP transport is not supported. Beyond that, I’m not really clear on what this ‘nextgen mvpn’ does that the other methods in that guide can’t do. It seems clear though that this MVPN and LSM are two different features and don’t overlap.

      Re BGP auto-discovery: As far as I’m aware, there is no auto-discover when using LSM. I’m not sure it would even make sense for LSM. LSM doesn’t require any additional BGP address-families to be configured beyond what you need for regular unicast L3 VPNs and all the signalling is done via LDP which, again, already has to be configured. What’s left for auto discovery to discover?

Leave a Reply

Your email address will not be published. Required fields are marked *

Would you like to subscribe to email notification of new comments? You can also subscribe without commenting.