From owner-freebsd-net@FreeBSD.ORG Thu Jun 5 06:39:59 2008 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 33D3F10656A8 for ; Thu, 5 Jun 2008 06:39:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 07A0C8FC2D for ; Thu, 5 Jun 2008 06:39:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 86390111C9C; Thu, 5 Jun 2008 02:39:58 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 05 Jun 2008 02:39:58 -0400 X-Sasl-enc: 1Fr2GGLXcojEOfJ6A4HJy3QpibLY8vtLm5LRqK8MUCj+ 1212647998 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id C1A5B3D05; Thu, 5 Jun 2008 02:39:57 -0400 (EDT) Message-ID: <48478A3C.6070107@FreeBSD.org> Date: Thu, 05 Jun 2008 07:39:56 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.14 (X11/20080514) MIME-Version: 1.0 To: Peter Jeremy References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <20080604081443.GJ1028@server.vk2pj.dyndns.org> In-Reply-To: <20080604081443.GJ1028@server.vk2pj.dyndns.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp 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: Thu, 05 Jun 2008 06:39:59 -0000 Peter Jeremy wrote: > Note that one downside of your carpdev patches is that (AFAIK) it is > no longer possible to identify which host sent the packet: The source > and destination MAC addresses, as well as the destination IP address > are all defined by CARP. Once you change the source IP address to be > the shared address there's nothing to identify which host sent it. > If you really, really wanted to, you could write code to prepend the original IP or MAC as an experimental IP option. Options less than <0x80 are not forwarded in IP fragments. I can understand why you'd want to do this (debugging springs to mind), though it does go against the gist of what carp is and does. Also, there is compatibility to keep in mind, and it's entirely possible that the presence of a new and unknown IP option is going to break implementations which don't parse IP option headers correctly, or trigger other unwanted behaviour ("I don't know what this IP option is therefore I will drop it").