IGMP use as client and router?

[SandipJunghare]

Hi,

I want to implement IGMP to use it for receiving multicast traffic i.e. device should act as client. And again want to use it for router/snooper.

Is this both use cases of IGMP possible??

Thanks.

[pedrofran12]

Hi Sandip,

To be honest I never tried using the same device as a client and as a router.

To receive multicast traffic you need to manifest your interest... Theoretically this manifestation of interest could be performed by IGMP or multicast routing protocols (like my implementations of PIM-DM or HPIM-DM or any other packages like pimd from @troglobit).

For IGMP manifestation, you will use the IGMP implementation that comes pre-installed with your Linux kernel. Basically whenever you want to receive multicast traffic (e.g. via a socket), the kernel by default sends IGMP Reports. These IGMP packets will be received by all routers attached to the same L2 broadcast domain (all routers that are also connected to the same broadcast domain will consider that there is interest from an "host" - however the host is also behaving as a router)

For the multicast routing manifestation, if you use hpim-dm or my implementation of pim-dm, the router will send PIM/HPIM Join messages towards the root of the multicast tree if it detects multicast interest from routers or hosts connected to interfaces different than the iif (a.k.a. root interface in my HPIM specification). I am not sure if my implementation of IGMP considers that there is interest in a given interface if it self generates IGMP packets and sends by that same interface.

Also to keep in mind is that my router-side IGMP implementation only supports IGMPv1 and IGMPv2. If you need to manifest multicast interest from specific sources this would require router-side IGMPv3 which is not implemented / not supported by my implementations).

I will test this on my PC. Can you please share a diagram of the topology that you are implementing (like hosts/sources/receivers and routers in between)?
I will only be able to test this next week... If you don't hear a reply from me please ping me back.

Best regards,
Pedro

[pedrofran12]

Hi Sandip,

Just wanted to give an update regarding the current behavior (I have tested this on HPIM, but the same behavior is expected on my PIM-DM implementation)

I have performed some tests and this is the current behavior:

• If a router wants to join a given multicast group, it will behave as an host and send IGMP Reports.
• The problem is where the IGMP Reports are sent... If you specify the iif as the interface to send the IGMP Reports (via IP_ADD_MEMBERSHIP socket option), the upstream router will receive it and consider that there is an host interested in receiving multicast traffic. Multicast traffic will be forwarded correctly and received by your application in the router.
• If you specify an interface different than the iif, the router will send IGMP Report messages via that interface (downstream the tree), however the router multicast daemon will not consider those self generated IGMP Report messages in the interest definition of an interface... The interface only interprets inbound IGMP messages and not self generated IGMP packets... This means that if there is no downstream interest, the router will not join the multicast tree even if you have an application interested in that tree.

Even if your application specifies the iif as the interface to send IGMP Reports, this would allow to receive multicast traffic correctly by your application but you would not be protected from possible issues in the network that could cause the iif to change dynamically (for example cost changes or link failures).

I have also tried to have a loopback interface to be used to send IGMP Reports and to forward multicast traffic to the receiver application (inside the router), but I am seeing that the application is receiving duplicated packets...

I am not sure if I can fix this bug... If I take into consideration self generated IGMP traffic I am not sure if this can cause some inconsistencies in the maintenance of IGMP state... it would be as if there was someone with the same IP sending IGMP messages (not sure if it can screw the Querier election).
I will investigate if there is a good alternative to solve this.

Best regards,
Pedro