Multicast over private MPLS network

Answered Question
Jun 12th, 2009

I am considering implementing a large scale private MPLS network. The application to be used over it will need to support multicasting of at least voice traffic. Because I will have total control over the router/switching infrastructure is the configuration a standard multicast config or are there MPLS specific isuues I'll need to deal with. All the docs I can find talk about running multicast ove a provider based network. I'm concerned with how this will work over MPLS. ie: if multiple joins to a common stream are issued from disaprate areas/routers in the network, will a stream be unicast to each RP (PIM sparse) that is upstream from the join request source? Or can I multicast across MPLS to the RP's?

Correct Answer by Laurent Aubert about 7 years 8 months ago


MPLS doesn't support multicast natively yet. You need to wait for mLDP (

So MPLS will be used to forward unicast traffic and in // you will have PIM deployed as usual for multicast traffic.

SP deployed mVPN to support multicast into a L3VPN. But even mVPN is not based on MPLS in the SP core.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Correct Answer
Laurent Aubert Fri, 06/12/2009 - 06:27


MPLS doesn't support multicast natively yet. You need to wait for mLDP (

So MPLS will be used to forward unicast traffic and in // you will have PIM deployed as usual for multicast traffic.

SP deployed mVPN to support multicast into a L3VPN. But even mVPN is not based on MPLS in the SP core.



cchughes Mon, 06/15/2009 - 05:49

So for a fully supported network I guess it is prudent to wait for mLDP. I'll need to lookup the latency introduced by a routed network versus an MPLS switched network. Can anyone point me to a study or whitepaper that goes into those numbers? Guess I should open a seperate conversation on this.


Laurent Aubert Mon, 06/15/2009 - 05:57


If you are using in your core distributed platform like 12000, CRS-1 or 7600, there is no difference between routing packets based on IP addresses or switching packets based on their labels. Everything is handle equally in Hw.



cchughes Mon, 06/15/2009 - 06:11

Hi Laurent, I plan on using 3800 series for most sites and something larger for hub sites. This means the majority of sites will be 3800 series. Do 3800's handle routing in HW too?

Laurent Aubert Mon, 06/15/2009 - 06:40

The router you put as CE depends on the Bw of the access-link. The feature you want to run could also impact the performance.

In my previous email I was referring to P and PE routers not CE routers.


cchughes Mon, 06/15/2009 - 06:58

This will be a proprietary MPLS network, therefore all routers will participate as PE's. My real concern, since I will be multicasting audio, is that implementing a standard routed network will introduce more latency than if I implement a MPLS network. The initial thought was that lable switching would reduce latency introduced by routing. With routing becoming much faster in recent years, I'm thinking the difference in latency will be negligible.

The network will be a geographically dispersed set of routers. Probably around 100 nodes. MPLS would offer switching and a virtual mesh topology while standard rouing would produce variable numbers of hops to get to each destination. If I could calculate the per hop rouing latency (minus latency introduced by the WAN links) I would better be able to decide whether going MPLS produces benefit in terms of performance over per-hop routing. Now that I have an idea of how MCast is supported over MPLS, my quest is to understand the latency of one over the other. (MPLS over Standard per hop routing)

Harold Ritter Mon, 06/15/2009 - 07:08


Bear in mind that all current large mVPN deployments are based on the GRE approach. So this would definitely be the safe and sound approach.

Also, there is divergence of opinions in the IETF on what the replacement to the "GRE approach" should be. Currently, there is two very different approaches proposed by Cisco and one of our competitors, so it will most likely take a while before there is interoperability between these two implementations.


tarnhundal Mon, 06/15/2009 - 06:58

Hi Dear,

I have a problem here ? It seems to be similar kind of problem. I m doubtfull that it may b multicast/QOS problem in my provider's network. Plz help me to sort out this. I have 6513 switch in my core location which is connected to 7613 router. Router has many WAN links with MPLS and p2p connectivity. If i have load on network like when there is Video conference session then i m getting too much delay from our LAN. It doesnt matter if i ping from my pc or from 6513. In same case if i ping from 7613 then there is no delay. When i checked the interfaces both on router and switch connected to each other , there are drops and also tx and rx load is high. My MPLS connectivity is on router with 10 Mbps link. I m having delay only on those locations which are connected with MPLS . Other locations which are on p2p link , those are working fine. I have changed all my modules and interfaces on both devices but no results. I m doubtful abt my ISP's MPLS . My ISP is BSNL. and BSNL provide us different IP for peering with them on MPLS. We are on private AS peering with Public AS. Now when i tried to ping from router to all locations of MPLS with different source IP then there is also delay on router .so what i saw that when i use source of my own network then i m getting delay but when i use provider's IP as source then there is no problem in latency. Sometimes it seems to me as MPLS problem ,coz there are also big number of drops on this MPLS interface and tx and rx load is high. One very important point is that there are also drops and high tx and rx load on all remote locations which are connected to MPLS.

so plz help me to rectify this issue, its very urgent to me.

thanx and regards,


Giuseppe Larosa Fri, 06/12/2009 - 07:35

Hello Chris,

multicast VPN solution doesn't use the MPLS forwarding plane:

Customer multicast traffic is encapsulated into GRE packets with a multicast destination in the global routing table.

Actually multipoint GRE is used.

So service provider needs to be able to transport IPv4 multicast packets over its infrastructure.

A default MDT is created for each multicast VRF to carry signalling and low volume user traffic.

For high volume multicast flows dedicated multipoint GRE tunnels /MDT

Hope to help


cchughes Mon, 06/15/2009 - 06:07

What do you meant by "For high volume multicast flows dedicated multipoint GRE tunnels /MDT" ?

Are you saying dedicated multipoint GRE's are needed for each multicast source/destination? Is this a workaround for MPLS not supporting multicast natively?

Also, what is MDT?


This Discussion