[Bug 259528] [carp] Backup node becomes second active master when master have some negative demotion values
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259528] [carp] Backup node becomes second active master when master have some negative demotion values"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259528] [carp] Backup node becomes second active master when master have some negative demotion values"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 29 Oct 2021 12:58:37 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259528 Bug ID: 259528 Summary: [carp] Backup node becomes second active master when master have some negative demotion values Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: marius.halden@modirum.com Created attachment 229121 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229121&action=edit reproduction.sh Given nodes 1 and 2, where node 1 has an advskew of 0 and node 2 has an advskew of 100, making them master and backup respectively. If net.inet.carp.demotion is set to a negative value on node 1, node 2 might become master while node 1 still retains it master status. Wether or not node 2 becomes master seems to depend on the nodes advskew and what the demotion sysctl was set to on node 1. The reason for node 2 becoming master seems to be that the calculated advskew taking demotion into account is truncated to a single unsigned byte when copied into the carp header for sending[0], and node 1 stays master since it takes uses the whole non-truncated calculated advskew when deciding wether to stay master[1]. To reproduce, make sure carp support is enabled (kernel module loaded or built in), then run attached reproduction case. Expected output from reproduction script when setting a negative demotion on the master: ># sh carp-test.sh >Staring jail carp1. >Staring jail carp2. > >Waiting for things to settle... > >carp1 status: MASTER >carp2 status: BACKUP > >decreasing carp demotion in carp1 jail >net.inet.carp.demotion: 0 -> -1 > >Waiting for things to settle... > >carp1 status: MASTER >carp2 status: BACKUP > >increasing carp demotion in carp1 jail >net.inet.carp.demotion: -1 -> 0 > >Waiting for things to settle... > >carp1 status: MASTER >carp2 status: BACKUP > >Cleaning up. Output actually seen when running the script: ># sh carp-test.sh >Staring jail carp1. >Staring jail carp2. > >Waiting for things to settle... > >carp1 status: MASTER >carp2 status: BACKUP > >decreasing carp demotion in carp1 jail >net.inet.carp.demotion: 0 -> -1 > >Waiting for things to settle... > >carp1 status: MASTER >carp2 status: MASTER > >increasing carp demotion in carp1 jail >net.inet.carp.demotion: -1 -> 0 > >Waiting for things to settle... > >carp1 status: MASTER >carp2 status: BACKUP > >Cleaning up. As shown, both carp nodes become master at the same time. [0] https://cgit.freebsd.org/src/tree/sys/netinet/ip_carp.c?id=130aebbab0d38da85f7d32b6d4227f95a2cd9ec7#n931 [1] https://cgit.freebsd.org/src/tree/sys/netinet/ip_carp.c?id=130aebbab0d38da85f7d32b6d4227f95a2cd9ec7#n736 -- You are receiving this mail because: You are the assignee for the bug.