Which interface should be configured with command ip igmp join-group at end router ?

[yangfrank]

Dear All

Which interface should be configured with command ip igmp join-group ? I noticed two documents. One said the command should be at up interface (toward multicast source) of the end router, while another said it  is at down interface (toward end user). I do not know which one is right. Can you give your comment ? Thank you

http://networklessons.com/multicast/multicast-pim-designated-router/

http://packetlife.net/blog/2008/jul/21/two-ways-force-igmp-join/

Frank

[Vasilii Mikhailovskii]

Hello.

I assume the router is not a multicast receiver; so, I would say you should not use "ip igmp join-group", but " ip igmp static-group".

If we are talking about last-hop routers, then the command needs to be put on the interface the receiver is connected to. Also we need the command only if the receiver is not capable of IGMP signalling (or per design requirements).

PS: if you describe your design/requirements, it would be easier to give you an advice.

[yangfrank]

Hi, I am sorry that I did not make my question clear.

Please see the picture in attachment. R3 and R2 are configured with multicast dense-mode. R3 is source of multicast message. I put command ip igmp join-group 224.2.2.2 at R2 interface e1/1 or e1/0, then when R3 ping 224.2.2.2, the results of reply are same. My question is what is difference functionally when command ip igmp join-group 224.2.2.2 is put at R2 e1/1 or e1/0 ? Should we put the command at e1/1 or e1/0 in the real production environment ? Thank you for your explanation

[Jon Marshall]

If you put it on R2's connection to R3 then you are only doing multicast routing on R3.

If you put it on R2s connection to the PC then you are doing multicast routing on both R2 and R3.

In production you generally don't use it because as Vasilii says you only need it when the end device is not capable of using IGMP to signal it wants to receive the multicast stream.

And with end clients they would need some sort of application to display the multicast stream anyway eg. VLC and that application would be capable of sending an IGMP join request to the router.

Depends on what you are trying to achieve.

Jon

[yangfrank]

Hi Jon, Thank you so much. What you are talking is very important for me to understand this issue. I basically understand the issue. but I would like to ask again:

You said "If you put it on R2's connection to R3 then you are only doing multicast routing on R3" Can you explain what this mean further with " then you are only doing multicast routing on R3" ?

Can I say "If you put it on R2's connection to R3 then you are only doing multicast routing on R3."  that means the end router is R3, and  end user would be R2, right ? 

"If you put it on R2s connection to the PC then you are doing multicast routing on both R2 and R3". That means the end router is R2. and PC would be end user, right ?

Thank you.

[Jon Marshall · Accepted solution]

Okay to be more precise when you say R3 is the source where is the actual ping being started from ?

Lets say for arguments sake you had a client connected to R3 on another interface and from that client you started your ping to a multicast IP.

If you add the "ip igmp join-group <multicast IP>" to the R2 interface that connects to R3 then R3 would be routing the multicast stream between it's interfaces but R2 wouldn't because it is joining the group, as you say, as an end device.

If you add the same command on R2s interface connecting to the PC instead then R3 would still route the multcast traffic but R2 would also route the traffic between the interface connecting to R3 and the interface connecting to the PC.

So basically yes to the way you have summed it up.

Jon

[AMediaFilm]

Which interface should...

I would say none. It shouldn't be used for two reasons.

1. Mrouting should work without any static joining in a normal working network environment. I mean when source and receiver works with igmp as it described in RFC, when igmp snooping works properly on access switches, with working igmp queriers, nothing filtering, no misconfigurations. All you need to care about is inner pim-domain configuration.

2. (should be №1). In case something wrong and you have to work around customer devices that does not fully support igmp (while seller told them it does and they trust to seller)... Then use ip igmp static-group. join-group instructs CPU joining group on interface and multicast will flow into CPU too which might cause uncomfortable problems.