From owner-freebsd-bugs@FreeBSD.ORG Thu Sep 29 15:10:10 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECFBD106564A for ; Thu, 29 Sep 2011 15:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C8C408FC1E for ; Thu, 29 Sep 2011 15:10:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8TFA9sd094616 for ; Thu, 29 Sep 2011 15:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8TFA9m7094615; Thu, 29 Sep 2011 15:10:09 GMT (envelope-from gnats) Resent-Date: Thu, 29 Sep 2011 15:10:09 GMT Resent-Message-Id: <201109291510.p8TFA9m7094615@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Damien Fleuriot Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E2611065670 for ; Thu, 29 Sep 2011 15:05:59 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 043EF8FC1F for ; Thu, 29 Sep 2011 15:05:59 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p8TF5wBt047015 for ; Thu, 29 Sep 2011 15:05:58 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p8TF5wir047014; Thu, 29 Sep 2011 15:05:58 GMT (envelope-from nobody) Message-Id: <201109291505.p8TF5wir047014@red.freebsd.org> Date: Thu, 29 Sep 2011 15:05:58 GMT From: Damien Fleuriot To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/161123: CARP - when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 15:10:10 -0000 >Number: 161123 >Category: kern >Synopsis: CARP - when preemption is enabled carp interface assumes MASTERship immediately even with higher advbase/advskew >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 29 15:10:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Damien Fleuriot >Release: 8.2-RELEASE >Organization: Hi-Media >Environment: FreeBSD pf2.multiprojet 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Sep 29 16:11:04 CEST 2011 root@pf2.multiprojet:/usr/obj/usr/src/sys/MULTI amd64 >Description: Under normal operating circumstances, a CARP interface goes through the following states: - INIT : when it's down - BACKUP : immediately upon being brought up, the interface assumes a BACKUP role and starts its timer to know if it should claim mastership. - MASTER : if the delay has expired (advbase * 3) without the interface seeing another master, it assumes mastership. BUG: When preemption is enabled (net.inet.carp.preempt=1) , the CARP interface immediately assumes MASTERship regardless of its advbase and advskew values. This causes CARP switchovers when a firewall from a CARP cluster is rebooted, for example. In our case, this actually led to lost client connections, lost database sessions, developers' daemons crashes because of lost java/db connections... This is a known problem with OpenBSD 3.8 and lower's implementation of CARP. This has been fixed as of OpenBSD 3.9. Refer: my post on -stable http://docs.freebsd.org/cgi/getmsg.cgi?fetch=368260+0+current/freebsd-stable >How-To-Repeat: Set up 2 boxes with a shared CARP IP. Enable CARP preemption. Bring down your CARP interface on the BACKUP box. Bring it up again. Notice how your interface assumed MASTERship for a short time. Check with dmesg which confirms that your box actually preempted. >Fix: The fix lies in sys/netinet/ip_carp.c in function carp_setrun(struct carp_softc *sc, sa_family_t af). All that is needed is to get rid of the code portion which instruct the CARP interface to immediately transition from INIT to MASTER if it has preemption enabled. Patch attached. Patch attached with submission follows: --- sys/netinet/ip_carp.c 2011-09-29 15:00:07.000000000 +0200 +++ sys/netinet/ip_carp.c 2011-09-29 15:01:37.000000000 +0200 @@ -1390,22 +1390,10 @@ switch (sc->sc_state) { case INIT: - if (carp_opts[CARPCTL_PREEMPT] && !carp_suppress_preempt) { - carp_send_ad_locked(sc); - carp_send_arp(sc); -#ifdef INET6 - carp_send_na(sc); -#endif /* INET6 */ - CARP_LOG("%s: INIT -> MASTER (preempting)\n", - SC2IFP(sc)->if_xname); - carp_set_state(sc, MASTER); - carp_setroute(sc, RTM_ADD); - } else { - CARP_LOG("%s: INIT -> BACKUP\n", SC2IFP(sc)->if_xname); - carp_set_state(sc, BACKUP); - carp_setroute(sc, RTM_DELETE); - carp_setrun(sc, 0); - } + CARP_LOG("%s: INIT -> BACKUP\n", SC2IFP(sc)->if_xname); + carp_set_state(sc, BACKUP); + carp_setroute(sc, RTM_DELETE); + carp_setrun(sc, 0); break; case BACKUP: callout_stop(&sc->sc_ad_tmo); >Release-Note: >Audit-Trail: >Unformatted: