There are many documents and websites that explain the various aspects of every protocol and technology known to man. Some are very good and some are just ok and may make things more confusing. Part of the reason why I have created this website is to not only help others try to understand these topics but also to help me understand them myself. Multicast VPNs in an MPLS core is one of these topics that I need to write about to help myself. There are a few ways that can be done and each have their out pros and cons so let’s jump right in and explain each.
First, we are going to take the MPLS topology I use in all my posts and cut it down so that only the core is present (no L3VPNs or other non-important connections).
In the above topology, all links are /30 transits, all loopbacks are configured and OSPF has converged into Area 0. All IP addresses are reachable from all routers. As we go through each type of Multicast VPN, I will update the diagram with the appropriate information to help illustrate the information.
Draft-Rosen Multicast VPN (ASM/SSM)
The original Multicast VPN is the Draft-Rosen MVPN and comes in two ways, either Rosen 6 which uses Any-source Multicast or Rosen 7 which uses Source-specific Multicast. If you use Rosen 6, there must be a Rendezvous Point configured since in ASM, the source is not initially known. Also, because of this, provider routers must maintain a multicast table so that multicast trees can be created.
If you use Rosen 7, you now know the source of each multicast group since that is what Source-specific Multicast is all about. The benefit of Rosen 7 is, since the source is known, the provider routers do not need to maintain a multicast table to keep track of the multicast trees. The interesting this about both Rosen 6 and Rosen 7 is not whether or not ASM or SSM is used, but now trees are built and why.
In Draft-Rosen MVPN, provider edge routers create trees between each other which can be one of two types and depending on the type, determines the traffic that it carries and what routers join the tree. The two tree types are Default Tree and Data MDT. Let’s take a look at each tree.
Default Multicast Distribution Tree
The default tree, as you could probably guess, is the default tree that is used and has a few purposes. First, every Provider Edge (PE) router joins this tree. It doesn’t matter whether or not there is a Customer Edge (CE) device behind it wanting to join a particular multicast stream inside a Virtual Route Forwarding (VRF) instance. This is because the default tree carries two things; control plane traffic and low-rate data plane traffic for particular sources (more on this in just a bit). As mentioned prior, this can use either Any-source Multicast (ASM) or Source-specific Multicast (SSM). For example, the diagram below shows if there was a multicast source on PE-R1 and the Default MDT was created:
Data Multicast Distribution Tree
The second tree that is created is the Data Multicast Distribution Tree (MDT). As it was mentioned when describing the Default Tree, low-rate data plane traffic is carried in the Default Tree. However, if configured, multicast traffic can be separated into it’s own tree if it goes past a certain threshold configured on the router. When this happens, a new Multicast Distribution Tree is created and only Provider Edge (PE) routers that have either the specific multicast source or interested receivers will join. So because of this, the tree is dynamically created when that threshold is reached.
For example, let’s say that data from a multicast source on PE-R1 went past the threshold configured and only PE-R3 and PE-R4 had receivers that were interested in traffic. We would then see a new Multicast Distribution Tree (MDT) be created and only PE-R3 and PE-R4 join that tree:
When implementing Draft-Rosen Multicast VPN, you need to be aware of a few things. First, the advantages:
- There is not special configuration in the core since Draft-Rosen only uses Protocol Independent Multicast.
- Customers can use their own multicast design and groups as they are completely independent from the provider core.
- If using Source-specific Multicast (SSM), Provider (P) routers do not maintain multicast tables and there is no need for a Rendezvous Point (RP).
However, there are some disadvantages:
- Multicast Distribution Trees are routed via the core routing protocol and not label switched. This means that they cannot go over LSP’s and you need to be mindful of core routing tables.
- Because it uses the internal routing protocol, when troubleshooting, you must use the Routing Information Base (RIB) and Forward Information Base (FIB) to troubleshooting path issues relating to Multicast Distribution Trees (MDT).