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!

How can the mapping between a (*,G) or (S,G) and a Multicast Distribution Tree be found?⌗

If you have a (*,G) or an (S,G), the following commands will show you which MDT is being used through the MPLS core. I find the easiest place in the network to check the mapping between a (*,G) or (S,G) and an MDT is on the Ingress PE. Two tables hold the mapping:

1 - the MFIB:

PE1#show ip mfib vrf BLUE 239.3.3.3
[...]
VRF BLUE
 (*,239.3.3.3) Flags: C
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   Tunnel0 Flags: A
   Lspvif0, LSM/2 Flags: F NS
     Pkts: 0/0
 (192.168.1.10,239.3.3.3) Flags: ET
   SW Forwarding: 5/0/100/0, Other: 1/0/1
   Ethernet0/0.10 Flags: A
   Lspvif0, LSM/32 Flags: F NS
     Pkts: 0/0

2 - the MRIB:

PE1#show ip mroute vrf BLUE 239.3.3.3 verbose
IP Multicast Routing Table
[...]
(*, 239.3.3.3), 1d01h/stopped, RP 192.168.254.100, flags: Sp
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Lspvif0, LSM MDT: 2 (default), Forward/Sparse, 1d01h/00:03:05, p

(192.168.1.10, 239.3.3.3), 00:00:20/00:02:39, flags: TAyp
  Incoming interface: Ethernet0/0.10, RPF nbr 0.0.0.0
   MDT TX nr: 1  LSM-ID: 0x32
  Outgoing interface list:
    Lspvif0, LSM MDT: 32 (data), Forward/Sparse, 00:00:20/00:03:11, p

Both tables show the same mapping:

  • The (*,G) is using the default, MP2MP tree with MDT index 0x2
  • The (S,G) is using a data, P2MP tree with MDT index 0x32

Now that the MDT index is known, how can the MDT be inspected?⌗

The MDT is an MPLS construct and as such can be inspected by looking at the MPLS database and using the MDT index as a search key. Use this command on the Ingress PE since that's the PE that was used in the question above when finding the MDT index.

PE1#show mpls mldp database id 32
LSM ID : 32   Type: P2MP   Uptime : 00:00:05
  FEC Root           : 192.168.255.1 (we are the root)
  Opaque decoded     : [mdt 65535:10 1]
  Opaque length      : 11 bytes
  Opaque value       : 02 000B 0655350000001000000001
  Upstream client(s) :
    None
      Expires        : N/A           Path Set ID  : 32
  Replication client(s):
    MDT  (VRF BLUE)
      Uptime         : 00:00:05      Path Set ID  : None
      Interface      : Lspvif0       192.168.255.10:0
      Uptime         : 00:00:05      Path Set ID  : None
      Out label (D)  : 28            Interface    : Ethernet0/1*
      Local label (U): None          Next Hop     : 10.1.1.10

This output shows the in/out label information, in/out interface information, the MDT type, and MDT root.

How can the mapping between incoming MPLS labels and an (S,G) be found on the Egress PE?⌗

I actually don't know the answer to this. I haven't found a way. If you have any ideas, please post a comment.

How can the root of a given MDT be found?⌗

By inspecting the mLDP database and/or binding table.

PE3#show mpls mldp database id 33
LSM ID : 33   Type: P2MP   Uptime : 00:00:26
  FEC Root           : 192.168.255.1
[...]

PE3#show mpls mldp bindings
System ID: 34
Type: P2MP, Root Node: 192.168.255.1, Opaque Len: 14
Opaque value: [mdt 65535:10 1]
lsr: 192.168.255.10:0, local binding[D]: 33 active
[...]

Why isn't any multicast traffic getting through? (Unicast works fine)⌗

Check that every PE has the same IP address configured for the root of the default MDT. Every PE must be configured for the same root otherwise control plane signalling will be broken and the forwarding tables will not be built correctly.

How does Penultimate Hope Popping work in LSM?⌗

Easy answer: there is no PHP in LSM.

The Egress PE always receives a labeled MPLS packet which causes the PE to perform two operations on the packet:

  1. Look up the incoming label in the LFIB. Result -> strips all labels off the packet and finds the right VRF to route the inner IP packet.
  2. Performs an IP routing lookup in the VRF from step 1. Result -> routes the IP packet out an interface that's bound to the VRF.

Are the PEs PIM neighbors with each other?⌗

Yes, the PEs form PIM neighborships across MPLS cloud via the Lspvif pseudo interface. This allows the PEs to exchange PIM messages via the standard All-PIM-Routers address (224.0.0.13). Messages to this group are carried via the MP2MP tree.

PE1#show ip pim vrf BLUE neighbor
[...]
Neighbor          Interface     [...]
Address
192.168.255.3     Lspvif0       [...]
192.168.255.2     Lspvif0       [...]

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