search

troglobit / pimd

PIM-SM/SSM multicast routing for UNIX and Linux
http://troglobit.com/projects/pimd/
BSD 3-Clause "New" or "Revised" License
194 stars 86 forks source link

pim register tunnel always streaming between two pimd's #128

Closed ruckc closed 2 years ago

ruckc commented 5 years ago

So we have an odd concern. So we have two pimd's and a multicast producer, and potential multicast consumers on the other of the RP/BSR.

image

So, when the producer is sending multicast, and there is no consumers joined to the MC group, we are seeing a potential issue.

1) Producer sends multicast to his LAN. 2) The DR picks it up, and sends it in a PIM Register to the RP. 3) The RP, sends a Register Stop, because find_route doesn't return an mrtentry. 4) The DR, receives the stop, and puts a register supression timer in place. 5) The RP, continues processing then creates an mrtentry for the commented reason 6) The DR, when the register supression timer expires, starts sending PIM Register messages 7) The RP, it has an mrtentry now, because it was created in #5, so it doesn't send the Register STOP ever again...

So, now the multicast data is always flowing from the DR to the RP, even though there is no joined consumers on the remote side of the RP. From our reading of the RFCs this should be continually sent Register Stop messages to trigger the register suppression timer on the DR.

Thoughts?

ruckc commented 5 years ago

This issue appears to be scoped to just between two pimd 3.0.0 processes, 2.3.2 doesn't create the mrtentry if it doesn't exist.

idismmxiv commented 5 years ago

Hi. Good catch. This seems to be caused by changes from https://github.com/troglobit/pimd/commit/c843c1ec1f8fd85581d6ad8968ae470cf35200f1 as part of issue #58 Given commit could just be taken out or changed in a way that register stop is sent if no oif:s exists for mrtentry.

ruckc commented 5 years ago

@idismmxiv another option would be to add another flag to those MRT entries that is filtered out at line 690, so find_route never finds those routes for this case.

troglobit commented 5 years ago

A flag would be nice but I'm thinking the problem might be related to section 4.4.2 in RFC7761, in particular this passage;

An RP should preserve (S,G) state that was created in response to a Register message for at least ( 3 * Register_Suppression_Time ); otherwise, the RP may stop joining (S,G) before the DR for S has restarted sending registers. Traffic would then be interrupted until the Register-Stop Timer expires at the DR.

I may very well be wrong, but it might be worth bringing up for discussion at least.

idismmxiv commented 5 years ago

I am not sure if that given sentence is applicable to this case. To me it says that once you have created (S,G) state in RP, you must maintain it atleast 3 * Register_Suppression_Time.

Defect we have at hand is about sending Register Stop if no one is requesting given MC-stream. It might be bit of a hack to create (S,G) entry even if no one is requesting MC-stream and play with flag or oif count, but RFC does not forbid to do so (not that given sentence or at least to me it looks like it does not).

troglobit commented 5 years ago

OK, I propose we revert c843c1e for now so that we can close this issue. What do you guys think?

troglobit commented 5 years ago

Note to self: Remember to revert ChangeLog as well, if @idismmxiv and @ruckc agree to revert c843c1e.

troglobit commented 5 years ago

ETIMEDOUT, reverting manually with reference to this issue. Thanks again for the report!

troglobit commented 2 years ago

Better fix in stormshield-rlibaert@099748b, separate PR coming.