[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

962.0. "What happens if a station never sends any data?" by JEDI::CAUDILL (Kelly - NaC Tech Support - 264-3320) Wed May 19 1993 15:46

    I just ran into this problem again and now I wonder why I forgot :-)
    
    In the original "Bricks" demo at DECworld '90, we experience a
    "feature" where, when we used UDP as the transport, the bridges would
    eventually "forget" where the destination was and start "flooding".
    
    This would happen because Bricks is pretty dumb.  It never sends
    anything back.  When you use TCP, the transport protocol causes some
    packets to be sent from the receiving station, but if you use UDP, and
    the traffic is all in one direction, the bridges will eventually decide
    that they cannot be sure where the destination is and therefore will
    send all the data to all the LANs.  
    
    At that time, I worked around the problem by having a few of the
    DECstations ping the others (all over FDDI) and therefore the bridges
    would not time-out the entries.
    
    Eventually I installed DECnet and had it use the FDDI adapters and
    so DECnet's hello messages solved the problem for me.
    
    Is that the end of the story?  Is it a fact of life that, if you never
    send any data, the bridges won't know where you are and therefore will
    have to "flood" traffic to you?
    
    I thought I had heard that some real world application had run into
    this sort of problem and something was done about it.  But I forget.
T.RTitleUserPersonal
Name
DateLines
962.1VCSESU::WADEBill Wade, VAXc Systems & Support EngWed May 19 1993 17:1322
    
    If the bridges are SNMP manageable and the agent implements
    RFC1286 you can set the MIB object dot1dTpAgingTime to a number up to
    ~15 minutes (945 seconds).  I don't know what the 15 minute limitation is 
    and this may or may not solve your problem.  The default is 60 seconds.
    
     dot1dTpAgingTime OBJECT-TYPE
           SYNTAX   INTEGER
           ACCESS   read-write
           STATUS   mandatory
           DESCRIPTION
                   "The timeout period in seconds for aging out
                   dynamically learned forwarding information."
           REFERENCE
                   "P802.1d/D9, July 14, 1989: Section 6.7.1.1.3"
           ::= { dot1dTp 2 }
        
    DECelms and the POLYCENTER Extended LAN Manager have the same
    functionality using the "normal aging time" parameter.
    
    Bill