Bob Henderson last edited by
Just a question to see if this is possible. Multicast over my lan is slow enough that unicast ends up being a better option. We’re talking pushing maybe 60 Mbps. I’m sure this is something to do with the config of my Cisco switches, but unless it’s a super quick fix, that’s neither here nor there.
I’m wondering the following:
I setup a physical fog server, replicate over the images from my master server. Import all my hosts into it as well. I plug this server into a switch, and plug all my clients into that switch. I plug the switch into the network, and update my DHCP settings to point to this new, physical fog server.
clients boot. get to the join multi-task option on all clients. disconnect the switch from the network, effectively isolating it. join the task on all of them.
Image hopefully goes as fast as it can.
Once image is over, replug in the switch to the network, allowing the clients services to see the master server, join AD, etc.
Am I overthinking? I’m stareing at a pile of 700 laptops to image, and I’d love to be able to do them 46 at a time…
The devs are still busy folks…
From the RC4 change log
- Fix multicast issues for the fog service.
- Fix multicast not closing on task cancellation from active tasks page (hosts are being untasked but session still exists.)
From the RC3 change log
88197b5 Update Version to 1.3.0-RC-3
f31b852 Merge branch ‘working-RC-3’ into dev-branch
3fd5ff3 (origin/working-RC-3, working-RC-3) Enable snapin location altering or not via locations.
58709a1 Update iPXE files to latest pull.
b1f9240 Add back the 7156 efi files for ensuring surface pro’s can still boot.
a9652be More accurately display multicast and don’t create a tasking, but do report why the tasking couldn’t be created.
99ef87a Make sure only multicast sessions that have a defined session client count are able to be used for multicast session joining.
627348c Use the fullPath variable for the multicast task.
363ef28 Ensure multicast continues even if the file cannot be found. Otherwise it will fail for that node and nothing after that point will run properly.
3cf50e3 Properly link progress row with it’s task.
67d5ebe Fix issue with multicast sessions being cleaned before they’re even booted.
2b692a7 Fix issue with printer memberships
289524f Fix getting the snapin job variable as there was a typo.
98921af Add expand-child element to the progress row.
ed70684 Make sure version is incremented
3eae96c Remove accesscontrol plugin
8327f66 Make fog configuration use ajax for kernel versions.
a8acad2 Address issue with nodes blocking load of the page.
5158f67 Fix upload last time not setting.
f2d8d72 Fix split call.
Wayne Workman last edited by
@Bob-Henderson Please update to RC-4, it addresses some multicast issues, and I imagine you will need those fixes for this project you have planned.
The key is having a switch that can forward data to all 46 ports. That netgear should be OK, if you were using one of those cheapish 5 ports switches I’d have some concerns about its forwarding rate.
Bob Henderson last edited by
Yep, we’re using Vlans. I’m 100% sure it’s going to be my switches that are currently giving me the issue, but am in a bit of a time crunch.
I’ll be putting in a netgear switch, since I have a few of those spare. One of the GSM7248v2 models. Not as good as a spare Procurve or the like, but it’s what I’ve got.
Luckily, all devices I’m working with here are modern (haswell or newer) i5’s with 8g of ram and SSDs, so I hope it’ll keep up.
In the case of multicasting, the slowest device on the multicast channel will set your maximum throughput.
Also if you are using vlans (maybe if you are not) you need to enable igmp snooping on the vlan in your switch configurations, where your clients are. This will let the switches listen to multicast subscribers and only send data to the ports where there are subscribers.
That is a solid plan. The only comment I can make, is make sure your deployment switch is an enterprise class switch and not a low end unmanaged switch.