stewart@mitel.misemi (John Stewart) (02/24/89)
There has been a lot of discussion in this newsgroup about various hardware combinations either working or not working. As Networks Manager of a fairly large network (about 100 workstations, 140 terminal servers, 20 vaxes, and more macs and pcs than you can shake a stick at), I have run across a few problems that the average person might not have seen (yet!). I have listed them below, not in any particular order. Our site is mostly sun/dec, so some of the names are vendor specific. Using Ethernet V2 tranceivers and IEEE 802.3 tranceivers interchangably. Not a good idea! V2 tranceivers are dc-coupled, 802.3 tranceivers are ac coupled. the 802.3 specs call for a signal called SQE (heartbeat) which I can't seem to find in the V2 specs that I have here. Some controllers can accept either, some can't. My sun 3/50 does not work with a DEC H-4000 thickwire tranceiver, no matter how the sun dip switches are set. We have another device that has only thin wire running to it, and to get it to run we had to connectorize in a few feet of thick wire, and put in a DEC H-4000. We also no longer have our sun fileservers running through our DEC fanout box (DELNI), using thinwire tranceivers (DESTAs) has pretty well solved our "ie0: no carrier" and "ie0 spurrious interrupt" problems. (the DELNI seemed to work fine till we hit the 30-50% ethernet utilization on that network). Connecting a repeater to a fan out box (DELNI) is not a good idea. The reason? The SQE signal (heartbeat) is also the collision detect signal (only the controller knows for sure which meaning is valid at that exact moment in time), so: lets say that we have a repeater connected to port 1 of our DELNI. port 2 is connected to our busy vax. there is a tranceiver that supports heartbeat connected to the outgoing port of the DELNI. The Vax transmits. The repeater sees the cd (collision detect line) activated because the tranceiver sends a heartbeat. The repeater must then (by definition) JAM its other ports, propagating its (assumed) collision to the other segments. Think about it. Imagine also connecting up a repeater that doesn't support heartbeat detection to a tranceiver that does? There goes the bandwidth! (ie, in decland, don't connect a DEREP to a DESTA) ANY repeater will have these problems! Watch out for repeaters connected up to thin wire repeaters (DEMPRs) also. Other people have mentioned some devices sourcing the multicast address in an ethernet packet. We had this problem also. Our culprit was sending this bad packet very intermittently (maybe once every 2 or so days). The symptoms? "Hey, our new HP's can't receive any incoming connection requests from the vaxes". Blame the HP's. Nope. Blame it on TCP/IP interoerability problems. nope. look at a lot of the traffic monitors for problems. nope. write a monitor myself to use the "spare" cpu cycles on a batch 8650. find bad packet once. look at getting the IEEE standard that DEC says that their bridges follow for managing and exchanging bridge info. Standard is not published. Weep and get the DEC Remote Bridge Management Product. Looks good. Ask the bridges for a list of the addresses theyve seen. Funny, bad address not listed. Ask the bridges "have you seen a source of FF-FF-FF-FF-FF-FF?" they respond, "yeah, i guess i did on port 1" (or 2) Write a program that uses this RBMS to go and ask the bridges every 5 minutes where the address was found. If found, mail me which port on which bridge, and delete that address from the forwarding databases. move our spare bridge around, breaking the networks up until the one workstationthat was sending the bad packet is isolated. (below is a capture of one of thesepackets with my home grown program) example protocol types: 6003 DEC_NET 6004 DEC_LAT 0800 DOD_IP 0806 IP_ARP Protocol Type (HEX) (0 for all): Sending Address (HEX) (0 for all): FF-FF-FF-FF-FF-FF Destination Address (HEX) (0 for all): ** Packet #1 ** Source: FF FF FF FF FF FF General Purpose multicast Destination: FF FF FF FF FF FF General Purpose multicast Protocol: FFFF Not a defined protocol type FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................ FF FF FF FF FF FF 00 01 00 00 00 0A 00 00 00 00 ................ 00 00 00 00 00 00 0A 03 00 00 00 01 00 08 00 00 ................ 1E 96 32 D0 66 4B 00 00 00 08 00 00 1A 3F 08 1A ..2PfK.......?.. DA 28 00 00 Z(.. Don't believe what loading some of the ethernet monitors show you. I have had (friendly) arguments between myself and one of the sun managers over whose figure is accurate. conclusions? yes, ethernet is busy 100% of the time if your sample time is small enough. Yes, the sun only reports packets that are sourced/ destined to it, not to anyone else. Yes, (we think) that the sun only looks at the data field of the packet to calculate loading. We have just bought a monitor that is a bit different from the rest. It is called a NQA, it only looks at the basics of ethernet. It does not report on the contents of packets (useless to almost anybody except the developers), but on the cable characteristics and timing of the tranceivers. Great for anybody with a big cable plant. Besides, with decs LTM and my own program, this is all that we need. When the reports of problems talking to fileservers/vaxes from people whose frequency of problems are proportional to their location on a thinwire segment look at the length and the cable properties to see/find/fix problems. (see the NQA stuff above) It's amazing how few 185 meters is when a cable snakes around desks and into the ceiling a dozen times. It is amazing how a cable can come loose. We have had thickwire crimps fall apart, tranceiver cables come undone, tranceiver cables break, people undoo tees to get rid of "that ugly cable"... Software engineers don't know about ground loops, and why those Tees that dec sells are insulated. Run thinwire between buildings (different transformers) and you'll see the un-insulated "ground" of the Tee somewhere above the ground of the local power supply. (yes, I'm a software engineer, who was educated by hardware types in previous jobs) Don't let a novice installer drill into the thickwire cable with his handy Black and Decker drill, if its grounded, then he can do a lot of damage to tranceivers, (ground loops again) If I remember right,the IEEE 802.3 spec mentions insulation of the shield from ground with insulatedhardware. maybe not. How can you learn more about Ethernet and IEEE 802.3 stuff? - read the product manuals - read DEC's Networks and Communications guide, and make a table of what tranceiver works with what box - read the specs. The version 2 specs that I have (from DEC) are very readable. The IEEE 802.3 specs are a lot harder, but still digestable. - Try things. Don't believe everything you read (including this!). I hope that some of the above is useful to someone. John Stewart Computer Internetworking Manager Mitel Corp. 613-592-2122