link470 (23rd April 2010)
Okay heres the deal, i set up a ghostcast server for a building to transfer images on but when i start ghost casting the image to the clients the internet stops, but when i'm making the image from the clients to the server, the internet works fine. Is it too much bandwidth being used or something????
Soemething to do with your networking harware does not like multicasting. You say the internet goes off but what about other network services? Have you tried pinging a server from a client to see if there is packet loss etc?
Ideally you want all managed switches that support IGMP filtering so that multicast only goes to the required ports. At minimum you want the core switch to support it, with the ghostcast server plugged into that.
For now you could also try limiting the ghostcast bandwith to to something like 200MB/min and see if that helps.
We try to keep ghosting for out of hours, as we sometimes find wireless users can't connect to the network!
The Ghost upload from client to server is directly between the two devices traffic is handled like any other.
The "Ghostcast" from server to multiple clients is sent to all clients on all ports using a [ame="http://en.wikipedia.org/wiki/Multicast_address"] multicast [/ame] IP address.
All participating clients will see and hear all of the traffic being multicasted, and of course the multicast packets will also have to pass across any switch uplink/downlinks you have, hence everyone else has to sit and wait for their turn to send!
If you have one bad NIC/RJ45/Jack or Patch lead on a client the packets will be resent time and time again until acknowledged or timed out so you had better make sure that all of your connectivity is in good shape before you choose to multicast.
I expect you have a single collision domain eg. one subnet with all clients connected.
In this case without very clever switchery it is not possible to contain the multicast enough to prevent the blocking of your other traffic.
As DMcCoy said, you might be able to throttle the speed so as not to flood the network however in practise on it's own this rarely works.
The analogy,
You have 20,000 cars parked in the Lot at Universal Studios and at 5.00pm you order all of them to vacate the Parking lot and relocate to Disney as fast as possible!
For the next few hours nothing gets on or off of the I4.
With proper traffic management the best you can hope for is to get every one home eventually!
With a correctly configured topology utilizing VLANs trunked links and IGMP Filtering you will manage it but how often do you need to image an entire suite in the middle of the day!
If you haven't done so already, make sure IGMP is enabled on all of your switches.
If possible try and make it so that the switch that has the ghost server connected to it, becomes the IGMP querier.
You can ensure it becomes the querier by enabling IGMP on it first - or by specifically prohibiting the other switches to be querier. Some switches let you do this in the GUI but for many it's a job for the CLI so check your switch manuals.
On 3Coms two IGMP settings need to be enabled.
Under the properities for bridge/multicastFilter/igmp are the options for queryMode and snoopMode. Both must be enabled.
This should ensure that the packets are delivered only to participating clients.
If your edge switch is connected directly to the IGMP querier this will help but if you have to traverse uplinks these will still be saturated unless LAGGED (Link Aggregated) and that takes us to another chapter....
link470 (23rd April 2010)
thanks for the wonderful advice, ill be sure to check these steps out on monday when i go back in.
thanks again,
devin

Not tried it on that scale but I had similar issues saturating a smaller (100Mbps) network which was resolved by merely switching to unicast in Ghostcast, which may or may not be an option for you to consider. I'd guess that depends how many images you're doing at a time (even though I can't personally remember the difference, this is going back a few years and have switched to Acronis since)
I use unicast during school hours if ghosting, otherwise the wireless starts to run like a dogs dinner.
I was doing a few last week and a 5 gig highly compressed ghost image on unicast was about 25 mins, on a multicast just over 10 - [ and that was going through a 100 meg switch & forcing the duplex on the cards ]
Hi,
Our switches that the PC's are plugged into are old now. but the backbone is a 3COm 5500G EI. The ghost cast server is plugged direct in to this and IGMP snooping is turned on. No problems multicasting, i warned them the first the time we did this with this setup and they actually thought the network was faster.
conrad
Last edited by EduTech; 13th June 2009 at 08:57 PM.
I am having same sort of problem with multicasting - even dumping an image from a client seems to be causing problems. I will look at what difference unicasting makes, and at the IGMP settings. But what puzzles me is that we were previously using ghost32.exe with Learning Network Manager, and I could boot from LAN and send an image to 6 clients at same time without needing to run ghostcast server and without any problems on the network. Same hardware but using ghostcast server and now there are problems.![]()
IGMP Snooping on your switches is essential
Are you using Symantec Ghost? As what we ended up doing was setting up the ghost cast server on a laptop, with the images. Then taking the laptop down to the area where the ghost is happening, plug the laptop into the local switch and accepting clients, but not sending. As soon as all clients are accepted then disconnecting the switch from the network and pressing send. This is so all the computers get an IP from DHCP.
It works really well, and it doesn't kill your bandwidth from everywhere esle either. Should stop your internet problem to![]()
bondbill2k2 (20th October 2011), link470 (23rd April 2010)
There are currently 1 users browsing this thread. (0 members and 1 guests)