From owner-freebsd-pf@FreeBSD.ORG Thu Jun 2 07:11:15 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B58C416A41C for ; Thu, 2 Jun 2005 07:11:15 +0000 (GMT) (envelope-from bconstant@be.tiauto.com) Received: from smtp.eu.tiauto.com (smtp.eu.tiauto.com [195.127.176.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A9EF43D54 for ; Thu, 2 Jun 2005 07:11:14 +0000 (GMT) (envelope-from bconstant@be.tiauto.com) Received: by euex01.resource.tiauto.com with Internet Mail Service (5.5.2657.72) id ; Thu, 2 Jun 2005 09:11:09 +0200 Message-ID: From: "Constant, Benjamin" To: 'Daniel Hartmeier' Date: Thu, 2 Jun 2005 09:11:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: freebsd-pf@freebsd.org Subject: RE: ALTQ on carp + pfsync? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2005 07:11:15 -0000 You are right and this is logical, pfsync is not impacted at all as it is using internal interface. It is also true that tcpdump is not showing too much traffic for CARP. I will assign this type of traffic to the queue with the highest priority. I still have some interrogation regarding CARP. Do you know why I see so much message like this one in kernel log? I've another big problem: I'm currently using two different hardware on the router boxes. The master router is a dual P4 Xeon (HTT enabled) using 2 em interface (scsi raid amr). The backup router is a single P4 (HTT enabled) using 2 em interface (sata raid asr). They are both using FreeBSD5.4 stable with same kernel configuration : backup router: 5.4-STABLE FreeBSD 5.4-STABLE #1: Tue May 31 08:53:13 BST 2005 master router: 5.4-STABLE FreeBSD 5.4-STABLE #10: Wed Jun 1 11:44:51 BST 2005 When the router crashs, it do not always panic, I just lost access to it (kbd, network,...). Here are some result of other tests I made yesterday: SMP on + CARP on = crash SMP off + CARP on = ok SMP on + CARP off = ok I've a spare box on which I'm able to reproduce the problem so I don't think it is hardware related. I'll be happy to help debugging the problem, just let me know how to... Regards, Benjamin Constant TI Automotive > -----Original Message----- > From: Daniel Hartmeier [mailto:daniel@benzedrine.cx] > Sent: mercredi 1 juin 2005 11:20 > To: Constant, Benjamin > Cc: freebsd-pf@freebsd.org > Subject: Re: ALTQ on carp + pfsync? > > On Wed, Jun 01, 2005 at 10:44:49AM +0200, Constant, Benjamin wrote: > > > - Pfsync is using internal interface (don't have 3 nic in > the box) to > > exchange data. > > - ATLQ is enabled on external interface (em1). > > - CARP is in use on both interface (in failover mode). > > > > I'm currently using CBQ scheduler for the traffic shaping > and as I've > > no specific rule for carp and pfsync protocols, I think > this traffic > > is falling in the default (mandatory) cbq child queue > (which of course > > doesn't have the biggest priority). > > If you have ALTQ enabled only on the external interface, and > pfsync uses only the internal interface, the pfsync traffic > is not queued at all (i.e. not using up any bandwidth in any > queue on the external interface), and the problem just > doesn't exist. Or what did I misunderstand? > > CARP doesn't itself generate significant traffic, you don't > need to worry about that (unless the external interface is so > saturated that CARP traffic can't get through at all, causing > failovers). You could simply give CARP traffic the highest > priority (using a top-level priority queue, possibly) in that case. > > Daniel > The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This communication is from TI Automotive.