| 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 |
The customer has a relatively small 62.5micron ring under 30 meters around with several devices on the ring. Some devices include a DECbridge 510, a Proteon FDDI bridge, a Fibercom bridge and a PC based file server. When a PC client sitting on the DECbridge LAN (lets call this LAN_1), it is able to link up with and communicate using small packets to a PC based file server which is either on the ring or on another 802.3 lan, linked through a non-DEC Bridge (lets call LAN_2). When the PC tries to request a load of a large file which appears to come across as 1024 or large byte packets, a sniffer on LAN_1 reports that some 880 bytes have been lost from the packet. The number of bytes lost appears to be consistent in all attempts. Any other combination of non-DEC bridge and on/off the ring works w/o problems. The customer does not have DECelms so I was unable to gather further info about the bridge, but I've asked the local rep to supply same. The customer who appears to be rather knowledgeable in LAN technology reports that all known versions of FDDI "stuff" appears to be consistent (i.e. SMP is at V6.2 in all bridges). The PC interface is a 3Comm 3C507 and the interface on the PC server is a Netware Peripherals NE3200. I haven't had any hands on with our FDDI equipment so don't really know what to look for. Any suggestions or recommendations as to what to check or if you've heard of such behaviour would be greatly appreciated. thanks, Al
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 410.1 | Please provide more detail | KONING::KONING | Paul Koning, NI1D | Fri Dec 06 1991 12:24 | 12 |
I find this very hard to believe. Could you explain more precisely what you observe? For example, precisely what does it mean for a Sniffer to "report that 880 bytes have been lost from the packet"? Certainly all bridges will take special action on frames that exceed 1500 bytes (either by discarding them, or by fragmenting them if a fragmentation procedure exists for that protocol -- though NOT by truncating them). But bridges do not have any special interest in any other sizes, such as 1024. paul | |||||
| 410.2 | More info.... | DUCAT2::FOUR62::LICAUSE | Al Licause (338-5661) | Fri Dec 06 1991 16:34 | 34 |
In talking with the customer again, he corrected a statement earlier in that the amount of data that is trashed appears to change. Basically if the large packets are generated on the 802.3 side of the DECbridge, then all is fine, but if generated anywhere on the FDDI side, then the problems occur. This is still a poor explaination, but here goes: a request is sent from the PC on the 802.3 side of the 510 and the server on the FDDI side responds with what is reported to be a 1064 byte packet. Sniffer shows the DLC header to indicate "frame error, bad alignment". It indicates that the frame size is 630 bytes.... the XNS header shows a length of 1064 in the 2nd byte.... then the sniffer shows 616 bytes in the frame. I realize that this a very poor explaination, but the customer has a trace of the data generated by a Network General Sniffer. He is willing to air ship this to us.....any takers? Anything make any sense here? Anything to look at? Sorry for the lack of detail but its really the blind leading the blind using a 1500 mile stick. Al | |||||
| 410.3 | Need to escalate to get support resources | BAGELS::LEVY | Fri Dec 06 1991 17:03 | 4 | |
There is no known bug to account for the behavior you've described.
I recommend that you use your normal escalation process to get support
from your geography CSC, and CLD this problem, if necessary.
| |||||
| 410.4 | KONING::KONING | Paul Koning, NI1D | Fri Dec 06 1991 18:18 | 4 | |
Frame error, bad alignment is a clear indication of broken hardware. Time for field service... paul | |||||
| 410.5 | thanks | DUCAT2::FOUR62::LICAUSE | Al Licause (338-5661) | Mon Dec 09 1991 08:35 | 5 |
Thanks to both .3 and .4. I"ll push it back to the sale rep and have him escalate. Al | |||||