Rajagopal Kunhappan wrote: > 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. Forgot to point to the source browser:
http://src.opensolaris.org/source/xref/netvirt/usr/src/uts/common/io/mac/mac.c -krgopi > 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] > _______________________________________________ networking-discuss mailing list [email protected]
