Conference 7.286::fddi

I don't know why it isn't working, but out of curiosity: why do you need to
turn the ring purger off?

	paul

    The Customer has read the white paper and has talked directly to
    engineering, he understand what is going on and belives that he does not
    need Ring Purging.  He has a fairly large ring and belives we can
    actually stressing other NON-Digital FDDI equipment. In a nutshell,
    he belives that purging will take care of itself when a station is
    holding the token and some packets come in on the receive port, the
    station will Purge this data. IS the Ring Purger enable Flag settable
    via MCC using ELMs?
    
    Later, Mike Beaulieu
    

    	Mike,
    
    	To be able to disable Ring Purger on a DECconcentrator 500,
    you need v.3.1 of firmware on it. I installed a site where we did
    it to share the ring with Fujitsu LANC adapter.
    
    	Patrick
    

Well, it's unclear whether things will take care of themselves.  That may be
true, but the size of the network isn't the issue.  The issue is the amount
of activity.  If the load is extremely high, then this statement is true.
If not (say, below 50%) then isn't as valid, less so the lower the load.

Unless the ring purger actually causes PROBLEMS (in non-conforming 
implementations of other vendors) it should be left enabled.

	paul

    Patrick, 
    
    Thanks, I have rev 3.0B of the firmware. I'll downline load the new rev
    level and check it out.  
    
    Paul,
    
    The customer was trying to implement a FDDI to FDDI bridge from AT&T
    (Starlan series) The bridge doesn't work and the AT&T folks were 
    implying that we were the cause of the problem.  I do not know how well
    AT&T conformed in it's implementation of this product. It's really a mute
    point because the AT&T/NCR Starlan series products are going into 
    maintenance mode. According to my customer, when NCR and AT&T merged
    all the key engineers on the Starlan projects left and all the futures
    that were promised in the product were cancelled (i.e. SNMP, Spanning
    Tree in the NI to FDDI bridge, etc.) That is why the customer is looking
    at Digital's FDDI products. Eventually the whole network will be
    replaced with DEC's FDDI gear. 
    
    Thanks for the info.  Mike Beaulieu
    

Ok...

It's important to get the message across -- over and over -- that the ring
purger will NOT cause any problems to a conforming node.  If something runs
into trouble, that's proof positive that it does NOT conform to the FDDI
standard.

	paul

    
    Does ring purging send 'null frames'?
    
    I just got back from a govt agency that wants to know if they can turn 
    the DECconcentrator null frame generation off.  There primary percieved
    benfit is more effective (or just easier) traffic monitoring of the 
    FDDI net - they don't want to deal with all the buffer overuns (?) that 
    the null frames create in the monitor/snooper.
    
    General comment from customer 'It's it a good product, BUT...' and the
    ensuing null frame complaint. 
    Does turning it off really work in V3.1?  Another 'rumor' they brought
    up was you could turn the flag to false, but it still sent null frames.

They are called "void frames"; there is no such thing as a "null frame".

There are two reasons why void frames are sent:

1. The node is acting as ring purger.  As you pointed out, you can turn off
   this feature.  That will stop the purger void frames IF there is no other
   node willing to act as ring purger.  If there is, that node will take over.
   You have to turn off the feature on all nodes that have it on, or someone
   will be purger.

   A purger sends a single void frame every token, whether it is sending data
   or not.

2. The node is running DECnet, or is a bridge, or for some other reason is using
   multiple source addresses.  In that case, it uses "bridge stripping", or
   "frame content independent stripping".  This feature cannot be turned off
   for the simple reason that there is no other way for such nodes to do what
   they have to do.

   A node in this case will send two void frames after each transmission of
   data (i.e., between the data and the token).  It will not send the voids
   unless it had sent data.

Incidentally, a "monitor" that can't cope with void frames is a piece of trash.
The best answer for the customer would be to return it to the factory and 
replace it by one that's designed correctly.  The standard actually requires
stations to NOT receive void frames.  Some stations do this wrong, and do
receive them.  It's one thing for stations to do that... but the purpose
of a monitor is specifically to analyze the traffic on a LAN, and not get
itself into trouble no matter what traffic it sees.  Something that pretends
to be a monitor but gets into trouble when void frames appear is not a monitor.

	paul

    Yea, they called them void frames (next time I'll take notes.....).
    
    This customer doesn't want to be forced to do something, in general.
    Being able to turn off void frames (perhaps because of a piece of trash
    monitor they bought, or because.....?) was option they wanted.  If ring 
    purging is turned on, how often is a void frame sent?

    on a different 'note' - any plans to be able to telnet to the 
    DECconcentrator 500 for setup, management, etc. - to get to the
    menu/console subsystem?

Re .9: as I said, ring purger sends a void every token.

Re .10: I doubt it.  The general industry direction is away from such things,
toward the use of SNMP.

	paul

    	How is the Ring Purger "elected" amongst candidates?
    
    Phil 

    Re:.12- (mine)
    
    	I should have made my question more specific. I know that the
    highest address among candidate purgers becomes ring purger. What I
    would like to know more about is the format of the Purger Hellos and
    other messages used- are they all SMT ESF Multicasts?
    
    	Are there any documents available on this?
    
    Phil

    >highest address among candidate purgers becomes ring purger. What I
    >would like to know more about is the format of the Purger Hellos and
    >other messages used- are they all SMT ESF Multicasts?
    
    Both Purger Hellos and Candidate Hellos use SMT ESF multicasts.
    
    >	Are there any documents available on this?
    
    The DNA FDDI Data Link Functional Spec. V1.0.0