Video Screencast Help

Multicast traffic

Created: 20 Aug 2013 • Updated: 21 Aug 2013 | 5 comments
This issue has been solved. See solution.


Recently I installed a Microsoft Windows 2008 R2 server, with DHCP, AD, WDS and Routing and Remote Services Roles.
This server is supposed to be a Ghost Server, which works pretty good.. except for Multicast traffic.

I've read dozens of articles stating that IGMP snooping has to be activated on switches e.t.c., but this is the case.
IGMP Snooping is activated on all switches that my VLAN comes into contact with, so that may not be the problem.
However, the issue that I am receiving is that clients can connect to the ghostcast server, that the session becomes 'In Progress' but nothing happens. The clients do not receive the actual traffic.. they are just 'waiting for session to start'.

If I stop the ghostcast server, some clients receive a time-out or other error, other clients are just standing there, 'waiting for session to start'.
Some times, Ghostsrv.exe just chrashes as soon as I click Stop..

Unicast works without a problem, but Multicast and Directed Broadcast do not.
When I manually start the devices to ghost32.exe and click Ghostserver-->Multicast --> Sessionname --> Ok, Ok, Yes.. then the devices actually start running, but it is unicast (because they start directly, without waiting for the others). However, it says in the status screen that it is Multicast.

Somehow, I guess, the Multicast traffic does not reach the clients.. I can see the clients talk to the server, but as soon as Start or Send is pressed, (or Autosend starts), the whole process dies.. without either the server nor the clients knowing it..

i receive 0 error messages during this whole process..

Some background information:

We are imageing clients with images delivered to us from customers. So we cannot change anything on the actual images. Sothat's why we use WDS for PXE-Boot (it's 500% faster then TFPT), and we only have 1 server for all 5 purposes, because the max load will be 100 clients per run.. 

Operating Systems:

Comments 5 CommentsJump to latest comment

EdT's picture

What version of Ghost?

Are you booting DOS or WinPE via PXE Boot ?

Here is a copy of a forum posting submitted by one of the Ghost developers:

Ghost Solution Suite 2.5 freezing during multicast

To clarify how this works

Cisco's documentation is excellent about explaining the concepts of IP multicast:

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

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

AlexvandenBos's picture

I did indeed read that article, and the article pops up a few times in every multicast-related issue.

However, as I stated: IGMP Snooping is enabled on every switch to which I connect. 
To answer your other question: I use Ghost 11.5.1 and boot to Windows PE3 (win7 pe)

I do have another ghost-server, on another LAN, which uses Windows 2003 and TFPT boot (instead of Windows WDS) and this works without any troubles.

However, this server is on another subnet (11.0.0.x / than the 'new' server (192.168.120.x / so it should not interfere, but that's an assumption....

EdT's picture

However, you do not mention whether there is an IGMP querier defined.

You may also want to review this thread and the association article if you are using WinPE 3.x as this version is not natively supported by Ghost. Terry Bu has done some valuable work on how to best incorporate WinPE 3 into GSS.

Finally, have you disabled the firewall in WinPE ?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

AlexvandenBos's picture

The switch which has IGMP SNooping enabled is also the IGMP Querier.

We also tried Windows Routing And Remote IGMP Router / Querier, but to no avail.

Yes, the firewall is disabled on all devices in the network, including the server and the clients (wpeutil disablefirewall is run during boot)

I did not mean to sound harsh, I really appreciate you trying to help me

AlexvandenBos's picture

The issue has been resolved:

The Firewall on PXE Clients refused to be turned off during startnet.cmd (wpeutil disablefirewall), I was sure of the fact that I put in startnet.cmd, but somehow it did not actually commit and I assumed that is was disableing the firewall but because it ran directly after WPEinit and miliseceonds before closing the initial dosbox, I did not see any confirmation or errors.

Due to the fact that a little voice inside me doubted myself, I disabled the firewall by hand, and boom, the clients started deploying.

to all: Thanks for your help!