Problems multicasting fog on different vlans
-
-
I Made a new very basic setup with just the fog server a router and a host. I configured the router to allow multicast.
I get the same result, everything is working: dhcp, unicast etc. Just not multicast. So i think fog is causing the problems. I’m just really lost what is wrong. FOGMulticastmanger is active and working, the multicast settings in the webinterface are all correct. Dhcp and the image are working fine. Mysql still remains a mystery to me though. I’ve got no experiecne with it on linux so.
-
From one of the wiki pages of fog it makes you check these files.
“Check the MySQL details in “/opt/fog/service/etc/config.php” are correct.
If not, correct them (they should be the same as in /var/www/fog/commons/config.php) and restart the service”
*
this can’t be right. There is not much in the first config.php file and the 2nd under commons doesn’t even exist.
-
@Yamakazi That wiki is outdated due to relatively recent changes I believe
-
@Yamakazi said:
FOGMulticastmanger is active and working, the multicast settings in the webinterface are all correct.
Checked the multicast.log? Do you see udp-sender processes in
ps ax | grep udp?I might be wrong but I feel that this is not a general FOG issue as we have a lot of users who are running multicast imaging just fine. What if you connect one FOG server and two or three clients just with one simple dumb mini switch? Not router!
-
@Yamakazi Also, your syntax is indeed wrong.
You need to do
use fog;first. Then try and run those other commands after that.
-
UDP running
*
This is to different vlan. Is it normal it broadcasts to 224.0.0.1? Because i see in wireshark it doesn’t get further than the first router it encounters on 224.0.0.1 (see pic a few posts back)
*
To the same subnet multicast is working properly.
*
Was also able to clear mysql database but to no avail.
I already tested the setup in the same subnet and that works. I’m just don’t seems to get it to work on different subnets.
How does fog multicast? to which multicast address? Does it make a multicast address and lets clients join it? or is it a set multicast address? Because it’s sending to 224.0.0.1 atm, which seems a bit weird.
-
This post is deleted! -
Alright it seems it has something to do with multicasting groups not properly reporting to eachother.
When fog starts a multicast session it send to 224.0.0.1 but it stops there and doesn’t get forwarded to other clients in different subnets
*
When in the same subnet, It manges to request to join that specific multicast group get the data en then again leaves the mcast group.
Though it’s doing this directly with the fog server and not trough the general 224.0.0.1 which normally request host to join or leave a group.
*
I know this is maybe not that fog related anymore, but we came this far already
Hosts in a different vlan listen to 224.0.0.1 to report their status. For example
*
-
Is it possible to change the multicast adress of fog somewhere? to something different then 224.0.0.1 ?
-
@Yamakazi You can specify the multicast address, but not the broadcast address I think. This seems like a routing issue, not a FOG problem, but I don’t really know enough about networking to say for sure.
-
Where could i change the multicast adress? Haven’t seen it anywhere in the options.
-
@Yamakazi Under Multicast settings - FOG_MULTICAST_ADDRESS default value is 0
-
-
@Yamakazi I’m guessing you’re on FOG 1.2 then? Not on trunk? Might be worth upgrading and see if that helps.
-
I’m not sure that 1.2.0 or trunk can multicast to more than one address. In 1.2.0 it uses the broadcast address of the broadcast domain the server resides in. In trunk, the same is true unless you define a custom address.
You can setup some custom multicast handling if you want, and have that traffic sent throughout your organization - but there’s no easy way to swap destination addresses easily in 1.2.0. Even with FOG Trunk it’ll be repetitive but doable.
You will need to figure out how to handle the traffic on your switches and routers.
-
@Yamakazi Good finds! Check out udp-sender’s man page and you’ll see options like
--mcast-rdv-addressand--mcast-data-address. I guess you could play with those and patch your PHP files in FOG 1.2.0 to achieve this. On the other hand I think this shouldn’t be need as multicast addresses ought to be “universal” and not depend on IP addresses used in the subnets. But possibly I just don’t know enough about multicast. What I know is that we were using multicast for three different subnets (separated via VLANs!) at my old working place. Worked like a charm after I had setup the multicast routing stuff on all the switches properly. Unfortunately I can’t remember all those settings in detail as this was years ago. -
Thank you. I’m going to try to get my hands on a sever and a few routers to try this in a real environment and not a virtual one. I think this is giving me issues.
But i’m still not sure on what address fog multicasts? Is this a fixed address? or based on your current subnet? can i find it anywhere in the config files? I know the trunk version let’s you chose the multicast address but i’m having other troubles with that version + a friend of mine got this version perfectly working in his business environment so i want to atleast try to get this working.
-
@Yamakazi It’s based on the fog server’s subnet, specifically the node settings in Storage Management. It uses the last address in the range, the broadcast address, by default. Again in Trunk, you’re able to change this. In 1.2.0 you cannot unless you want to do it in PHP.
-
@Yamakazi It’s all explained in the man page I posted:
–mcast-rdv-address address
Uses a non-standard multicast address for the control (rendez-vous) connection.
…
By default “mcast-rdv-address” is the Ethernet broadcast address if “ttl” is 1, and 224.0.0.1 otherwise. …So multicast control connection should be on address 224.0.0.1 I suspect! And then:
–mcast-data-address address
Uses the given address for multicasting the data. If not specified, the program will
automatically derive a multicast address from its own IP (by keeping the last 27 bits
of the IP and then prepending 232).Means 232.x.x.x if I don’t get that wrong.
