Date: Thu, 05 Jun 2008 07:39:56 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Max Laier <max@love2party.net>, freebsd-net@freebsd.org Subject: Re: Understanding the interplay of ipfw, vlan, and carp Message-ID: <48478A3C.6070107@FreeBSD.org> In-Reply-To: <20080604081443.GJ1028@server.vk2pj.dyndns.org> References: <200803041351.46053.fjwcash@gmail.com> <36735.192.168.4.151.1204669226.squirrel@router> <20080604081443.GJ1028@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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").
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48478A3C.6070107>