I'm looking at putting bridging functionality into Nemo, and I think I
need some advice (particularly from those who are currently modifying
Nemo).
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.
When any client transmits on a link that's attached to a bridge, the
packet doesn't necessarily go out on that same link. If the
destination MAC address the sender is trying to contact is known to
the bridge and is reachable through some other link on the bridge,
then the bridge must first forward the packet to the proper link -- or
it'll never reach the desired destination.[1]
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) 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).
I'm going to attempt to do the hack at the mac.c layer to be sure that
I catch all transmits, but if anyone has a better suggestion, I'm all
ears.
1. If this isn't obvious at first glance, consider an internal bridge
connecting hme0 and hme1. You have IP plumbed on hme0, and you
send a packet to a host connected on hme1. What happens? If you
send it out on hme0, the host will never see it. You're the
bridge for these two networks, and you've just sent the packet on
the wrong link. Nobody else will pick it up and forward it.
As a bridge, you need to know that when you receive traffic on
hme0, and the receiver is located on hme1, you have to forward.
This is true regardless of whether the sender is external (some
other host connected on hme0) or internal (a client, such as IP).
--
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]
