FOG - Killing our network

[GreyFox]

Hi all,

 

After getting FOG working thanks to the people here, we've now run into another problem. FOG is killing our network! Any ideas please?

 

I've already turned down the speed of the network card in our FOG Server

 

'sudo ethtool -s eth0 speed 100 duplex half autoneg off' - But we're still having issues when multicasting - even just 4 machines! I could turn it down to speed 10...which I guess wont make much difference as according to FOG the bandwidth usage is only 10MB/s anyway. We were fine in the past with Windows XP deployment. Is this just down to our network?

 

Thank you in advance,

 

Grey Fox

[maniac]

When you say 'killing your network' what do you mean?

 

Sometimes multicast activity can cause network issues, specifically with wireless access points and certain routers in my experience as the packets flood these devices and stop them working. If your switches support IGMP then turn this on, as this will then control the multicast traffic and send it only where it is needed.

 

Mike.

[GreyFox]

Sorry, by killing, I mean grinding the network to a halt for most users, causing web pages to load incredibly slowly - or not at all and in some cases making machines unusable.

What you said about WAPs sounds familiar. We had a number of people complaining their laptop's wireless connection had stopped working (red X) - connections to network drives going as a result.

 

I believe IGMP is already switched on. We had been fine with multicasting with XP. I shall have to double check this.

 

Thanks

 

Grey Fox

[maniac]

Yes that does sound like certain devices on the network are being flooded and therefore the normal traffic can't get through. We get this with our Cisco wireless access points when we use multicasting, although we only use it in the holidays so it doesn't really matter too much. However it shouldn't cause this sort of problem if your switches are setup properly for it.

[morganw]

I could never get multicast transfers to work with our switches, in the end I just reduced the maximum queue size on the storage node to 2 and let everything queue with unicast transfers. The maximum unicast transfer time we have is about 2 minutes and by staggering each deployment you've just created a poor man's load balancer for any post-imaging task that you may have.

[6Foot2]

We had a similar situation with Symantec Ghost before we had our VLANs configured.

 

Once setup the VLANs addressed our problems. However we are now trailing WDS for deploying Windows 7 and it is looking promising.

 

I realise that this may not be the reply you were looking for but I feel that WDS is a viable alternative worthy of your consideration.

[GreyFox]

Will find some time to double check these, but like I said, we were fine when deploying XP.

 

Morganw - 2 mins transfer time!? What size are you images? Our two are 15.8 and 16.4GB. Quickest we've had unicast is about 12 minutes I think. Might be worth looking in to your solution though during normal working days.

 

DaveP - We tried WDS, then came back to FOG. We couldn't get WDS to multicast, no matter what we did. I spent hours, maybe days searching for solutions and trying things out. Plus FOG is quicker we found. Plus, we couldn't get it working for a couple of machines types. Didn't seem to be a driver issue - drivers where there.

 

Thanks

[morganw]

We have a (almost) universal image which is 3.4 GB, applications are installed after this as snap-ins. Most computers can download this in about a minute.

I'm moving to WDS / MDT2010 for OS deployment, it is slower but I'm struggling to manage drivers with the traditional flat sysprep approach. I gave up on multicast deployment a long time ago and haven't required or missed it.