Multicast Address isn't randomized

[Rob Thomas]

When deploying a hacluster, the multicast address defaults to a fixed address of 226.94.1.1.

This means having two haclusters on the same network segment will cause no end of conflicts and other unexpected behaviour.

The recommended address range (to simplify) for private address space is 239.[192-255].[1-254].[1-254] (ref rfc2365, and specifically note the exclusion of all 1s and all 0s in the last two octets, to avoid historical switching bugs)

When a hacluster is deployed without a mulitcast address it should be randomly allocated from that pool.

This only gives 24 bits of randomness, and does have potential to cause a conflict. The mcastport may additionally be randomized to add more entropy.

[Rob Thomas (xrobau)]

Additonally, looking at the charm:
  corosync_mcastaddr:
    description: 'Multicast IP address to use for exchanging messages over the network.
      If multiple clusters are on the same bindnetaddr network, this value
      can be changed.

That should be 'must be unique per cluster' or something like that.

[James Page (james-page)]

By default, different charms use different ports on the default multicast address, so you should not get any conflicts; I've been considering switching to auto-generated addresses (which is supported by corosync based on cluster naming) but that's currently a wishlist item.

Best practice would dictate using different multicast addresses per clustered service avoiding propagation of multicast traffic to broadly; this is configurable via the charms.

[Rob Thomas (xrobau)]

I hadn't noticed the port differences, that would cover my 'why is this not causing so many problems' question.

However, that address used is still classed as RESERVED by IANA, and should be changed to a valid space, in the 239/8 range., which is the equivalent of RFC1918 addresses for multicast.