Multicast Imaging

When a room full of machines images at once, every one of them downloads the same WIM. Multicast sends that WIM once, to a group address all of them listen on, instead of once per machine.

It is off by default, and it is worth understanding why before you turn it on: multicast only works if your network agrees to carry it. FluxDeploy cannot make that happen and does not pretend to. What it does instead is fail over quietly and quickly, so a network that will not carry multicast costs you nothing beyond half a minute per machine, once.

Turn it on at Settings > Deployment > Agent & Multicast.

Should you turn it on#

What your network has to do#

Multicast is not like unicast. A switch does not learn where a group lives the way it learns a MAC address, so by default it has two choices: flood the group to every port, or forward it nowhere. Which one you get, and how to fix it, depends on your equipment.

On a single VLAN, on one switch. This is the easy case, and the one most imaging setups are in.

• IGMP snooping lets the switch see machines joining the group and forward the stream only to the ports that asked. Without snooping, most switches flood the group to every port. Multicast still works that way, but every other machine on the VLAN receives the whole WIM too, which is a lot of traffic to push at devices that never asked for it.
• An IGMP querier is what makes snooping work. A snooping switch with no querier on the VLAN eventually ages out every group membership it learned and stops forwarding - so the transfer starts, runs for a minute or two, and then stops dead. That failure looks like a flaky network rather than a missing setting, and it is the single most common cause of a multicast deployment that works on Monday and not on Tuesday. If there is no router doing IGMP on the VLAN, enable the querier on the switch.
• Some switches, given snooping and no querier, flood instead of dropping. Some drop. Do not rely on which yours does.

Across routers or VLANs. A router does not forward multicast unless it is told to. That means PIM (PIM-SM with a rendezvous point, or PIM-DM on a small network) on every router in the path, and the TTL on the FluxDeploy side raised high enough to survive the hops (see below). This is real network engineering, and if you are not already running multicast routing it is usually not worth standing it up just for imaging. Put the imaging server on the same VLAN as the machines instead.

Wireless. Do not. Multicast over Wi-Fi is sent at the lowest basic rate and is not acknowledged, so it is both slow and lossy. FluxDeploy has no retransmit (see below), so on wireless the transfer will almost always end up falling back anyway.

What happens when the network will not carry it#

Nothing bad, and that is the design. The agent asks the server for a session, joins the group, and waits. If the datagrams do not come, it downloads the image over HTTPS exactly as it would have with multicast switched off, and the deployment finishes normally.

The only cost is the wait, and it is bounded:

There is no retransmit. UDP multicast has no mechanism to ask for a packet again, and FluxDeploy does not build one. So the agent's job is to notice that something is missing rather than to repair it, and anything missing means the whole attempt is abandoned and the partial file deleted. That is deliberate: handing on a half-received WIM would turn one lost packet into a failed deployment, when the right answer is a slower download.

The SHA-256 check is the same either way. A multicast-assembled image is hashed against the server's record exactly as a downloaded one is. If it does not match, the agent reports MULTICAST_INTEGRITY_FAILED as a warning, deletes the assembled image, and downloads it ONCE over unicast - verified the same way, and halting with INTEGRITY_FAILED if that copy fails too. The stream itself is not authenticated, so a single forged datagram on the segment could otherwise stop every machine in a session after its disk was wiped. That warning exists to tell you something specific: the WIM on the server is almost certainly fine and this network corrupted the transfer in a way the chunk accounting could not see, so the action is to turn multicast off here, not to re-upload the image.

Telling which one actually happened#

This matters more than it sounds, because a working multicast deployment and a completely broken one both end with a green "Completed". The fallback is silent by design, so you have to go and look.

The deployment console is where it is written. Open the machine under Activity > Deployments and read its log. Every outcome is stated in full:

• Joining multicast session for image 3 on 239.255.42.1:9100 - the agent asked and the server said yes.
• WIM received over multicast: 5368709120 bytes in 655360 chunks - it worked.
• Multicast transfer did not complete (NoTraffic: no multicast traffic on 239.255.42.1:9100 within 30s - this network is not forwarding the group) - falling back to unicast download - it did not, and the parenthesised reason tells you which of the four cases above you are in.
• Multicast not offered for image 3 - downloading over unicast - the server declined. Either multicast is off, or the concurrent-session limit was already reached.

The quick read: if the machines finished in about the time a single unicast download takes multiplied by the number of machines, multicast is not working no matter what the settings page says. If twenty machines finished in roughly the time one takes, it is.

The settings, and when to change them#

All seven live on Settings > Deployment > Agent & Multicast.

When a change takes effect#

No restart is needed for any of them. What differs is whether a change reaches a transfer that is already running, and none of them do. A stream in flight keeps the settings it started with, because the agents receiving it have already joined a group on a port and agreed a datagram layout - re-pointing a live stream would desync every one of them and corrupt the image they are assembling.

Accepted values: the group address must be an IPv4 address in the multicast range 224.0.0.0 - 239.255.255.255; base port 1024-65535; send rate 1-1000 MB/s; max sessions 1-16; chunk size 512-65000 bytes; TTL 1-255. A value outside those bounds is refused rather than quietly clamped, so the page never shows you a number the server is not using.

Relay sites#

The settings reach every relay, through the same sync manifest that already carries the unattend settings and the organization details. A relay applies them to its own streaming service on the next sync. There is no restart, and nothing to configure at the branch.

This is the case multicast is actually for. A relay serves a branch office, and the link that hurts is the one into that office, so ten machines at a branch each pulling the same WIM is the problem worth solving. Multicast that only worked from Core optimised the one site that was already fine.

Per-site overrides#

Site detail > General > Multicast WIM streaming.

The other settings families in the manifest describe the deployment, which is the same wherever it runs. These seven describe the network the stream crosses, and that is a property of the site: one branch has IGMP snooping with a querier and another floods the group to every port; one uplink is 10 GbE and another is a closet switch; 239.255.42.x may already be spoken for at one location.

So a site can override any of the seven, and every box shows where the value in force came from:

Leave a box on Inherit to follow Core; clearing an override returns the site to the fleet value on its next sync.

Overrides are authored here in Core, not at the relay. A relay has no multicast settings page of its own. That is deliberate: a value set at the branch would be invisible from the console that is supposed to be able to answer what a given site is running.

One consequence worth knowing: a relay that has lost contact with Core cannot locally turn multicast off. That is tolerable because a network which is not forwarding the group costs each machine a single 30-second timeout before it falls back, and the server stops streaming once its last client has gone.

Troubleshooting#

See also#

• Settings Overview - every settings page and what lives on it
• PXE Boot - the network boot chain that gets the agent running in the first place
• Error Codes - including MULTICAST_INTEGRITY_FAILED
• Relay Sites - what does and does not sync from Core to a site