[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

967.0. "Ethernet framing errors on 620" by BUSSTP::JHANNAH () Tue May 25 1993 12:26

Hi,
   I was wondering if anyone could help me with the following problem. 

I have two DECbridge 620's set up in a dual ring configuration, serving three 
ethernet segments. One bridge is the live bridge, the other bridge is the 
backup bridge, the three ethernet ports on the live bridge are in Forwarding 
mode, the three ports on the backup bridge are in Backup mode, as you would 
expect. 

Some time ago, I switched over what was then the live bridge to be the backup 
bridge, and the backup bridge to be the live bridge, so I know they are both 
capable of forwarding onto the three segments okay, that's a bit of background
information for later.  

On Saturday, a problem developed whereby both the live bridge and the backup
bridge were forwarding onto one of the segments at the same time. This was only
happening on one of the three segments, the other two were fine. I know this
was happening because the FWD light was on on both bridges, and the live bridge
, which is also the root bridge, was clocking up Bad Hello Limit Exceeded
messages. I had a PC set to monitor the segment and could see the other Hello's
coming from the backup bridge. 

I reckoned there was probably a problem with the backup bridge, so I removed 
it from the dual ring completely, thinking I could just run with one bridge 
until I could get the faulty one fixed/replaced. Anyway, what happened was that
when I removed the backup bridge from the dual ring, the segment in question 
filled up with Framing and CRC errors. The PC monitor I had set up showed this,
and the line counter on the remaining bridge also showed it. Almost every 
system on the segment was transmitting bad frames.

The only way I could stop the errors on the segment was to connect in a new, 
working DECbridge back into the dual ring again. This meant I was back in the
situation of having a live bridge and a backup bridge again.

I can live with the fact that one of my bridges failed, that's okay, it's the
reason I had a live and a backup. What I can't understand is why the segment in
question would have so many errors when I only had one bridge connected. The
other two segments served by these bridges were okay, and why would the problem
disappear when I connected another bridge back in again.

Would anyone like to comment?

Jim.
  
T.RTitleUserPersonal
Name
DateLines
967.1KONING::KONINGPaul Koning, A-13683Tue May 25 1993 15:548
If the Ethernet transmitter goes bad, you'd get all those bad frames.  If
among those are bad hellos, the other bridge on that LAN would end up going
into forwarding because it doesn't see any good hellos from a higher priority
bridge.  Since the three Ethernet ports each have their own Ethernet 
chips, it certainly makes sense for one port to misbehave while the others
work fine.

	paul
967.2Which bridge to blame?BUSSTP::JHANNAHWed May 26 1993 08:5813
    My thinking was, since my "backup" bridge is forwarding when it should
    be in backup mode, then there's probably something wrong with it, so I
    swapped it for a good one. I suppose it could have been the "live"
    bridge which was at fault. If it's ethernet port was faulty then that
    could explain why the backup bridge kicked in, it would also explain
    why I had framing errors when I only had one bridge connected, the
    "live" one.  I still have the "live" bridge connected in and serving
    the segments just now. If it was the problem, and could still be since
    it's there just now, and it was the cause of the framing errors, why
    would they disappear when I reconnected in a backup bridge?
    
    Jim.
     
967.3Backup Configs not Always 100% Wonderful ROCKS::CAMPTue Jun 01 1993 08:1024
    Interesting problem and it may be that as Paul said if the "main"
    bridge was sending bad packets then the bridge hello messages are
    likely to have errors so the backup bridge can't see theses hellos,
    so its starts to forward. Now the main bridge starts to see these
    hello messages, which it believes are incorrect (assumes the "main"
    bridge can receive OK), and the bad hello counter will clock up 
    and I assume that port will then stop transmitting, attempt a
    reinitialize on that port, and come back on line listening, see the
    hello's from the backup bridge, and reinit etc.... 
    
    So it's likely that the main bridge never gets back on line, hence you
    don't see the bad packets. The GOTCHA here is that the Forward light
    should not come on on the main bridge.
    
    This is the  Catch 22 with backup bridge configurations is that if either 
    the main or backup bridge dosen't fail "nicely", eg PSU blows up, internal 
    logic gets a fatal error etc, but fails marginally then it can really 
    screw up the network, and more so if the bridge is or is  near the route 
    bridge.  If the failed bridge can't detect that its gone wrong its
    bad news. Not that common I'm pleased to say but it can happen.
    (Some Ethernet products on the market can't perform a self test on to the 
    network in any event, ie they can transmit onto the cable and receive
    from it, but can't truly receive their own transmitted message.) 
    
967.4Works, but need to test more.BUSSTP::JHANNAHTue Jun 01 1993 12:1810
    Everything has been running okay for the last week and a half, I'm
    pleased to say. What I'm going to do is, now that I've changed the old
    "backup" bridge for a new one, test the failover to make sure that it
    works okay, and also disconnect the "backup" bridge to make sure that I
    can run with only the "live" bridge connected into the fibre ring.
    
    I'll post the results when complete.
    
    Jim.