Problem with VRRP



  • Hello,

    We use CloneDeploy in diffrent subnets of our network. Everything is working fine, except when we user multicast, at that moment de DHCP-Server isn't providing any new IP-adresses in the subnet.

    I contacted global support and the could see there is a conflict with the VRRP (Virtual Router Redundancy Protocol) when using multicast in CloneDeploy. The VRRP is also using multicast and this gives problems when using the CloneDeploy multicast.

    Is there any solution for this?
    We really would like to use this multicast, but we can't afford to break the dhcp-server during this multicast.



  • I really only have one option for you, this is out of the realm of my expertise but you can give it a shot. The CloneDeploy multicast uses 224.0.0.1 to handle control and 232...* to transfer the data. I'm guessing the actual data transfer on 232 is not causing a problem but the control is. 224.0.0.1 is an address for all systems, maybe your routers are trying to respond to that. We could try and change the control to either 224.0.0.3 which is unassigned or the ip of your CloneDeploy server. See here for references.
    http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml

    In CloneDeploy web, admin->multicast->sender arguments(server) try adding this.
    [code]--mcast-rdv-address 224.0.0.3[/code]

    Like I said you could also try your CloneDeploy Ip but I suspect that wouldn't work across subnets.



  • Thanks,

    I will try this out ASAP



  • I tried to play with the settings in In CloneDeploy web, admin->multicast->sender arguments(server), but whatever I change there, it seems to have no effect.

    I found a manual for udpcast on the internet:
    https://www.udpcast.linux.lu/cmd.html

    It says this --mcast-rdv-address 224.0.0.3 has to be added on server en client side, I tried both, only as server argument, both as server and client argument, but when the multicast starts, I see that the clients still connect to the ip-adress of the clonedepoy-server, not at 224.0.0.3.

    I also tried to add "--ttl 2" instead, the manual says it should take 244.0.0.1 as ethernet broadcast address, but this also has no effect.

    So I wonder if these arguments have any effect at all?

    I tried to add --mcast-data-address address (only as server argument) and this indeed has an effect, I can see on the client that the address I provide is being used. But this didn't resolve the problem.

    I have installed clonedeploy under ubuntu 14.04.



  • [quote]It says this --mcast-rdv-address 224.0.0.3 has to be added on server en client side, I tried both, only as server argument, both as server and client argument, but when the multicast starts, I see that the clients still connect to the ip-adress of the clonedepoy-server, not at 224.0.0.3.

    I also tried to add "--ttl 2" instead, the manual says it should take 244.0.0.1 as ethernet broadcast address, but this also has no effect.[/quote]

    These are most likely taking effect, there is just nothing visible that would change. The clients will not connect to 224.0.0.3, it is just used by the multicast for control. You can verify the arguments were added by checking admin->logs->multicast So my guess is that none of them fixed the issue. Unfortunately I don't have anything else to try, I too am just going off of the udpcast documentation.



  • Sorry for my late reply, after some deep investigations it turned out to be QOS policy on the backbone that set multiconnections ( broad- en multicast ) to a limit of 100Kb/sec. When this was augmented to 60MB/sec all went well.

    Thanks for the help.