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
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 <jason.iannone@gmail.com> 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
On 26/Feb/16 11:33, Yann Lejeune wrote:
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...
I've ran both modes, and found SPT-only mode to be a fair compromise between speed and scale. When operating SPT-only modes, we did not witness a noticeable difference in channel-changing times. In SPT-only mode, the (S,G) state is already present on the Receiver PE router even though there is no downstream interest for that state. So when an IGMP Join request comes into the router, it does not have to travel the RPT tree like it would if you ran RPT-SPT mode (which is traditional Multicast). In our case, we had Multicast probes connected to every Receiver PE router to track performance for each channel. So if you have that, you're going to need all the channels present on the router anyway, even though downstream interest is not present. In this case, avoiding the extra steps associated with RPT-SPT mode is what compelled us to run SPT-only mode. But as Yann has mentioned, even in SPT-only mode, the Type 6 routes will exit in the router, but won't really be used. Type 5 routes are more important when operating in SPT-only mode, and those are always present in such a state. My next NG-MVPN operation will be SSM-based, so this should be simpler still. Mark.
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 <yann.lejeune@gmail.com> 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 <jason.iannone@gmail.com> 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
participants (3)
-
Jason Iannone -
Mark Tinka -
Yann Lejeune