MPLS Multicast 1CE can ping both Multicast, other CE can ping only 1

[rpalmeida]

Hello.

I have to implement a scenario similar to or the same as what I am trying in the picture that I send as an attachment.

I have 2xCE and I have 2xPE.

From 1 CE, i can ping the 2 multicast groups (239.0.0.2 and 239.0.0.4)
From the other CE i can only ping the multicast group that is configured locally, not the remote one.

Can you help me?

I am attaching the configs and pings.

Thanks.

[paul driver · Accepted solution]

Hello
Did you find a solution for this?
Looking at your cfg, You are using static ASM , with the PE configured as the RP, so Curious  do you have reachability to this RP?
from either R6/8?

[Harold Ritter · Accepted solution]

Hi Paul,

Quickly looking at the configurations, I can see that multicast is not configured in the core.

In the legacy mVPN solution (draft-rosen), the customer multicast traffic is encapsulated in a GRE tunnel in the core. This GRE tunnel destination address is a multicast address for the default MDT.

This solution will not work unless multicast (SSM or ASM) is properly configured in the core.

Regards,

[rpalmeida]

Hi Harold,

Nice seeing you too.

As i told to Paul, the only way to get both sides ( CA1 and CA2 ) joining an IGMP GROUP is having PIM in CORE.

If PIM is not in CORE, side from CA1 can join IGMP from CA1 and can join IGMP from CA2.

Side CA2 cant join IGMP from CA1.

Thanks for your response.

Best Regards.

[Harold Ritter]

Hi @rpalmeida ,

> If PIM is not in CORE, side from CA1 can join IGMP from CA1 and can join IGMP from CA2.

This is due to the standard PIM behavior. Multicast traffic (ping 239.0.0.4) from CA2 reaches PE2, which is the first hop router (FHR) and this FHR encapsulates the multicast traffic and sends it as unicast traffic (PIM register message) towards the RP (PE1). Since PE1 already has a (*,G) state for 239.0.0.4 because of the IGMP report message received from CA1, traffic can be sent to CA1.

On the other end, multicast traffic from CA1 (ping 239.0.0.2), reaches PE1, which is the RP and does not have a (*,G) for 239.0.0.2 as this would require PIM to be enabled in the core. Therefore traffic can't make it to PE2 and CA2.

This explains why you can see the PIM client domain multicast traffic working in one direction, but not in the other when PIM is not enabled in the core.

Regards,

[rpalmeida]

Hi Paul.

Nice seeing you.

The only way to get both sides ( CA1 and CA2 ) joining an IGMP GROUP is having PIM in CORE.

If PIM is not in CORE, side from CA1 can join IGMP from CA1 and can join IGMP from CA2.

Side CA2 cant join IGMP from CA1.

Thanks for your response.

Best Regards.

[rpalmeida]

The information you 2 passed me was very usefull to get around this.

Thanks.

[Harold Ritter]

You are very welcome @rpalmeida and thanks for the feedback