01-24-2011 09:09 AM
If I want to support multicast in a layer 3 VPN, using either method, does multicast need to be enabled within the default routing instance, even though the underlying network doesn't currently require multicast?
Solved! Go to Solution.
01-24-2011 10:15 AM
The draft-rosen method (using PIM) does require the default routing-instance to be multicast/PIM enabled. This is required in order to build the core state used to "tunnel" the multicast-vpn traffic.
Multiprotocol BGP (MBGP)-based MVPNs do not require a multicast enabled core. As, the PIM state is maintained by the PE routers only, using the same methods as you would for unicast VPNs.
01-24-2011 11:17 AM
Ben is correct about PIM
But if you have receivers directly connected to multicast PEs or you want to use static IGMP joins to fan out multicast traffic from VRF interfaces , then IGMP needs to be enabled in master instance under [edit protocols igmp] and interfaces inside multicast VRFs need to be specified there:
[edit protocols igmp] interface ge-0/0/0.100; ## interface in multicast VRF1 interface ge-0/0/1.200; ## interface in multicast VRF2 etc etc
Accept as Solution = cool !
Accept as Solution+Kudo = You are a Star !
01-24-2011 11:57 AM
Okay. What is really confusing me are the examples in the documentation. Take this, for example:
This shows that PIM needs to be enabled in the PE and P routers, but it also shows that it is an MBGP MVPN. Is there a better example in the documentation that someone can point me to?
05-19-2011 11:28 AM
That's only because in the example BGP MVPN is configured to use PIM-ASM "multicast tunnel" in the core In this case you do need PIM to be configured in the P and PE routers.
BGP MVPN provides the flexibility to use different tunnel types. When you use multicast tunnels based on p2mp rsvp-te, you wouldn't need PIM in the core. Other supported tunnel types are ldp-p2mp, ingress-replication
# set routing-instances vpn-a provider-tunnel rsvp-te label-switched-path-template default-template
You will need to enable traffic engineering under ospf and enable
Enable traffic engineering on core facing interfaces on PE routers
# set protocols ospf area a.b.c.d interface ab-x/y/z.w
Enable RSVP on core facing interface on PE routers
# set protocols rsvp interface ab-x/y/z.w
05-23-2011 05:02 AM
Thanks. I ended up finding some decent Juniper white papers on NG-MVPN and following the examples in there. Everything is working, except for two sites whose CPE does not have the ability to run PIM, so I can't figure how to get those working. The odd thing is that the same exact setup in my lab works, but not in production.
01-11-2012 07:33 AM
I had the same issue ,
My question is : must both PE routers be a PIM neighbors if I am using p2mp rsvpn tunnel ?
No. With p2mp rsvp tunnel, pim is not needed in the core.
01-15-2012 10:47 AM
Hi bend ,
thanks for the reply , my concern is with p2mp rsvp-te , when I did : show rsvp neighbor , there is no neibhor and also no rsvp session , so the 2 PEs(one connected to the multicast source and other to the receiver) will not establsh PIM neighbor , am I correct ? can you explain what is expected ?