|  | Yes, it floods those packets with an unknown DA. But only
that first packet; when the station in question ACKs, its
address is then added to the forwarding table.
I don't know the answer to question #2, but it doesn't seem
like a good idea, since that first packet seen for a previously
unknown DA will then be dropped. And you won't be able to
communicate with the poor station that has that address.
Perhaps they wish to explore some type of filtering, if they
are concerned about extraneous traffic traversing the switch
unnecessarily.
-Mike
 | 
|  |     
    I just saw this note, and yes, as Mike said, the DECswitch will
    flood the DA packets until they are acknowledged.
    The question I have is, does the customer wish to to disable this
    behavior because they perceive that they have no control over the
    generation of packets with "bogus" destination addresses?
    
    If the customers network consists of a small number of end nodes,
    they could put the DECswitch ports in manual mode, add the MAC
    addresses of the end nodes that are connected to the specific 
    DECswitch ports. Thus they give up the learning feature of the
    DECswitches, in favor of having a dedicated "hard configured"
    LAN that can't evolve on its own, and no bogus or unconfigured addresses 
    would ever flood to adjacent DECswitch ports. Any future additions of 
    nodes however, would then have to be manually added/managed (a real pain).
    Filtering would minimize flooding but wouldn't eliminate it all
    together. There are NIC cards (real cheap ones), that allegedly will
    put out extraneous packets with bogus destination addresses.
    If this is what the customer is dealing with, then basically they've 
    gotten what they paid for with those cheap NIC cards.
    
    Bob
 | 
|  | 
The customer wishes to setup a test procedure to verify that the DECswitch 
900EF isolates the various LANs, and one of the tests is to try to loop DECnet 
through a bogus address. Using IRIS, I see what appears to be a unicast 
packet from one DECnet MAC address to another DECnet MAC address. However, 
based on the information that you have provided, the behaviour I am seeing is 
the norm and I will just need to document a procedure on how to look into the 
packets to determine that they are Connect Initiate to the bogus address, and 
the remaining 3 packets are restransmitted CI. I liked doing this procedure 
alot better before they added the bogus address!
Thanks for the responses.
Dennis Faust
 |