Conference 7.286::fddi

When beaconing is going on, the ring is not operational, and it carries no
traffic.  Therefore there's nothing to forward (to/from FDDI, that is).
Forwarding between Ethernet ports should continue under those circumstances,
of course.

As for item 2, multicast packets have to be "flooded", i.e., forwarded on all
the active ports, not just on one.  That takes more processing than forwarding
to a single port, so it's reasonable for this to be done at somewhat lower
performance than the individual port case.  It's not right for a bridge to
reset under overload, though; it should just discard what it can't handle
and keep going.  That's a problem that should be reported with as much
supporting info as you can manage.

Incidentally, is item 2 a practical problem or a contrived one?  I'll agree 
there is a bug, but does this scenario occur in practice?  (If so, how?
That sort of traffic is NOT normal with DECnet...)

	paul

    Regarding Scenario #1:
    When the FDDI port joins the ring and starts operating normally, the
    bridge goes into pre-forwarding state on that port for 30 seconds.
    During this time it is monitoring the port and storing addresses, but
    not forwarding any of the traffic. At the end of the 30 second
    interval, it goes into forwarding mode. That's normal. 
    
    What caused it to start beaconing in the first place? Were you just
    adding the bridge to the ring?
    
    Regarding Scenario #2:
    
    The 600 series bridge can forward about 22,000 packets per second. That
    number is the sum of the activity on all four ports, and is not
    affected by packet size. Packets that are forwarded to or from the FDDI
    side must also be translated. The translation rate is packet size
    dependent, and for 73 byte packets it's around 18,000 packets
    translated per second. At 3% load, that should be somewhere around 5000
    packets per second, so the bridge should be able to handle that. But if
    there is a great deal of activity on the 3 Ethernet ports the sum could
    exceed the 22,000 limit and some packets would get dropped.
    
    When you say it "stops forwarding and resets itself", does the bridge
    actually crash and reset? If so, you should see the Unsolicited Resets
    counter increment. The bridge shouldn't crash even if the network traffic
    exceeds its ability to forward packets.
    
    
    Dave
     

    Thank you both for replying so quickly...
    
    Regarding Scenario #1:
    In this case the bridge is already on the FDDI ring and is in a
    forwarding state on all ports.  The addition of a Cisco router some how
    causes the claim process to fail (Cisco is looking into this problem),
    causing the bridge to enter the beaconing state.  I understand now that our
    bridge will stop forwarding during the beaconing process, but I do not
    understand why it apparently enters the pre-forwarding state?  If this
    is true, then any time anything causes the bridge to beacon will cause
    all timing sensitive connections (like LAT) thru the bridge's FDDI port 
    to be dropped. Is this truly the way we designed the bridge?
    
    Regarding Scenario #2:
    I will do some additional tests and get bridge counters before and
    after the problem.  To answer your immediate questions...  Dave, 2 of
    the 3 Ethernet ports have loop backs installed and the third is
    connected to an Ethernet segment with less than 3% total average 
    utilization so we should be a long ways from exceeding the 22,000
    limit.  When I say it stops forwarding I am going by what I see on the
    lights on the bridge. All forwarding lights on all ports go out, all
    carrier lights except the one on the active Ethernet go out, and if we
    leave the tekelec broadcasting packets for more than about 20 seconds
    then red lights come on on the AP, FI, and QM port modules.  I will
    send more information as I have it.  
    
    Again thanks for all your help!
    
    Laurie Richards 

    re: .3
    
    >I understand now that our
    >bridge will stop forwarding during the beaconing process, but I do not
    >understand why it apparently enters the pre-forwarding state?  
    
    The pre-forwarding state is required by Digital's bridge architecture
    spec. (It has nothing to do with FDDI; the Ethernet bridges behave the
    same way.) Without this state, extended LANs would be significantly more
    unstable during bridge transitions. The "Bridges & Extended LANs
    Reference Guide" (EK-DEBAM-HR) has a good discussion on this topic.
     
    >If this
    >is true, then any time anything causes the bridge to beacon will cause
    >all timing sensitive connections (like LAT) thru the bridge's FDDI port 
    >to be dropped. 
    
    Beaconing is not a normal condition. It is an indication of a broken
    ring.

    Wait a minute.  Pre-forwarding is necessary when there is a topology
    change.  It is NOT necessary or useful or appropriate just because
    beaconing occurs.
    
    	paul

going back to .3, 

>    The addition of a Cisco router some how
>    causes the claim process to fail (Cisco is looking into this problem),
>    causing the bridge to enter the beaconing state.

Is this Cisco dual-homed into the ring ? A colleague did some testing with Cisco
and found that a dual-homed Cisco takes 30 seconds to come into the ring, during 
which time it effectively takes out the ring (causes all frames to be junked).
This 30 seconds is plenty for our brige to time out, claim, beacon, trace and 
get well fed up with whats going on. This has been reported back to Cisco but I 
don't have any info on what they're doing about it.

Does this fit your problem?

Steve

Assuming the problem I mentioned in -.1, where the cisco can take 30s to enter
the ring during which time it 'breaks' the ring, can anyone comment on the
legality within the standards of taking this long. 

My hope :-) is that this time is far too long and breaks the standard. 

Thanks for any info,

Steve

    You mean that no one can use the ring for 30 seconds?  If so, then no
    question, that's a GROSS violation of the standard.  But make sure you
    know precisely what the problem description is before you wheel out the
    cannons...
    
    	paul

Hi There,

I have been away for a few days.  I'm glad to see that my original note created 
so much conversation...

 
>Wait a minute.  Pre-forwarding is necessary when there is a topology
>change.  It is NOT necessary or useful or appropriate just because
>beaconing occurs.


Paul, I'm glad to see that you feel that beaconing should not cause our bridges
to enter the pre-forwarding state.  From my testing it appears that all bridges
on the FDDI ring enter the pre-forwarding state regardless if they initiated the
beaconing or not.  However, this could be the result of a stuck beacon and a
trace, but I do not see the trace initiated or trace received counters go up 
on any of the bridges.  How long of a time will a station beacon before it
considers it a stuck beacon condition and therefore initiate a trace?  In the
case of a stuck beacon and trace should the bridge go into a pre-forwarding
state?  Should the trace function only affect the station that initiated the
trace and its upstream neighbor or should it impact all stations on the ring? 
Can anyone make any recommendations on how to isolate this possible problem 
further?     
   
>Is this Cisco dual-homed into the ring?

Yes, the Cisco is dual-homed.  On our production ring it would be dual-homed to
two different concentrators, but since I only had one spare concentrator for my
tests it is dual-homed to the same concentrator.  The problem with the Cisco
routers is as follows...  When we power-up a Cisco router with FCIT microcode
10.1 and software version 9.1.3 onto a live FDDI ring it causes all bridges on
the ring to stop forwarding for approximately 33 seconds.  I'm assuming this
amount of time is a result of the bridge entering the pre-forwarding state. 
Also all DEC FDDI controllers on our ring (DEC FDDIcontroller 400s and 700s)
log a fatal error (device timeout or transmit timeout).  Collecting MAC frames
on my test ring which has 2 Ciscos and 2 DECbridge 610s attached to a single
DECconcentrator 500 we see thousands of beacon frames from a bridge and a few
claim frames.  We sent the Tekelec data to Cisco and they are researching the
problem.  They have not been able to reproduce it with a SynOptics, Cabletron,
or AT&T concentrator which is why I'm asking all the questions about our
bridges.  I was thinking that perhaps the problem with the Ciscos is causing
the claim process to fail which causes our bridges to beacon and enter 
the pre-forwarding state.
    
    Your answers, comments, suggestions, and questions are greatly appreciated!
    
    Thanks,
    
    Laurie Richards

    re: .5
    
    >Wait a minute.  Pre-forwarding is necessary when there is a topology
    >change.  It is NOT necessary or useful or appropriate just because
    >beaconing occurs.
    
    According to the bridge firmware engineers, a beaconing FDDI port is
    considered to be a broken datalink by the bridge firmware. So that port
    goes through pre-forwarding after CNS declares the station "up."

That's not good.  Beaconing is a sign that something interesting has happened
on the FDDI, but it does NOT necessarily mean there's a problem with the FDDI,
and it CERTAINLY doesn't mean that there is a problem with the FDDI port of
the bridge.

	paul

	I believe that if we are beaconing for more than 2 seconds, the	
	link becomes "unavailable" which would cause the bridge to think
	the link is broken.

	Luc

Let's make sure we're all talking about the same thing... I'm getting a bit 
confused at this point.

1. "regular" beaconing -- i.e., beaconing that lasts a fraction of a second.

   This can be caused by various things; one common cause is one of the
   allowed standard station insertion techniques.  This case of beaconing
   does NOT indicate a failure, and is NOT a legitimate reason to stop
   forwarding.

2. "stuck beaconing" -- i.e., beaconing that is not resolved within the
   stuck-beaconing timeout specified by SMT.

   This indicates a serious hardware problem in the ring (more precisely, in
   some station on the ring).  I would argue it isn't necessarily useful to
   go into pre-forwarding in this case, but it certainly is ok to do so.

   If a node causes stuck-beaconing (and thus Trace) as a result of some
   condition other than a serious hardware failure, that node has a fatal
   design error and should be nuked.  For example, while a brief beacon is
   a legitimate consequence of station insertion, stuck-beaconing or trace
   is NOT.

It's not really clear to me at this point whether the problem we've been
talking about is #1 or #2.  If #1, our bridges need to be told not to go
to pre-forwarding on plain beacons.  If #2, our bridges are blameless and
the instigator of the stuck-beaconing needs to be repaired.

	paul