Date: Mon, 12 Mar 2007 17:02:19 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: rik@FreeBSD.org, andre@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org, thompsa@FreeBSD.org Subject: Re: kern/109815: wrong interface identifier at pfil_hooks for vlans + if_bridge Message-ID: <20070312140219.GE44732@comp.chem.msu.su> In-Reply-To: <45F554F5.8020505@FreeBSD.org> References: <20070304160613.GN80319@codelabs.ru> <45EB4915.1090703@FreeBSD.org> <20070305145647.GT80319@codelabs.ru> <45EC3EFD.3000301@FreeBSD.org> <20070306073945.GR57456@codelabs.ru> <45ED900A.7050208@FreeBSD.org> <20070312092406.GJ58523@codelabs.ru> <45F51F2B.5020906@FreeBSD.org> <20070312112056.GC44732@comp.chem.msu.su> <45F554F5.8020505@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 12, 2007 at 01:26:13PM +0000, Bruce M. Simpson wrote: > Yar Tikhiy wrote: > >Guys, excuse me, but I still fail to see how the case of VLANs' > >sharing a single MAC differs from the case of several physical > >interfaces with the same MAC from the POV of a bridge. A bridge > >can have no own MAC addresses at all, it plays with foreign MAC > >addresses only. Therefore I can't see why our bridge code needs > >to know local MAC addresses, let alone why it fails when they're > >the same. Could you give me a hint? Thanks! > > > > A few points: > > 1. A bridge *does* have a MAC address; it is automatically assigned one > to participate in IEEE 802.1d Spanning Tree. Well, I'd say it *can* have a MAC address if it wants to participate in STP. > 2. In the case where 802.3ad trunking is implemented, the same Ethernet > address may be used by multiple physical interfaces. > > 3. As Eygene explained well: there are a number of consumers of > Ethernet frames in the stack. As if_bridge may potentially be passed > mbuf chains containing packets for these consumers first, it must > examine the destination address to determine if it should claim the > packet or not. > > Finally, because of the above points, the Ethernet destination address > cannot be regarded as a unique key in the bridge code, or indeed the > general Ethernet path, for where packets should be relayed in the stack > as a whole. But why are we relying solely on the Ethernet destination address? Each frame was received via a particular interface, which is recorded in mbuf's recvif. As the frame moves between levels of abstraction, such as a physical interface, vlan, bridge, recvif can change, but at each level the pointer to an entity in the previous level should be enough, shouldn't it? E.g., if several vlan interfaces are bridged, if_bridge shouldn't need to know which physical interfaces are used by the vlans. OTOH, it can know which particular vlan the frame came through, although vlan MACs can be the same. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070312140219.GE44732>