James Carlson wrote: > 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] >
Some part of this functionality already exists in the crossbow gate. See mac_tx_send() and mac_tx_classify() in uts/common/io/mac/mac.c. This code implements the vswitch functionality routing packets among VNICs for the case where VNICs are created on top of a NIC. It does not route traffic between VNICs which are created on different NICs. You can get to crossbow gate internally at /ws/crossbow-gate. -krgopi > 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). > > _______________________________________________ networking-discuss mailing list [email protected]
