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.
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