On 2014-06-30 11:11, Peus, Christoph wrote: > Henning, thanks for your quick reply. > >>> Which disadvantages could this mode of operation have compared to the classic mode with IPs assigned? >> the backup node might not be able to reach the network on the carp if > > Hmm... what does this mean to me..? To make it more precise - my setup looks like this: > > Physical NIC -> trunk interface -> vlan interface = physical interface of the carpdev -> carpdev -> virtual IP (no IP on the vlan interface) > > I tested this setup and experienced unpredictable transitions from and to master/backup state on different carp groups configured that way and also unstable connections with >50% packet loss. I strictly followed the carp/pfsync configuration guidance in respect of advskew, sysctl.conf options and so on. So I wondered if this may have been caused by the "no IP" configuration. > > Is multicast only used when there are no IPs configured for the physical interfaces of the carpdevs?
Not exactly. >From ifconfig(8): > CARPPEER _peer_address_ > Send the carp advertisements to a specified point-to-point peer > or multicast group instead of sending the messages to the default > carp multicast group. The _peer_address_ is the IP address of the > other host taking part in the carp cluster. With this option, > carp(4) traffic can be protected using ipsec(4) and it may be > desired in networks that do not allow or have problems with IPv4 > multicast traffic. So it always uses multicast unless you specify "carppeer". Reading ip_carp.c, I don't see any reason carppeer can't be a completely arbitrary address, including an address bound to a loopback adapter. Using carppeer unwisely can defeat the purpose of the multicast transmission, i.e. detecting layer 2 failures, if your layer 3 ensures the carppeer address remains reachable (e.g. both hosts are running OSPF and can re-route over another interface). Recap: - Interface state (carrier/no-carrier) detects local layer 1 failures only - Multicast heartbeat detects layer 2 failures, and remote layer 1 failures; this is desirable in VLAN scenarios, I believe, where carrier/no-carrier does not signify anything useful. - Using carpdev specifies the interface on which to bind the CARP address and on which to send multicast packets. If it is not specified, it is inferred from the subnet. - Using carppeer disables multicast - the nominal use case is to protect CARP traffic with IPSec. Other uses are possible, but questionable because they may break lower-level assumptions. (or so I believe, anyway. I'm sure Henning will correct me if not.) FWIW, I don't use carppeer even though it could save me substantial IP address space, for a couple of reasons: 1) I want the canary-in-the-coal-mine to inform me of any layer 2 weirdness 2) I prefer predictability and "normal" use cases 3) if I ever stop using CARP and switch to HSRP or VRRP, I'll need those addresses again -Adam
