Question on impact:changing from IGMPv3 to IGMPv1

[news2010a]

Hello,

In my organization an application administrator tells me that a new given application/server is known not to work with IGMPv3. Therefore application administrator asks me to change respective vlan the application is running from IGMPv3 to IGMPv1.

Topology is depicted on the attached diagram.

So it seems that if I change "int vlan 2" to igmp version 1 on the 4507, I would need to observe that ApplicationServer1, which is currently running OK using IGMPv3, continues to operate OK.

Question:

Anyone has any other recommendation on what else I would need to do when changing this from IGMPv1 to IGMPv3 to make sure this will work?

!
interface Vlan2
description TO-2950
ip address 10.2.19.124 255.255.255.0

ip helper-address 192.168.1.1
ip pim sparse-mode
ip igmp version 3
ip ospf message-digest-key 10 md5 <>
ip ospf cost 1000
end
!

[Giuseppe Larosa]

Hello Marlon,

but IGMP version 2 is not known to application developers ?

I can understand issues with IGMPv3, but IGMPv2 should be supported check this point.

also where is application server1, in the same IP subnet/vlan or in another vlan?

I would rather test new application in your current environment, it is not clear where the application should fail if using IGMPv3 instead of a previous version.

IGMP is used between possible receivers and infrastructure devices (multicast routers and switches) and generally does not involve sources.

That is a source may be just a traffic generator unless they are checking the presence of IGMP reports just to decide if it is the case to send traffic.

Hope to help

Giuseppe

[news2010a]

I thought about the same; why not IGMPv2. In IGMPv1 as far as I know there are known inefficiencies with the leave group message.

What I know is that on the other parts of the network they implemented IGMPv1 and it is working, but I will definitely try IGMPv2 as well.

Yes, sorry for my misexplanation:

All ports on the 2950 switch are on vlan 2. So both new and existing application servers are assigned to vlan 2.

Thanks for the feedback.

[Jon Marshall]

news2010a wrote:
I thought about the same; why not IGMPv2. In IGMPv1 as far as I know there are known inefficiencies with the leave group message.
What I know is that on the other parts of the network they implemented IGMPv1 and it is working, but I will definitely try IGMPv2 as well.
Yes, sorry for my misexplanation:
All ports on the 2950 switch are on vlan 2. So both new and existing application servers are assigned to vlan 2.
Thanks for the feedback.

Marlon

Definitely look to use IGMPv2. If IGMPv1 works then so should IGMPv2 and as you say it has improved efficiences with the leave message.

Jon

[news2010a]

One thing that I cannot understand:

The output below is from another site, in which a 4507 which routes the vlan 2 where such applications which do not work with IGMPv3 and therefore a network admin converted that to IGMPv1.

It is running on IGMPv1 is pasted below, however, there is no configuration for RP. Anyone can explain how this is working on IGMPv1, sparse-mode and no RP was set? See that mroute lists RP=0.0.0.0.

If

show ip mroute

(...)

(10.2.17.2, 239.254.13.32), 13w6d/00:02:03, flags: sPTI
  Incoming interface: GigabitEthernet4/1, RPF nbr 10.2.60.129
  Outgoing interface list: Null

(*, 224.0.1.40), 18w6d/00:02:36, RP 0.0.0.0, flags: DPL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

Building configuration...

Current configuration : 336 bytes
!
interface Vlan2
description TO-APPLICATIOn-SW
ip address 10.2.32.232 255.255.255.0
ip helper-address 10.2.3.1
ip pim sparse-mode
ip igmp version 1
ip ospf message-digest-key 10 md5 <>
nd

[Edison Ortiz]

The command ip igmp version 1 will not force the receivers to run on that mode.

The router or switch will still be able to support igmp version 2 and version 3 on hosts attached to the subnet.

This command is only for L3 device-to-L3 device communication and must be the same on all L3 devices in the subnet.

Refer to the usage guidelines:

http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_02.html#wp1047837

As far as the lack of RP on your output, if you noticed the flags, (sPTI) it denotes this source is running on SSM mode.

If you do a 'show ip mroute' the flags will be listed with their respective meaning.

In addition, this source is not sending to any receiver as the OIL is null. Thus, the output is not from a functioning multicast flow.

Regards

Edison