From owner-freebsd-net@FreeBSD.ORG Mon Oct 25 06:19:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71C5E1065675 for ; Mon, 25 Oct 2010 06:19:12 +0000 (UTC) (envelope-from nr1c0re@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 39DF18FC08 for ; Mon, 25 Oct 2010 06:19:11 +0000 (UTC) Received: by iwn39 with SMTP id 39so3968049iwn.13 for ; Sun, 24 Oct 2010 23:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=OLHGqCRCTqGZryL+p+CDLt23iMEQMVwy/N/xU22t0Rc=; b=v8UFhqCsDPLPXWyen4KzIBuXQOMglxGxDjoP9c0/DNYrYKnwKssmke4TNkbEOD6Ryc CAbptC4E0l85jOxo+mzONKtvVSOkOSrFanTMA0BF/s7cbo0ZoH3ydSaRS1m4sQSh0E5k tlYFwwTZScccvIoBUSVBGl/GDQQsAWjJFOwXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fv+5M5VM7oJvZg0Bn+fV3OrE92I2W+eA7CRfzrHSQGqchL2OLASBCzF3QDprNl/wqR eWxgvq2JLjm7xaNYleERgIkSQlY+eGQQ4ergOvabsJUTFpymFXlIuKuCWw1K63SruEEk X0UL6i2f+8Ib/WPQGnI9lJG0fFuFawNu9g+x4= MIME-Version: 1.0 Received: by 10.231.150.7 with SMTP id w7mr5350092ibv.14.1287987551542; Sun, 24 Oct 2010 23:19:11 -0700 (PDT) Received: by 10.229.217.20 with HTTP; Sun, 24 Oct 2010 23:19:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Oct 2010 10:19:11 +0400 Message-ID: From: c0re To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: carp and arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 06:19:12 -0000 It's strange... No log messages about moving from BACKUP to MASTER. Oct 23 04:00:05 carp2 kernel: arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) Oct 23 04:00:05 carp2 kernel: arp_rtrequest: bad gateway 1.1.1.6 (!AF_LINK) Oct 23 04:00:05 carp2 kernel: arp_rtrequest: bad gateway 1.1.1.9 (!AF_LINK) Oct 23 04:00:06 carp2 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) Oct 24 00:10:18 carp2 kernel: arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK) Oct 24 00:10:18 carp2 kernel: arp_rtrequest: bad gateway 1.1.1.6 (!AF_LINK) Oct 24 00:10:18 carp2 kernel: arp_rtrequest: bad gateway 1.1.1.9 (!AF_LINK) Oct 24 00:10:18 carp2 kernel: carp0: MASTER -> BACKUP (more frequent advertisement received) 2010/10/20 c0re : > I got 2 servers with CARP enabled. One is MASTER, second - BACKUP. > CARP is for HA of running some service on that servers. > > All works fine, but today I've got interesting case: > Service was not responding for 5 minutes. Can't tell more details > because it was said by not IT guy. > > Okay, I went to check logs on master and backup servers. All was fine > except dmesg and messages: > > Master server has no recored in messages for about 1 hour. > > But on slave server I saw that: > > Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.5 > (!AF_LINK) > Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.6 > (!AF_LINK) > Oct 20 12:15:00 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.9 > (!AF_LINK) > .................. > Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.5 > (!AF_LINK) > Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.6 > (!AF_LINK) > Oct 20 12:49:58 carp-backup kernel: arp_rtrequest: bad gateway 1.1.1.9 > (!AF_LINK) > > Total about 300 records. > > Can anyone comment something about it? What was that? Backup server > was loosing connectivity with Master server? > > In sysctl.conf I've got only net.inet.carp.preempt=1.Now I tuned log > to net.inet.carp.log=2. This should log carp info messages. > > Am I right about loosing connectivity between master-backup servers or > there can be another reason? >