Multicast concerns

[Quang Do Xuan]

Hi everyone.

Need you opinions for the following question.

1. When we replace a RP with another RP, is there any down time for the multicast applications. (I guess no because RP is only needed for initializing connection between source and clients, but never verify to be 100% sure)

2. What happen if we have two multicast application using the same multicast IPs? 

This is for the multicast configuration in my company and your answers are much appreciated. 

[Peter Paluch]

Hi,

1. When we replace a RP with another RP, is there any down time for the multicast applications. (I guess no because RP is only needed for initializing connection between source and clients, but never verify to be 100% sure)

This depends primarily on whether your network is configured to perform a switchover to the shortest path tree (SPT switchover), or whether it remains using the shared tree rooted at the RP. If your routers perform the SPT switchover then changing the RP should not have an impact on your multicast traffic delivery. If, however, your routers are configured to remain joined to the shared tree then replacing the RP would cause outages.

2. What happen if we have two multicast application using the same multicast IPs?

I assume you are asking about the result of having two multicast applications send their data to the same multicast IP address. In this case, if a receiver subscribes into this group, it will be receiving both streams whether it wants them or not. Note that receives is not the same as process - while a computer may be receiving a multicast stream, that stream may still contain a UDP flow to a destination port that is closed. The subscriber would be therefore receiving a stream it is not really listening to, and would be dropping it. IGMPv3 can, in theory, help here as it allows a receiver to subscribe to a particular source-and-destination, not just to a destination; however, IGMPv3 is rarely used to my best knowledge.

A more serious problem could ensue if both multicast applications use the same upper layer protocol address, for example, the same UDP destination port. In this case, to the receiving application at the subscriber computer, these two streams would be indistinguishable, and the application would process them both. That could be disastrous for the application.

Please feel welcome to ask further!

Best regards,
Peter

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

A footnote to what Peter has already posted.

Multiple multicast IPs map into the same Ethernet multicast MAC.  So, its possible, a multicast receiver will be sent multicast traffic even with a different multicast IP.

However, if this happens, the receiver's NIC might filter out the undesired traffic, avoiding the situation Peter mentions where different application multicast packets with the same destination IP need to be examined.  Yet, even if the NIC filters frames, those frames will still consume bandwidth to the receiver.  (BTW, the latter is "normal" for non-snooping switches or hubs.)

Lastly, Peter mentions two multicast applications, with same IPs and ports, would be indistinguishable. To further clarify, that's true at the L3, but may not be true higher in the stack.  (Which is why, I'm sure, Peter notes "could" be a serious problem, not "would" be a serious problem.)  Yet, best to avoid, if for no other reason to minimize receiving host's work load.

[Quang Do Xuan]

Thanks Peter & Joseph,

"This depends primarily on whether your network is configured to perform a switchover to the shortest path tree (SPT switchover), or whether it remains using the shared tree rooted at the RP"

How to know whether my network has this switchover feature?

Sorry I'm just a newbie to multicast.

[Jon Marshall]

It depends on the "ip pim-spt threshold" command.

The default is that when the first packet is received from a new source by the PIM router connected to a receiver it automatically switches over to the SPT.

So unless you have specifically configured it not to using the above command it should be doing it by default.

Jon

[Peter Paluch · Accepted solution]

Hi Jon,

Your answer is to the point as always! Let me just add that the ip pim spt-threshold command controls the SPT switchover on the end routers where receivers are directly connected. It is sufficient to veriy the configuration on the edge routers that connect to multicast subscribers.

Best regards,
Peter

[panayiotiscy]

Hello All,

I am joining this thread because its highly on my agenda.

When it comes to the multicast-pim configuration on the edge nodes.

What is the configuration needed for nsf / sso ?

Thanks