baker@Vitam6.UUCP (Fred Baker) (06/09/89)
This is a reply to Steve Elias' question concerning Bridges and Address Filtering. Vitalink uses several different approaches to Address Filtering based on the needs of the algorithm involved, some of which are software based and some of which are hardware based. The simplest and most effective software algorithms that we have found capitalize on the fact that most vendors implement some sort of serial number in the vendor-specific field of the Ethernet Address. A few examples: U/B Address: 00-DD-00-xx-xx-00 where xx-xx is a number DECNET IV: AA-00-04-00-xx-yz where y is AREA and zxx is NODE (approximately) 3COM Address: 09-00-02-xx-xx-xx where xx-xx-xx is a big-endian integer Net net is that if aa-bb-cc-dd-ee-ff is an Ethernet Address, -ee- is the most commonly "different" octet, and -ff follows close behind. Hashes that include them generally work pretty well. Lookup tables that have no hash to jump start them don't work for beans, and even in hashed lookup tables, this word should be compared against first. One of our algorithms, used to quickly discard local traffic, can discard at LAN speed even on a 10 MHz 68010, so software approaches should not be discounted out of hand. Hardware approaches generally fall into two categories: Associative Content Addressable RAMs (CAMs) such as AMD's, and lookup engines. Vitalink uses a lookup engine in our TransRING (Transparent Token Ring) Bridge, and that works pretty well. The problem with the TI Chipset is that it can only process a very limited number of frames per second, so any help one can give it in knowing what it can safely ignore is helpful. Ethernet controllers are generally more capable, so discarding before or after the controller is more a question of what MIPS rating one is willing to pay for, and how that trades off against the cost of the lookup engine.