My original question:
>Hello sun-managers,
>
>Since a few days I get the following message on my console:
>
>Oct 26 09:50:38 krimson vmunix: le0: Receive: giant packet from <address>
>Oct 26 09:50:38 krimson vmunix: le0: Receive: STP in rmd cleared
>
>The mentioned ethernet-address is of a Sparc2. This machine is running
>SunOS 4.1.1 Rev. B. The Sun 3/60 on which I get the messages runs SunOS
>4.1.1_U1.
>I have read the manual and found the following:
>
>le%d: Receive: STP in rmd cleared
> The driver has received a packet that straddles multiple
> receive buffers and therefore consumes more than one of the
> LANCE chip's receive descriptors. Provided that all stations
> on the Ethernet are operating according to the Ethernet specifica-
> tion, this error "should never happen," since the driver allocates
> its receive buffers to be large enough to hold packets of the largest
> permitted size. Most likely, some other station on the net is
> transmitting packets whose lengths exceed the maximum permitted
> for Ethernet.
>
>How can it be that our Sparc puts packets on the ethernet that exceed the
>maximum length? Have I configured something wrong? Should I worry about
>those messages?
>
>Of course I will summarize.
>
>Thanks in advance,
>
>Johan Thole.
Thanks to the following persons:
Arie Bikker <aribi@geo.VU.NL>
david@srv.PacBell.COM
Michael Squires <mikes@moose.cs.indiana.edu>
dan@ees1s0.engr.ccny.cuny.edu
root@cas.ds.boeing.com
fmc@key.amdahl.com
grs@claircom.com
BILL CALKINS <YBC5+aZEUS%Haworth@mcimail.com>
peter@key.amdahl.com
celeste@xs.com
ats@prosun.first.gmd.de
The general consensus is that the problem described above can have
(at least) three causes:
1) existance of more than one protocol on the same physical segment.
If you run e.g. AppleTalk or decnet together with tcp/ip on the same
network, this can cause problems.
2) a too long physical segment.
If your network does not comply with the 802.3 standard, you can
expect such problems.
3) a hardware problem, such as a defect bridge, router or ethernet-card.
Such defects seem to be very hard to track down. The best you can
do is to control the correct operation of each component by monitoring
before and after it.
The ``giant packet problem'' can be serious, because it can degrade your
performance to a great extend. The cause of this problem can be very hard
to track down.
In our case I think it will be cause 1 or 2. When we were running our
own little network with three suns nothing was wrong. The problems began
when we were added to another segment. I already discovered that now
we are running Banyan Vines and tcp/ip on the same network. I haven't heard
of problems with Banyan Vines, but I expect this could be the cause. When there
IS a hardware-problem it will almost surely be those folks with their PC's.
Below are included the answers I got:
--------------------------------------------------------------------------------
>From @bronto.geo.VU.NL:aribi@geo.vu.nl Mon Oct 26 17:05:23 1992
Date: Mon, 26 Oct 92 16:50:28 +0100
From: Arie Bikker <aribi@geo.VU.NL>
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210261550.AA18796@bronto.geo.vu.nl>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
Hallo,
Wij hebben dergelijke messages ook wel eens. Het ethernet adres dat er
bij staat is onbetrouwbaar, we hebben ook wel eens adress ff:ff:ff:ff:ff
gezien. Waarschijnlijk wordt het achterste eeind van het packet door een
ander overschreven, cq te klein tijdsinterval tussen pakketten. Ik ben al
tijden op zoek naar een oorzaak. Ik heb sterk het vermoeden dat het te
maken heeft met Apple Mac's met ethertalk op dezelfde kabel. Zou dat een
mogelijkheid zijn?
[Translation by Johan Thole]
-We also have these messages sometimes. The report ethernet-address is
-unreliable. We sometimes have address ff:ff:ff:ff:ff. I think that either
-the tail of one packet is overwritten by another one, or the interval
-between two packets is to small. It could be due to Apple Mac's with
-ethertalk on the same cable. Is this a possibility?
groeten,
Arie Bikker
___=======-----
------------------------------------
-- Drs. Arie Bikker --
-- Instituut voor Aardwetenschappen --
-- Vrije Universiteit --
-- Amsterdam Netherlands --
-- aribi@geo.vu.nl --
------------------------------------
--------------------------------------------------------------------------------
>From david@srv.PacBell.COM Mon Oct 26 22:02:28 1992
Date: Mon, 26 Oct 92 12:17:24 PST
From: david@srv.PacBell.COM
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210262017.AA13209@ncc-1701.srv.PacBell.COM>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
are you also running decnet and/or appletalk? they often cause the problem.
our "giant packet" problem was finally resolved by upgrading the proms on
the fastpaths.
--------------------------------------------------------------------------------
>From mikes@moose.cs.indiana.edu Mon Oct 26 22:07:47 1992
Date: Mon, 26 Oct 1992 16:04:14 -0500
From: Michael Squires <mikes@moose.cs.indiana.edu>
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <0345012E800490EA@HEARNVAX.nic.SURFnet.nl>
In-Reply-To: <9210261221.AA05192@krimson.cs.rulimburg.nl>
Newsgroups: cs.works.sun
Organization: Indiana University, Bloomington
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
One way this happens is if your network cabling is too long and packets
are being run together.
--
Mike Squires (mikes@iuvax.cs.indiana.edu) 812 855 3974 (w) 812 333 6564 (h)
mikes@iuvax.cs.indiana.edu 546 N Park Ridge Rd., Bloomington, IN 47408
--------------------------------------------------------------------------------
>From dan@ees1s0.engr.ccny.cuny.edu Mon Oct 26 22:07:49 1992
Date: Mon, 26 Oct 92 14:37:26 EST
From: dan@ees1s0.engr.ccny.cuny.edu
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210261937.AA12145@ees1s0.engr.ccny.cuny.edu>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
Johan,
Are you sure that your ethernet is within the specs? What is the
collision rate? Funny things are known to happen if the ethernet sement
is too long or other wise does not follow the specification.
/dan
--------------------------------------------------------------------------------
>From root@cas.ds.boeing.com Mon Oct 26 22:28:56 1992
Date: Mon, 26 Oct 92 10:08:38 PST
From: root@cas.ds.boeing.com
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210261808.AA06054@cas.ds.boeing.com>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
Sounds like multiple platforms on the same network and on the same router.
Separate them according to architecture and install more router/concentrators.
Each router should have one common architecture to be safe.
Bill Orr
--------------------------------------------------------------------------------
>From fmc@key.amdahl.com Tue Oct 27 02:06:31 1992
Date: Mon, 26 Oct 92 16:57:59 PST
From: fmc@key.amdahl.com
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210270057.AA02187@raider.key.amdahl.com>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
We`ve experienced a similar condition with one of our SGI`s and a Sun server,
a 4/690 running 4.1.1, but the giant packets are reported to be comming from
a MAC address which corresponds to our router because they are being forwarded
through the router.
We put an lanalyzer on the subnet where these were able to capture one of
these giant packets. By dissecting the packet we could see that it was actually
composed of 6 packets which had run together. Our next step (when we find time)
will be to place the lanalyzer and a mux just in front ot the SGI and see if
we can capture another giant packet. If we find one there then the culprit is
probably the SGI. If not we`ll move the lanalyzer/mux to just in front of the
router and see if the packets are giant packets before they reach the router
or after. This should help us isolate the problem between the host, network,
and router.
We only seem to see this when our SGI users does several simultaneous compiles
on the SGI.
I'll keep you posted on what we find but would be interested in hearing in
your progress also.
Incidentally this seems to have a significant impact on our network. Fortunately
it is our least busy network and critical work is not being performed there.
fmc
fmc@key.amdahl.com
--------------------------------------------------------------------------------
>From grs@claircom.com Wed Oct 28 00:16:59 1992
Date: Tue, 27 Oct 92 09:36 PST
From: grs@claircom.com
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <m0mjuqV-0000j4C@torpedo.claircom.com>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
This is something of a misleading error message. A number of
things can cause this, and they may have nothing to do with
the machine mentioned in the logged message.
I was involved in tracking something like this in a very large
network, where a number of these errors would come out every
night, and the logged host would change. The cause of it
turned out to be, after 6-8 months of casual/serious investigatino,
a broken ethernet board in a PC.
There were also many CRC errors logged during the time this was
going on, which also helped in diagnosing the problem.
Eventually, we ended up separating various segments of the network,
disconnecting the coax portion, and doing something of a binary
search with disconnecting hubs and seeing where the CRC errors
turned up. Eventually, we got to this port, and after taking
this PC off the network, no CRC errors or giants were logged
ever again.
All in all, very much a headache. Good luck..
Gregg Siegfried
grs@claircom.com
--------------------------------------------------------------------------------
>From YBC5+aZEUS%Haworth@mcimail.com Wed Oct 28 00:17:08 1992
Date: Tue, 27 Oct 92 16:06 GMT
From: BILL CALKINS <YBC5+aZEUS%Haworth@mcimail.com>
Subject: Giant packets
To: JOHAN <thole@CS.RULIMBURG.NL>
Message-Id: <63921027160636/0005057003ND1EM@mcimail.com>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
This message is something to be concerned about. I was getting it and it was
locking up a station. The problem turned out to be a fiber optics interface car
d
that was out of rev. Check out other parts of your network between the source
station and the receiving station as the source of the problem (ie routers,
repeaters, bad transceivers, etc.) Hope this helps.
--------------------------------------------------------------------------------
>From peter@key.amdahl.com Wed Oct 28 00:17:11 1992
Date: Tue, 27 Oct 92 07:44:33 PST
From: peter@key.amdahl.com
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210271544.AA14781@klatu.key.amdahl.com>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
Yes, I would definitely worry about those "giant packets" because we are
currently getting them on our server and everytime it happens, the users see:
Server not responding
Server okay
because it really kills the server.
However, I really can't answer your problem regarding the Sparcstation (but
want to see the summary!).
We have narrowed it down to our SGI machine spitting out packets of the wrong
length and it looks more and more like a hardware problem (a faulty transceiver
or bad ethernet board).
That could be the problem with that Sparcstation...a hardware problem.
Peter Sivo
Amdahl/Advanced Systems
peter@key.amdahl.com
--------------------------------------------------------------------------------
>From xs.com!celeste@stokely.mtview.ca.us Wed Oct 28 00:17:22 1992
Date: Tue, 27 Oct 92 06:30:17 PST
From: celeste@xs.com
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210271430.AA07633@xs.com>
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
You probably have either a noisy network condition (RF leaking into the
ungrounded network from somewhere), a bad transceiver, a bad transceiver
cable, or bad ethernet hardware in the Sun. (That list is from most-likely
to least-likely).
It depends on how often you see the errors, and under what circumstances.
..Celeste Stokely
Program Mgr for Unix Systems Administration Consulting, Expert Support Inc.
EMAIL: celeste@xs.com
--------------------------------------------------------------------------------
>From ats@prosun.first.gmd.de Wed Oct 28 11:03:01 1992
Date: Wed, 28 Oct 92 10:52:51 +0100
From: ats@prosun.first.gmd.de
Subject: Re: le0: giant packet received from <address>
To: thole@CS.RULIMBURG.NL
Message-Id: <9210280952.AA16602@prosun.first.gmd.de>
In-Reply-To: <9210261221.AA05192@krimson.cs.rulimburg.nl>
Newsgroups: info.sun-managers
Organization: GMD-FIRST, Berlin
X-Envelope-To: thole@CS.RULIMBURG.NL
Status: RO
This shouldn't happen, if both machines are on the same cable, then
one of the machine's ethernet port has a hardware-problem. But check
also the cable's and transceiver's.
Most likely this problem happen's if both machines are on different
networks and there is a bridge or router between them, we are seeing
this errors also, and located the bridge as the bad part, if the
bridge get to much traffic, it shuffles two packets from one network
to one packet on the other, hence a giant packet.
--
ATS ( ats@first.gmd.de or ats@cs.tu-berlin.de )
Andreas Schulz GMD-FIRST O-1199 Berlin-Adlershof Rudower Chaussee 5
Gebaeude 13.7 Tel: 030-6704-2658
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:51 CDT