Solution would be setting a higher PIM priority in lt-1/1/10.770, so that it becomes the DR
On 10/23/13 12:40 AM, "Antonio Sanchez-Monge" <[email protected]> wrote: >That's a brilliant analysis Stacy, I think you nailed it (awaiting Mihai's >confirmation). > > >On 10/22/13 11:59 PM, "Stacy W. Smith" <[email protected]> wrote: > >>On Oct 22, 2013, at 2:44 PM, Mihai <[email protected]> wrote: >>> Removing PIM fromlt-1/1/10.770 is not a solution because the PE will >>>not learn about the source and the multicast group. >> >>Actually, removing lt-1/1/10.770 from PIM would allow the source and >>multicast group to be learned, and fix the problem (as long as multicast >>routing was still enabled on the lt-1/1/10.770 interface). >> >>The problem is that there's a PIM neighbor relationship between a and x. >>Because of your IP addressing, a is the DR for the a-x LAN. >> >>Because you are injecting traffic with ping and "bypass-routing interface >>lt-1/1/10.771" logical-system a is NOT the first-hop router. It's simply >>acting as a multicast source that's pumping traffic with destination IP >>225.10.10.10 out the lt-1/1/10.771 interface. >> >>Logical-system x instance mvpn receives this traffic on lt-1/1/10.770 and >>does not forward it because it is not the DR. >> >>Therefore, the logical-system x instance mvpn doesn't learn about the >>active (S,G). >> >>Another way to solve this problem is disabling PIM on logical-system a. >>This will make lt-1/1/10.770 on logical-system x instance mvpn the DR, >>and cause it to learn about the active S,G (and therefore generate the >>NG-MVPN Type 5 route). >> >>I have mocked up your configuration in the lab and confirmed that >>removing PIM from logical-system a fixes the issue. >> >>--Stacy >> >> >> > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
