Thanks for responding. What's interesting is that even though no listener joins to RP, one must be configured for PIM Sparse Mode ASM to function. I suppose this is a result of MVPN outsmarting PIM.
In my testing so far, generating a working flow with rpt-spt is much faster than spt-only. I suspect this has to do with the conditional nature of the Type 7 Join which waits for receipt of a Type 5 SA before signaling interest upstream. spt-only mode seems objectively superior to rpt-spt in every other way. Jason On Fri, Feb 26, 2016 at 2:33 AM, Yann Lejeune <[email protected]> wrote: > Hi > To support the section §10 in your conf you have two choices: > a. (§10.1) implementing the RP on your PE (protocol pim rp local). It will > advertises the route type after pim register message (or msdp source active > from other RP is you have other rp in your network) > + be sure to use spt-only mvpn mode (default one) > > b. (§10.2) implementing an MSDP session between the RP and its PE > each time the RP will learn a source (either because it receives a pim > register or a SA message from another RP (full meshing msdp between rp), it > will advertise route type 5 to the mVPN. This way receiver PE will learnt > source and if they received join (*,g), they will be able to advertise the > good route type 7 to the source PE. The required conf is: > - msdp session between the pe and the rp > - defining the rp address (protocols pim rp static....) > - be sure to use spt-only mvpn mode (default one) > > The route type 6 is used in another mode call rpt-spt, where you are closer > to the traditionnal multicast behavior (first we build the rp tree and > second we build the source tree). this mode must be enable explicitely per > routing-instance in the mvpn-mode knob. One thing: even in spt-only mode, > the junos will create a route type 6 when receiving a join (*,g) but will > not advertise it. It just wait to get a related route type 5 > > It's up to you to choose what mode you want to use: > - spt-only: is quite "simple". We only have (s,g) in the core. To validate > an os, it's faster. > - rpt-spt. We have both (*,g) and (s,g) in the core. the validation is more > complex, the protocol is more dynamic... > > Regards, > Yann. > > > > On 23 February 2016 at 16:39, Jason Iannone <[email protected]> wrote: >> >> Hi all, >> >> I'm having trouble interpreting under what circumstance section 10 of >> BGP MVPN comes into play. >> >> The way I read this section, upon the receipt of PIM/IGMP Join to >> (*,G) the Receiver Site PE does not signal Type 6 or Type 7 Joins >> until a Type 5 Source Active route is received from a Sender Site PE. >> >> If Section 10 assumes the use of ASM groups in the VPN, why develop a >> Type 6 Shared Tree Join A-D route for unknown sources? >> >> What are the practical minimum Juniper configurations to support >> Section 10 for ASM and (*,G) PIM Join when the PE doesn't know a >> source? >> >> CE1---PE1,C-RP-----P-----PE2---CE2 >> Sender Site-------------------Receiver Site >> >> 1. CE1 has no active source >> 2. CE2 forwards PIM Join (*,G) to PE2 toward PE1,C-RP >> 3. PE2 eats PIM Join, maintains (*,G) state >> 4. CE1 generates Register messages to PE1 >> 5. PE1 originates Type 5 (S,G) >> 6. PE2 receives Type 5 (S,G) >> 7. PE2 verifies existing (*,G) state >> 8. PE2 advertises Type 7 Join (S,G) >> 9. PE2 does PMSI and P-Tunnel attachment >> 10. PE1 receives (S,G) from PE2 >> 11. PE1 adds PMSI to downstream interfaces >> 12. Multicast flow end to end >> 13. Achievement unlocked! >> >> I'm least sure about steps 2 & 3. >> >> Comprehension challenged, >> >> Jason > >
