[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

832.0. "NSC6614/NatSemi chipset Translation Bridging Problem" by VIVIAN::MILTON (CAUTION - Unresolved Postulates) Fri Jan 15 1993 06:32

Some interesting information concerning NSC6614 Translation bridges using 
National Semiconductor Chipset (as described by Nat Semi Application Note 740)

One of our customers in London are performing some testing on a ring involving
some 7 x NSC6614 (configured 4 ethernets and one FDDI as translation bridges). 
The ring also includes 2 x NSC6800 DXs (configured with wide area ports - FDDI
encapsulation) so that these can "talk" to the native ring, one of the 6614s is 
set up as a encap/translation gatway. They have been using a Network General 
FDDI Sniffer and several ethernet sniffers to both generate and observe traffic.

They have found that for ring latencey of greater than 5 micro-seconds (or lower
with small packet sizes) the 6614s produce duplicate packets if the original was
a broad/multicast or unknown single destination, for example, a multicast packet 
originating on an ethernet segment will be flooded onto the FDDI ring and the 3
other ethernets by the 6614, the packet is then received back on the FDDI ring 
by this bridge and stripped, however, the packet is now flooded down all 4 
ethernets, including the originator. To make matters worse as the packet is seen 
to have come off the ring the forwarding database is updated to reflect this and 
so the originator of the multicast is not reachable off its own segment until it 
transmits again - imagine if this was a boot me request or a DECnet routing 
update - would the device ever load and how does decnet deal with getting its 
own update back?

Regards,

Tony.
T.RTitleUserPersonal
Name
DateLines
832.1KONING::KONINGPaul Koning, A-13683Fri Jan 15 1993 12:1310
Wow.

Is that a chipset design error or is the bridge using it wrong?  Sounds like
it would be useful to look at the chip documentation.

Then again... how confident are you of this diagnosis?  It sounds like the
sort of problem that's too severe ever to make it out of the lab, so  I'm a
little sceptical.

	paul
832.2Not the first time.VIVIAN::MILTONCAUTION - Unresolved PostulatesMon Jan 18 1993 05:2032
Paul,

It took a lot of kit to get the ring latencey up to 5 microseconds - 7 x 6614s,
2 x 6800 DXs and a couple of Cabletron concentrators, in fact at one point they
were putting this down to a concentrator problem as it only occurred when the 
last conc. was put in the ring. NSC here in the UK have been trying to emulate 
the problem but they don't stand a chance because Warburgs (the customer) has all
their kit. I understand that NSC Miniapolis (sp?) are starting to do some testing
but their first comment was that this looks like a configuration problem - 
Warburgs are not impressed.

As far as chip or implementation goes - I've had a look at Nat Semi's application
note and this area seems to be dependant on "additional logic" including the 
maintainence of a stripping flag - I can fax you a copy of these should you need
them.

As far as Warburgs are concerned, this isn't getting out of their lab - they've 
only got the 6614s (which NSC has had to give them free) because NSC could not
supply a translation bridge option for the 6800 DX (as promised) due to AMD 
chipset/implementation problems.

Warburgs have demonstrated this problem to me and given the evidence I must agree
with their diagnosis. In fact during the lab session we had an instance of a 
no-owner frame wreaking havoc - this frame was an ethernet broadcast which the
transation bridges put on each ethernet once per rotation. The no-owner frame 
also showed up a mis-understanding about the Cabletron ring puging opperation 
which turned out to be ring scrubbing - they are now convinced more than ever 
that they require ring purging and are fast coming to the conclusion they should
use Digital's.

Regards,
Tony.
832.3KONING::KONINGPaul Koning, A-13683Mon Jan 18 1993 11:436
I'd be interested in additional information, but I don't really have any 
significant time to spend on this.  So at your leasure...

Sure sounds like an excellent sales opportunity for some DECbridge-600s!

	paul