Multicast BSR advertisement does not go through the mpls network. Routing issue in "core" ?

[gabor_fejer]

Hello All,

I'd like to aks your help, I am getting out of ideas ...

I am working on a solution to enable  multicast feature in a small MPLS network and "playing" with different solutions. However, I had to realise that something is wrong. There is a small test network set up for this, and I use ospf and iBGP between the MPLS routers and eBGP between PE and CE. I tried to configure PIM Sparse mode using PIM AUTORP or PIM BSR methods but none of them worked. When I statically configured the RP address on PE2, it worked. It seems PE1 does not pass the advertisement to PE2 neither using AUTORP nor using BSR. As far as I know, PE1 should automatically propogate the information to PE2 how to reach the RP. (because the PE1 is the BSR-candidate)

Is there a problem with the Handover of VPNv4 route ? What did I miss out ?

The related part of the config and some outputs are attached,

Thank you for your help, I really appreciate it.

Cheers,

Gábor

[Spooster IT Services]

Hello @gabor_fejer,

Check out the link below for config example to configure Multicast over MPLS.

Multicast Support for MPLS VPNs Configuration Example - Cisco

***Please rate all helpful posts***

[gabor_fejer]

Hello,

Thanks for the link. Yes, I have seen that, but I think that example is not the best as it does use sparse-dense mode, and dense mode makes sense. The reachability would work without RP because of the dense mode. I'd liek to use pure Sparse mode. However, I'll check it one more time, maybe I find smtg.

Cheers,

[gabor_fejer]

Hi All,

I have checked the setup again, and found a strange entry in Wireshark, namely "Malformed Packet PIM". You can see the attached picture. What can cause this problem? I am suspecting my main problem caused by this ?

[Giuseppe Larosa]

Hello @gabor_fejer ,

the frame is identified as a Register message .

The second picture looks like more an issue of wireshark then a real issue as a register stop frame is seen in response in the first figure.

So I am afraid it is not this the root cause of your issues.

Hint:   the register message is sent by a PIM DR near the source to signal to the RP that the source is alive by sending the mcast packet encapsulated in GRE with destination the RP address.

The Register stop is sent back by the RP to say to stop sending these encapsulated packets possible reasons are:

a) no receiver is interested on the group G the source is sending to

b) there are receivers downstream but for efficiency the RP has already joined the source based tree rooted at source PIM DR

I have reviewed some labs I did several years ago I used PIM SSM in the backbone or PIM SM, I may be wrong but dense mode should not be supported in this model that is called Draft Rosen multicast VPN    the use of MGRE in the service provider to create MDTs.

Hope to help

Giuseppe

[gabor_fejer]

Hello @Giuseppe Larosa

Thanks a million for your comment.

"The second picture looks like more an issue of wireshark" -> Ah, ok, it makes sense. I have never seen such a message like this before.Ok, I will ignore this.

As for the "register Stop messages"

,a, --> I have configured "ip igmp join-group 239.2.2.22" on the PC (behind CE1).

"b, there are receivers downstream but for efficiency the RP has already joined the source based tree rooted at source PIM DR". -->> I don't understand this, could you please explain ?

Cheers,

Gábor

[Giuseppe Larosa · Accepted solution]

Hello @gabor_fejer ,

>> "b, there are receivers downstream but for efficiency the RP has already joined the source based tree rooted at source PIM DR". -->> I don't understand this, could you please explain ?

In PIM SM in Cisco implementation the shared tree (*, G)  is  based on the RP is undirerctional in outgoing direction from the RP.

Now you have a downstream receiver for the group and the PIM SPT threshold is so low that as soon as the source is known the RP will join a source based tree (S,G) sending a PIM join for group G to the PIM router connected to the multicast stream source the so called source PIM DR.

Once the RP has joined the source based tree (S,G) the downstream devices if any also joins the source based tree re-using part of the shared tree.

At this point the RP will send register stop messages to the source PIM DR router ( the router where the source is connected the one with loopback 2.2.2.2) to tell to stop sending multicast packets encapsulated in GRE packets with destination 5.5.5.5 = RP address.

This happens every few minutes actually ( 3 minutes ) 5 seconds before this timer expires the PIM Source DR sends a registration packet and the RP answers with a registration stop.

Hope to help

Giuseppe

[gabor_fejer]

Hello @Giuseppe Larosa,

Thank you for the info. If I am not mistaken this happens because there is a "better path", I mean the traffic will be switched from the initial shared tree  to the (S,G ) tree because that path is better, that is why we have register stop messages regarding the original path (this way the traffic flows via the better path). Right?

Will try to dig deeper in multicast to find the root cause for my problem.

[Giuseppe Larosa]

Hello @gabor_fejer ,

in PIM SM the Shared tree can be used only to send packets out of the RP downstream.

in PIM Bidir the transition to (S,G) tree is never done and in this case the source PIM DR can send multicast packets to the RP without using registration. ( this is why is PIM DR is called bidirectional traffic can be sent to or from the RP).

In PIM SM as soon as the source is known the shift to the source based tree starts (S.G) and the RP itself joins the (S,G) if it is on best path between the source and the current set of receivers.

It is forwarding efficiency the main reason.

Hope to help

Giuseppe

[paul driver]

Hello
Try introducing an MSDP peering between ASN's:

example:
CE1
ip msdp peer 4.4.4.4 source loopback 0

CE2
ip msdp peer 5.5.5.5 source loopback 0

[gabor_fejer]

Hello @paul driver ,

Thank you for your thoughts on this. I tried to configure msdp, but unfortunately it did not work, either. Even though the peering came up, multicast ping did not work. I think the root cause is the same like before, so , the root cause should be discovered.

CE2#sh ip msdp summa
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
5.5.5.5 65002 Up 00:03:52 0 0 ?
CE2#

[paul driver]

Hello

I know you have excepted a solution but did you try actually statically configuring the rp with the loopback ip address with MSDP

CE1
ip msdp peer 4.4.4.4 source loopback 0
ip pim rp address  x.x.x.x <ce1 loopback)
CE2
ip msdp peer 5.5.5.5 source loopback 0

ip pim rp address  x.x.x.x <ce2 loopback)

[gabor_fejer]

Hello @paul driver 

YEs, sorry, I clicked on the "Accept as Solution" button by mistake. Yes, I know it is a bit misleading, sorry about that.

Yes, adding "ip pim rp address  x.x.x." makes sense, ping works now. However, my original idea was to avoid any static config regarding RP, that is why I wanted to use autorp or BSR. Or, is it a must to configure static rp in a set-up like this ?

Despite the fact it works, I noticed packet duplication. When I make a packet capture in Wireshark, I see the PIM reg message sent 2x. First one is sourced by the physical int, the 2nd one is sourced by the loopback int. Not sure why this happened. (source is CE2)

CE2#ping 239.2.2.22 rep 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 239.2.2.22, timeout is 2 seconds:

Reply to request 0 from 10.10.10.2, 72 ms
Reply to request 0 from 10.10.10.2, 76 ms
Reply to request 1 from 10.10.10.2, 112 ms
Reply to request 1 from 10.10.10.2, 116 ms
Reply to request 2 from 10.10.10.2, 108 ms
Reply to request 2 from 10.10.10.2, 108 ms
Reply to request 3 from 10.10.10.2, 64 ms
Reply to request 3 from 10.10.10.2, 64 ms
Reply to request 4 from 10.10.10.2, 80 ms
Reply to request 4 from 10.10.10.2, 84 ms
Reply to request 5 from 10.10.10.2, 40 ms
Reply to request 5 from 10.10.10.2, 44 ms
Reply to request 6 from 10.10.10.2, 68 ms

[Giuseppe Larosa]

Hello @gabor_fejer ,

Paul Driver's suggestion to use MSDP is a very good one.

Let me add that MSDP just allows communication between different RPs of different multicast routing domains that can tell each other about active mcast sourced in their own domain.

MSDP by itself does not provide a valide routing information to pass the RPF check on the source.

On a traditional inter-AS multicast scenario MSDP peering will be a companion for eBGP in address family ipv4 multicast.

Here you have VRFs so it is to be checked if address-family ipv4 vrf <vrf-name> multicast is supported on your platform.

the eBGP session in ipv4 vr<vrf-name> unicast should be enough to propagate unicaat routing info to be used for RPF check.

Hope to help

Giuseppe

[gabor_fejer]

Hello @Giuseppe Larosa,

Grazie. Thank you for the clarification. IT is getting clear

Cheers,

Gábor