On Apr 1, 2008, at 3:26 PM, 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. 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.
More specifically between MAC clients sharing the same underlying NIC. The VNIC is only one type of MAC client, other MAC clients include dls/ dld, xnbo, aggr, vsw, etc. We do this today in Crossbow by having a per mac_impl_t L2 classification table which contains the MAC addresses and handles of MAC clients. If there are multiple MAC clients, we do a classification on the outbound path from mac_tx(). If there's a match, the destination is either another MAC client or a broadcast/multicast address, and we process the packet accordingly (i.e. pass to a MAC client's receive routine or broadcast/multicast the packet respectively). If the destination is unknown, the packet is passed down to the underlying NIC for transmission. In the case of bridging, something to consider would be to add the MAC addresses known to the bridge to the L2 classification tables of the NICs that are attached to a bridge. The bridging code would register its own callback/argument which would be invoked on a match. This way you wouldn't have to even modify the common data-path. We're also changing the receive side as part of Crossbow, the new code will allow clients to register receive callbacks that will only receive packets for the unicast and multicast addresses associated with a MAC client, and the promiscuous callbacks will be registered separately. In the case of the receive path, the MAC module will go through classification using the per MAC impl L2 classification table I mentioned earlier, and this could allow the bridging code to be invoked without modification to the receive path. Nicolas. > > > 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] -- Nicolas Droux - Solaris Networking - Sun Microsystems, Inc. [EMAIL PROTECTED] - http://blogs.sun.com/droux _______________________________________________ networking-discuss mailing list [email protected]
