Multicast issue
-
I am unable to multicast. It always hangs. I can capture, and I can unicast to the subnet I’m trying to, but no multicast.
Here is my debug error when attempting to multicast. I’ve looked for /var/log/partclone.log but it doesn’t exist:
This is fdisk -l on the client during debug:
Here is the hang:
I’m just not sure how to troubleshoot from here. I’ve run through all the wiki’s and troubleshooting steps and forum posts I could find on the subject. I’ve also rebuilt twice. Any help would be greatly appreciated.
-
@mashley Multicasting requires more infrastructure cooperation than unicast imaging. This failing is not typically the FOG server or fog imaging root cause.
Multicasting (in general not specifically FOG imaging) uses multicast messaging. Multicast messages are typically blocked at your subnet router. So multicasting works correctly on the same subnet where the FOG server is, but on a different subnet it needs a helper service, just like DHCP needs a helper service to cross subnets. They kind of use the same technology but different. On your subnet router for dhcp you normally run a dhcp-helper/dhcp-relay service. Multicasting needs either you to enable the mrouter service or “igmp proxy” service to send multicast messages between the subnets.
-
@george1421 Thanks for you response.
I decided to just put the FOG server on the same subnet (instead of getting in the switches and messing with them more).I followed these steps to make sure the migration happened properly - https://docs.fogproject.org/en/latest/reference/change_fog_server_ip_address.html
Everything is working now!!! At this point, I wouldn’t mind creating a new server for each subnet that I’ll be working with because my switch work (these are really old HP switches and the router is an old L3 switch) apparently didn’t do anything when I tried to get igmp working a few weeks ago. Again, thanks for your help! I know that I understood what logically needed to be done, I just needed that logic explained to me in someone’s own words.
-
@mashley Just to complete this thought, on your switches enable igmp snooping. Multicasting works in 2 different modes. Sparse mode and Dense mode. You decide this based on how close the multicast recipients are to each other. This has nothing to do (well kind of) with imaging but multicasting.
Think of multicasting dense mode in that most of the ports on a switch will connect to the multicasting stream. So the multicasting stream is sent to all ports on the switch. There is a certain advantage for this if most of the ports are participating in the stream. Sparse mode is when you have one or two multicast receivers on each switch. With IGMP snooping the switch learns what ports have a multicast subscriber and then only sends the multicast stream to those ports and doesn’t flood the other ports with multicast traffic where there are no subscribers (that would be dense mode).
That was a long explanation to say turn on igmp snooping on the vlans where you expect to have multicast subscribers.
That igmp snooping will only help with the multicast subscribers and not crossing your core router. For that you still need an mrouter or igmp proxy.
-
This post is deleted! -
@george1421 Ok, thank you for that information. I’ll use that if I find out I need to.
I do have one further question with the multicasting I’m doing now - What may cause the task to basically stop? I haven’t paused the task and my clients look like they’re still getting the image, however, the rate is now down to 162mb/minute and dropping, and it’s been stuck at 27% completion for a little while now. Didn’t take long to get to that point, but now the rate is dropping. I double checked my layer 1 connections because I figured I bumped something (I did apparently bump something and lost connection once), but the rate is still dropping. Do I need to restart? Not sure what would cause that other than layer 1. I’m looking at my hosts in the GUI and I see that the status of only one of them is unknown, while the status of the other two (only testing three at a time at the moment) show the OS. I feel like that shouldn’t pause the task, but I’m not a super pro at this point.
Thanks again for any help you can provide. -
@mashley With multcasting only one image is sent out from the server. So all the clients that participate in the multicast image work in lock step. So the speed of your image deployment is based on the slowest computer in the group. You do want to kind of group like systems (performance wise) together in a deployment group to get the best performance. If you have fast computers but one is behind a 100Mb/s link, that one behind the slow link will slow down the entire group.
