Dnia Tue, Jun 28, 2022 at 10:03:25AM +0200, Christer Solskogen napisał(a): > On Tue, Jun 28, 2022 at 9:52 AM Łukasz Moskała <l...@lukaszmoskala.pl> wrote: > > > Run tcpdump on master, ping on backup. If you see pings in tcpdump, then > > master is responding. > > If not, backup is responding to itself. > > > > > Good catch. > The backup is responding to it self. But should it? In the FAQ I find this: > "The master host is the one that currently "holds" the shared IP; it > responds to any traffic or ARP requests directed towards that address." > So the question now is should master respond? > > -- > chs
Master can't respond to that traffic, as it never goes over wire. Just like pinging 127.0.0.1 If you have 192.0.2.10/24 on em0, and ping 192.0.2.10 from host that has this IP, this traffic newer goes over network cable either. Also this allows you to bind service to that CARP IP on both hosts. If that address would "disappear" from interface when host is in backup mode, services running on backup host couldn't bind to that IP. For example you have CARP IP 192.0.2.200/32. You can bind httpd to 192.0.2.200:443 on both hosts, and have both of them running, but only master would receive traffic. Master is the only one who advertises this IP on the network. So from perspective of any other host, only master has this address. Maybe you can get userspace CARP implementation that removes IP from interface when in backup mode and adds it again when in master mode. This is how keepalived on linux works (but it uses VRRP, not CARP). What problem are you trying to solve? -- Łukasz Moskała
