Ghost Solution Suite

 View Only
  • 1.  Ghost Solution Suite 2.5 freezing during multicast

    Posted Mar 28, 2011 02:25 PM

    Hello everyone,

    I am running into some issues with our ghost multicast sessions and was looking for some help.  When we attempt to multicast multiple machines the ghost cast session will freeze at random times and will not complete.  Unicasting multiple machines works fine though.

    We have Dell Precision T3500 machines and we are using the onboard NIC, Broadcom net extreme 5700 series.  They are running through Juniper switches.  Some of the troubleshooting we have tried is multiple images, and multiple PCs, all with the same result. 

    Another issue we are running into is that when trying to multicast more than 2 PC's the ghostcast session will not even start up.  It just sits at teh "Waiting for ghost cast session to start" dialog.

     

    If anyone has some insight on this issue please let me know, it is much appreciated!

     

    Thanks,

    Ken Evans



  • 2.  RE: Ghost Solution Suite 2.5 freezing during multicast

    Posted Mar 28, 2011 03:50 PM

    Could you check whether IGMP and multicasting has been enabled on the Juniper switches?

    Also, have a look at this thread: https://www-secure.symantec.com/connect/forums/dell-powerconnect-5324-multicasting



  • 3.  RE: Ghost Solution Suite 2.5 freezing during multicast

    Posted Mar 28, 2011 05:53 PM

    Hello Edt,

    thanks for the response on this issue, I have looked into the switches IGMP and multicasting are turned on for the switches.  I have seen on different forums that indicate to turn off and turn on IGMP.  I am not sure which would be the recommended, i think it is to leave that on.

    Any other thoughts are greatly appreciated.

     

    Thanks,

    Ken Evans



  • 4.  RE: Ghost Solution Suite 2.5 freezing during multicast

    Posted Mar 28, 2011 11:33 PM

    Cisco's documentation is excellent about explaining the concepts of IP multicast: http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094821.shtml

    Although you absolutely should read the above, the executive summary is this:

    - 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. ]