Here are a couple of old postings by Nigel Bree, former Ghost Developer. In the absence of any other postings I hope this is of some assistance. Try using the search function on "snooping" as it may throw up other content.
//////
- You absolutely should have "IGMP snooping" enabled on all the managed switches in your network which can support it, because without this the switches emulate the behaviour of classic IEEE 802 Ethernet in respect to multicast frames, which is to broadcast them. You DO NOT want this if you have applications which use IP multicast heavily. Enabling switch-level IGMP support brings the efficiency benefits of IP multicast down to the level of switch ports, and in particular allows the switches to avoid distributing multicast frames to switch ports which are in low-power states, where it is common for the port to be autonegotiated to a 10mbps speed.
- "IGMP snooping" is a switch concept which is not a part of the IGMP protocol or the IETF IP network architecture; IGMP snooping in switches instead piggybacks on the IGMP protocol, which is a protocol conceptually provided by routers in the IETF architecture - when this snooping is enabled, switches (which are really point-to-point routers that are emulating a broadcast bus) then use that routing information to determine how to route frames to their individual switch ports.
- The part of the IGMP protocol provided by routers is called IGMP querying: in order to work correctly, IGMP snooping requires at least one active IGMP querier to be servicing the network segments covered by the switches. This can be provided by a router, and the majority of modern managed switches can also provide this capability.
- Although the IGMP protocol specification details techniques by which multiple queriers vote amongst themselves (by IP address) to ensure only one query source at a time is active, some switches have appeared to not honour this part of the IGMP specification properly. See for instance https://www-secure.symantec.com/connect/forums/ghost-115-flooding-our-network and so some care may need to be taken in selecting which device(s) have IGMP query generation enabled.
- Sometimes, dedicated routers or devices such as managed switches with routing functions do not have a particular configuration setting for generation of IGMP queries. On such devices, IGMP query generation is implicit, and enabled by the configuration of inter-router protocols such as PIM. So, depending on your vendor it may or may not be necessary to configure PIM support on some device(s) to ensure IGMP query generation. Enabling PIM may have some consequences beyond the local switched network, however, so if you are considering this it's generally a good idea to read your vendor's documentation thoroughly.
Note there is nothing Ghost-specific about any of this; IP Multicast is a standard part of the IETF network architecture and has been since about 1989, while the "IGMP snooping" extensions to switches (which piggyback on the IETF standard IGMP protocol) have been defined by switch vendors and all have basically worked the same way since the mid-to-late 1990's. It simply happens that since Ghost's protocol code was written to the IETF multicast architecture but before IGMP snooping became a widely deployed technique, it's not designed to cope with the hard-to-detect failure modes resulting from incorrect network configuration due to not installing an IGMP querier. Unfortunately, since Ghost is also one of very few applications (other than telephony) which makes extensive use of IP multicast and offers significant network load, it's generally the only thing on many corporate networks which is sensitive to the network's multicast configuration.
When a switch is configured to use IGMP snooping but no IGMP querier is present, the most common presentation is that a networks on which IP multicast appears to be working perfectly for a short time suddenly stops working altogether as the switches time out and unilaterally block delivery of multicast traffic to their ports. Because the switches do this without issuing any advice or control traffic to anyone and because the TCP/IP stacks in operating systems do not provide features for applications to detect whether an active IGMP querier is present, detecting this failure mode automatically is hard (and when it happens, there is very little that applications can do about it).
[ Edited to correct the link to one of my earlier posts on this subject. ]
Ghost uses IPv4 standard multicast; a great many switches are not configured correctly for this extremely simple part of standard TCP/IP networking, but every switch vendor has documents explaining this and how to configure it, and I've written many dozens of posts here on these forums on the topic of configuring switches for this.
Basically, the problem is a switch feature called IGMP Snooping - IGMP is a standard protocol used to communicate with routers that Ghost uses in a perfectly standard way. Since modern switches are only *emulating* classic Ethernet, they really behave more like routers, and IGMP Snooping is a technique the routers employ to piggyback on the actions of real routers to efficiently deliver multicast traffic to only the switch ports that subscribe to it.
However, to use it you must also have the network enabled with the proper router support - in particular, having a router or similar device generating standard IGMP query traffic; without this, the router is aware of machines initially subscribing to multicast groups but then times out those associations after a few minutes, which leads to precisely the symptoms you describe.
Exactly how to correctly configure this depends slightly on what network equipment you have, but all the switch and router vendors have extensive documentation on how to do this properly. It's a simple process which may just be a matter of changing one configuration either in your routers or switches.