imp@osa.com (Charles T. Lukaszewski) (09/04/90)
In our experience, the symptoms you describe may derive from one of both of a combination of two factors. There may be others. We have done extensive testing of every major protocol analyzer on the market and have found the Sniffer to be somewhat inaccurate, sometimes by substantial amounts, in its current form. In particular, when the results of a Sniffer analysis are compared to the interface statistics of certain computers (VAXes, DG Aviion & Sun tested to date), they do not match, often by an order of magnitude. This affects most protocol analyzers to one degree or another. We've found the Hewlett-Packard 4972 to be accurate almost 100% of the time, and is an excellent benchmark for the Sniffer, if you can get your hands on one. Network General itself uses the 4972 to test the Sniffer. If you have twisted-pair ethernet, this may be another source of discrepancy. There is a problem in many vendors (at least ODS & Synoptics - we're still checking Cabletron & David Systems) implementations of collision handling under 10BaseT. As there is no distinct collision detect line under 10BaseT as there is in an AUI cable (10BaseT has only Transmit & Receive lines), collisions must be communicated to individual stations through a transmission of a special preamble. Depending on your network design, that preamble can be transmitted to the rest of the network. We have documented this behavior at several client sites, and it seems to affect Cisco routers more than any other kind of network device. Specifically, while just about every other network device or node will ignore the preamble as network "junk", the cisco picks it up as a network error. The solution is to place a filtering bridge between the Cisco(s) and any twisted-pair equipment. Ciscos should *not* be directly connected to either ODS or Synoptics hubs if you wish to avoid this situation. _______________________________________________________________________________ Chuck Lukaszewski imp@osa.com 612 525-0000 Managing Partner & Chairman Open Systems Architects, Inc. "Who needs a disclaimer? I liked the opinions so much, I bought the company."
smb@ulysses.att.com (09/06/90)
Since the item on Ciscos vs. 10BaseT networks was rather alarming to me, I forwarded it to Pat Thaler at HP, a member of the 10BaseT standards committee. Here is her reply, forwarded with permission: --Steve Bellovin ---- ------- Forwarded Message Return-Path: ulysses!hprnd.hp.com!pat Received: by ulysses; Wed Sep 5 16:20:25 1990 Received: by inet.att.com; Wed Sep 5 16:20 EDT 1990 Received: from hprnd.hp.com by hp-sde.sde.hp.com with SMTP (16.3/15.5+IOS 3.13) id AA21408; Wed, 5 Sep 90 13:20:13 -0700 Received: by hprnd.hp.com; Wed, 5 Sep 90 13:21:14 pdt From: Pat Thaler <pat@hprnd.hp.com> Full-Name: Pat Thaler Message-Id: <9009052021.AA14150@hprnd.hp.com> Subject: Re: 10BaseT incompatibilities? To: smb@ulysses.att.com Date: Wed, 5 Sep 90 13:21:12 PDT In-Reply-To: <9009051846.AA20249@hp-sde.sde.hp.com>; from "smb@ulysses.att.com" at Sep 05, 90 2:44 pm Mailer: Elm [revision: 64.9] (deleted) You may forward my response below on to the mailing list. > > > ------- Forwarded Message > > Return-Path: osa.com!imp > Message-Id: <9008312336.AA07191@osa.com> > Subject: Re: Inaccurate interface statistics/Sniffer > To: cisco-request@spot.Colorado.EDU (Cisco Mailing List) > Date: Fri, 31 Aug 90 18:36:00 PDT > > <Material on LAN analyzers deleted> > > If you have twisted-pair ethernet, this may be another source of > discrepancy. There is a problem in many vendors (at least ODS & > Synoptics - we're still checking Cabletron & David Systems) implementations of > collision handling under 10BaseT. > As there is no distinct collision > detect line under 10BaseT as there is in an AUI cable (10BaseT has > only Transmit & Receive lines), collisions must be communicated to > individual stations through a transmission of a special preamble. > Depending on your network design, that preamble can be transmitted to > the rest of the network. This is incorrect, there is no special preamble for 10BASE-T collisions and stations should see the same kinds of things they see on a coax network. Details follow: 10BASE-T handles collision just like a 10BASE2/10BASE5 (coax) LAN with repeaters. Stations connected to a segment with two active transmitters will get a collision indication (Signal Quality Error (SQE)) on the Control In (CI) pair of the AUI. On coax this would be any stations connected to a coax segment which has at least two transmitters active (actually, that is only true when the stations have transceivers with receive mode collision detect; stations with transceivers with transmit mode collision detect may not see the collision indication if they are not transmitting). On twisted pair only stations which are transmitting will see SQE (because there are only two transceivers per segment). Stations attached to a segment with only a single transceiver transmitting (whether twisted pair or coax) see the same thing during collision. They see a packet which begins with normal preamble and has fewer than 512 bits following the start of frame delimiter. They are suppose to know to reject packets which are shorter than minFrameSize (that is 512 bits) as collision fragments. This is true regardless of whether they are Ethernet Rev 1, Ethernet Rev 2 or IEEE 802.3 stations. The repeater standard (IEEE 802.3d) requires that all repeaters begin transmitting with at least the first 62 bits being a repeating pattern of 101010.... If a collision is detected, jam after the first 62 bits have been sent may consist of any bit pattern as long as it is not intentionally concluded with the correct CRC for the bits sent. There is no special preamble or collision pattern for 10BASE-T. (Repeater designers often choose to jam with the same pattern as preamble, so collision fragments where the collision was detected during pramble may look like a very long preamble with no start of frame delimiter.) Stations with non-receive mode collision detect transceivers attached to a coax segment with more than one other transceiver transmitting may not see collision detect. They will see a packet of less than 512 bits, but the content is indeterminate since they are seeing two transmissions superimposed on each other. Of course, statements about collision fragments being less than 512 bits may not hold if you violate the topology rules and let your network get too long. > We have documented this behavior at several client sites, and it seems to > affect Cisco routers more than any other kind of network device. > Specifically, while just about every other network device or node will > ignore the preamble as network "junk", the cisco picks it up as a > network error. The solution is to place a filtering bridge between > the Cisco(s) and any twisted-pair equipment. Ciscos should *not* be > directly connected to either ODS or Synoptics hubs if you wish to > avoid this situation. > I have heard before of problems with Cisco routers and short fragments. Perhaps you should talk to people at Cisco about this. A short fragment created by a collision is a normal part of Ethernet/IEEE 802.3 network operation, not a network error. These fragments are not specific to 10BASE-T operation only, they also occur on multi-segment coax LANs. > ______________________________________________________________________________ > Chuck Lukaszewski imp@osa.com 612 525-0000 > Managing Partner & Chairman Open Systems Architects, Inc. > "Who needs a disclaimer? I liked the opinions so much, I bought the company." > > ------- End of Forwarded Message > Pat Thaler pat@hprnd.hp.com ------- End of Forwarded Message