From owner-freebsd-net@FreeBSD.ORG Tue Mar 27 14:29:18 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6374616A402 for ; Tue, 27 Mar 2007 14:29:18 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from pobox.codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 1324513C48C for ; Tue, 27 Mar 2007 14:29:17 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=cvWCXdO7YHDnuMOOybXk6H5fVF886lX0XdwMcgjd0TEL6WnrqQuiSjppseE+//KeCNHlI/Q1qx/fBganUambZB9q8KeZ4ZCXt5CgE29S/VPNEb3uJxWhSyOMmfRP22CJ5lR1kgKHNdguwSTvyPRPoBT/Tq5kxSK52bkkGeCsdYM=; Received: from codelabs.ru (pobox.codelabs.ru [144.206.177.45]) by pobox.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1HWCff-000DqX-T5; Tue, 27 Mar 2007 18:29:12 +0400 Date: Tue, 27 Mar 2007 18:29:07 +0400 From: Eygene Ryabinkin To: Julian Elischer Message-ID: <20070327142907.GH14837@codelabs.ru> References: <45F554F5.8020505@FreeBSD.org> <20070312140219.GE44732@comp.chem.msu.su> <20070312143811.GA58523@codelabs.ru> <20070312165145.GF44732@comp.chem.msu.su> <45F5BD36.1070205@inse.ru> <20070312214926.GK44732@comp.chem.msu.su> <20070313055029.GK58523@codelabs.ru> <20070317192254.GB82045@codelabs.ru> <45FCC115.1020408@elischer.org> <20070318051709.GE82045@codelabs.ru> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="I3tAPq1Rm2pUxvsp" Content-Disposition: inline In-Reply-To: <20070318051709.GE82045@codelabs.ru> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-3.4 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 Cc: freebsd-net@freebsd.org, rik@inse.ru Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge 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: Tue, 27 Mar 2007 14:29:18 -0000 --I3tAPq1Rm2pUxvsp Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Good day. Sun, Mar 18, 2007 at 08:17:09AM +0300, Eygene Ryabinkin wrote: > You're right, thanks for spotting the error. The corrected patch > is attached. After some iterations with rik@ we came to a next version of an if_bridge.4 patch. Comments are welcome. -- Eygene --I3tAPq1Rm2pUxvsp Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="if_bridge.4.diff" --- if_bridge.4.orig Sun Mar 4 15:37:22 2007 +++ if_bridge.4 Tue Mar 27 18:25:52 2007 @@ -82,6 +82,13 @@ .Nm interface randomly chooses a link (MAC) address in the range reserved for locally administered addresses when it is created. +This address is guaranteed to be unique +.Em only +across all +.Nm if_bridge +interfaces on the local machine. +Thus you can theoretically have two +bridges on the different machines with the same link addresses. The address can be changed by assigning the desired link address using .Xr ifconfig 8 . .Pp @@ -219,9 +226,89 @@ so all packets are passed to the filter for processing. .Pp -Note that packets to and from the bridging host will be seen by the -filter on the interface with the appropriate address configured as well -as on the interface on which the packet arrives or departs. +The packets originating from the bridging host will be seen by +the filter on the interface that is looked up in the routing +table. +.Pp +The packets destined to the bridging host will be seen by the filter +on the interface with the MAC address equal to the packet's destination +MAC. There are situations when some of the bridge members are sharing +the same MAC address (for example the +.Xr if_vlan 4 +interfaces: they are currenly sharing the +MAC address of the parent physical interface). +It is not possible to distinguish between these interfaces using +their MAC address, excluding the case when the packet's destination +MAC address is equal to the MAC address of the interface on which +the packet was entered to the system. +In this case the filter will see the incoming packet on this +interface. +In all other cases the interface seen by the packet filter is chosen +from the list of bridge members with the same MAC address and the +result strongly depends on the member addition sequence and the +actual implementation of +.Nm if_bridge . +It is not recommended to rely on the order chosen by the current +.Nm if_bridge +implementation: it can be changed in the future. +.Pp +The previous paragraph is best illustrated with the following +pictures. Let +.Bl -bullet +.It +the MAC address of the incoming packet's destination is +.Nm nn:nn:nn:nn:nn:nn , +.It +the interface on which packet entered the system is +.Nm ifX , +.It +.Nm ifX +MAC address is +.Nm xx:xx:xx:xx:xx:xx , +.It +there are possibly other bridge members with the same MAC address +.Nm xx:xx:xx:xx:xx:xx , +.It +the bridge has more than one interface that are sharing the +same MAC address +.Nm yy:yy:yy:yy:yy:yy ; +we will call them +.Nm vlanY1 , +.Nm vlanY2 , +etc. +.El +.Pp +Then if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm xx:xx:xx:xx:xx:xx +then the filter will see the packet on the interface +.Nm ifX +no matter if there are any other bridge members carrying the same +MAC address. +But if the MAC address +.Nm nn:nn:nn:nn:nn:nn +is equal to the +.Nm yy:yy:yy:yy:yy:yy +then the interface that will be seen by the filter is one of the +.Nm vlanYn . +It is not possible to predict the name of the actual interface +without the knowledge of the system state and the +.Nm if_bridge +implementation details. +.Pp +This problem arises for any bridge members that are sharing the same +MAC address, not only to the +.Xr if_vlan 4 +ones: they we taken just as the example of such situation. +So if one wants the filter the locally destined packets based on +their interface name, one should be aware of this implication. +The described situation will appear at least on the filtering bridges +that are doing IP-forwarding; in some of such cases it is better +to assign the IP address only to the +.Nm if_bridge +interface and not to the bridge members. +But your mileage may vary. .Sh EXAMPLES The following when placed in the file .Pa /etc/rc.conf --I3tAPq1Rm2pUxvsp--