David Edmondson writes: > > On 24 Mar 2008, at 20:32, James Carlson wrote: > > On the receive side, it looks like I can just be a DLS client in > > promiscuous mode, and all should work fine. The transmit side is much > > more complex. > > A DLS client or a mac client?
DLS, because it's simpler. But you're right that this *does* look more like a mac client. For one thing, it doesn't run on top of VLANs, but rather underneath. > > Unfortunately, it doesn't seem that there's either (a) a way to layer > > entities at the mac level without renaming them (no I_PUSH equivalent > > here) or (b) a single place where all these packets appear that could > > be modified with a simple "if (link->attached_to_bridge)" test. > > > > The solutions appear to be either modifying the relevant mac clients > > (currently just vnic_dev.c and dls.c) > > Why not xnbo? Simply because I never heard of it before. ;-} As I said, the client-side approach seems distasteful. The only thing that made me consider it is that the framework itself doesn't have a central point where transmit is handled, and that makes it much harder to maintain. (The N^2 profusion of mi_tx* things is a result of that, and it'd be good to avoid stressing that part of the design.) > > so that the common transmit > > functions there make a pass through bridging first, or modifying mac.c > > with yet another mi_tx* entry for this new case. The former seems > > distasteful, but the latter just stresses an existing Nemo design > > problem (combinatorial explosion in tx functions). > > The problem seems to stem from directly using the underlying mac while > that mac is also a member of the bridge. If members of the bridge were > otherwise unavailable and clients passed packets to the bridge itself, > would this problem disappear? (The bridge would look a lot like aggr.) I thought of that, but I think it would make brand new problems appear. The links on a bridge are _not_ fungible. You can have different VLANs configured on different links, and which one you use makes a good bit of difference in MAC address usage and multicast behavior. The bridge itself isn't a link, so it'd either have undefined behavior, or we'd have to invent fake bridge ports -- both of which end up causing adminstrative artifacts. Because of that, I want to have the links that are attached to a bridge be available to the administrator under their original names. To an administrator, it behaves exactly as though there were an external bridge connecting those interfaces together. The problem really stems from wanting to do something that wasn't envisioned in the original Nemo design: layering on top of mac without a name change. :-< I'll work something out and come back with a more concrete suggestion. I was hoping that someone else (L2 filtering?) had faced the same issue before and had already planned out a solution. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
