Category: Multicast

Key Concepts to Understand for Routing Protocols

Protocols We Care About:

  1. OSPF
  2. IS-IS
  3. EIGRP
  4. BGP
  5. PIM (Spare/Bidir)

Protocol Theory

  1. How neighbors are formed and maintained
  2. How the best path is calculated
  3. How aggregation is configured and deployed
  4. How external routing information is handled
  5. How protocols interact

Multicast over MPLS – mVPN – Rosen Draft

The original method of switch multicast over MPLS core is called mVPN, or the Rosen draft.

The following article gives a very clear and concise description of how it works:

There are two trees in MVPN:

  1. Default Tree
    1. is used for customer Control Plane and low rate Data Plane traffic
    2. created by default, all PEs that run multicast VRF are part of the tree
    3. can use SM and SSM, SSM is preferred because without RP, it is simplier to deploy and maintain
  2. Data MDT
    1. created dynamically when there is active multicast source and listeners
    2. only PEs with active source or listen will join the tree
    3. customer traffic initially run on the default tree, when the traffic crossed over the configured threshold, a data MDT is built.


  1. SP core does not need any code support for mVPN, the core routers only need to support regular PIM multicast protocols
  2. SP core is scalable before it does not need to keep multicast states for customers. Instead, all multicast groups for each customer is configure one multicast group in the SP core. This is archive by encapsulating customers’ multicast traffic in point to multipoint GRE tunnel between PE (or Multipoint to multipoint GRE tunnels if BiDir-PIM is used in the SP network)
  3. customer can keep their multicast design without making any changes. They can keep their RP if running PIM-SM.
  4. customer can use any multicast groups as usual, because the customer multicast groups are hidden from the SP core.


  1. customer multicast traffic is not label switched, the multicast packets are routed using regular IP multicast tunnel in GRE.
  2. SP NOC need to look at Multicast RIB and FIB to troubleshoot multicast issue, and look at LFIB to troubleshoot unicast issue.

External Links:

  1. Cisco MVPN Design Guide

How to choose PIM-SSM vs. PIM-ASM (PIM-SM)

Choose PIM-SSM when:

  1. You have few multicast sources. More sources mean more routers CPU and Memory requirement. In that case, use Any-Source Multicast
  2. When you want optimum routing from source to listeners
  3. When you want a simpler multicast network to manage, because SSM does NOT need RP, which has management overhead
  4. When you run IPv6 and want to have multicast between Service Providers. Because there is not way to share RP info for IPv6 between multicast domains
  5. When your hosts and edge routers suport MLDv2 for IPv6 and IGMPv3 for IPv4. If these protocols are not supported, static Source to Group mapping need to be defined manually on each edge router, or using DNS

IPv6 Multicast Deployment Models


  1. There are two models:
    1. Any Source Multicast (ASM)
    2. Source Specific Multicast (SSM)
  2. What is ASM?
    1. It requires RP
    2. It uses SPT between Source and RP, and ST between listeners and RP on the initial connection setup but could switch to SPT if the SPT is a more efficient path.
    3. The PIM model to use is PIM-SM
  3. What is SSM?
    1. It does NOT use RP
    2. It uses SPT (S,G) between listeners and Sources
    3. The PIM model is PIM-SSM
  4. When to use ASM?
    1. When you have distributed Sources, like an enterprise network with multiple DCs and multicast sources in all these DCs
  5. When to use SSM?
    1. When you have few sources, like a SP network with a centralized content streaming servers
    2. When you have more then one PIM domains, because there is no mechanism to exchange RP information between domains for IPv6
    3. When you do not want to manage RP

Bootstrap Router (BSR)


  1. Bootstrap router (BSR) provides dynamic distribution of RP-to-group mapping information across a PIM domain. A set of routers is configured as candidate BSRs. Each of them sends bootstrap messages (BSMs) that are flooded throughout the domain. The messages contain a Priority field. If a candidate BSR receives a BSM from another candidate with a higher priority, it stops sending BSMs for a given period of time. Through this election process, a single BSR is left flooding the domain with BSMs and thus providing the RP-to-group mapping information.