tperala@umn-d-ub.D.UMN.EDU (Tim Perala) (06/30/89)
I have been getting strange behaviour when pinging a particular host on the Internet. I have not seen this behaviour with any other host. Here is a script of what is happening... Script started on Thu Jun 29 14:41:41 1989 1% /etc/ping multimax.encore.com PING multimax.encore.com: 56 data bytes 64 bytes from 129.91.1.14: icmp_seq=0. time=215. ms 64 bytes from 129.91.1.14: icmp_seq=1. time=221. ms 64 bytes from 129.91.1.14: icmp_seq=2. time=210. ms 64 bytes from 129.91.1.14: icmp_seq=3. time=213. ms 64 bytes from 129.91.1.14: icmp_seq=3. time=220. ms 64 bytes from 129.91.1.14: icmp_seq=4. time=226. ms 64 bytes from 129.91.1.14: icmp_seq=5. time=229. ms 64 bytes from 129.91.1.14: icmp_seq=6. time=275. ms 64 bytes from 129.91.1.14: icmp_seq=7. time=1064. ms 64 bytes from 129.91.1.14: icmp_seq=8. time=284. ms 64 bytes from 129.91.1.14: icmp_seq=8. time=289. ms 64 bytes from 129.91.1.14: icmp_seq=9. time=622. ms 64 bytes from 129.91.1.14: icmp_seq=10. time=231. ms 64 bytes from 129.91.1.14: icmp_seq=12. time=598. ms 64 bytes from 129.91.1.14: icmp_seq=13. time=619. ms 64 bytes from 129.91.1.14: icmp_seq=14. time=307. ms 64 bytes from 129.91.1.14: icmp_seq=15. time=243. ms 64 bytes from 129.91.1.14: icmp_seq=16. time=224. ms 64 bytes from 129.91.1.14: icmp_seq=17. time=211. ms ^C ----multimax.encore.com PING Statistics---- 18 packets transmitted, 19 packets received, -5% packet loss round-trip (ms) min/avg/max = 210/342/1064 2% ^D script done on Thu Jun 29 14:42:34 1989 Notice that I receive multiple replies on some of the requests. I have no reason to believe that my ping program is in error. What are some possible explanations for this behaviour, aside from the obvious, that the recipient of the request is actually generating multiple replies from a single ICMP echo request? Just curious. Tim Perala Systems Programmer Information Services University of Minnesota, Duluth (218) 726-6122
cliff@violet.berkeley.edu (Cliff Frost) (06/30/89)
Duplicate ICMP Echo Replies are an interesting phenomenon. I've seen a lot of them and in my experience they have never been caused by errors at the recipient, although that is always a possibility. They seem usually to be caused by inappropriate link-level retransmission of the packets, and they sometimes point to a link that's failing or heading in that direction. For example, with some link-level protocols a device may see a NAK when the packet actually made it out the other end of the link, and it then does a retransmission of the packet. I have often seen this associated with the particular data patterns in the packet itself (groan!). In the past I've seen these within the UC Berkeley network, and on our local NSF Regional (BARRNet), and in both these cases they've meant trouble. That is, when I start seeing duplicates around here I'm sure that something in our net needs fixing fast. I don't think they always mean trouble. I see them occasionally going across the NSFNet backbone and yet we have no problems with the backbone. You can anonymously ftp a version of ping that detects and reports duplicates, as well as allows you to specify a data fill pattern from jade.berkeley.edu. The files of interest are pub/ping.c and pub/ping.8. Cliff Frost <cliff@cmsa.berkeley.edu> Data Communications and Network Services UC Berkeley RE: In article <1131@umn-d-ub.D.UMN.EDU> tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes: >I have been getting strange behaviour when pinging a particular >host on the Internet. I have not seen this behaviour with any >other host. >... >Notice that I receive multiple replies on some of the requests. >I have no reason to believe that my ping program is in error. >What are some possible explanations for this behaviour, aside >from the obvious, that the recipient of the request is actually >generating multiple replies from a single ICMP echo request?
iain@etive.ed.ac.uk (Iain Lindsay) (06/30/89)
I have observed multiple echo replies when using an old 3com ethernet V1.0 interface on one of our vaxes. What appears to happen is that the interface sends a packet, which is then followed on the wire by a packet from another machine, with minimal packet spacing. The 3com i/f erroneously thinks the two packets collided and flags an error, causing the packet to be retransmitted. Thus, the target host sees two identical packets and sends two replies. There are probably numerous other mechanisms which can duplicate packets and which do not invlove dogdy hardware. -Iain..
lars@salt.acc.com (Lars J Poulsen) (07/01/89)
In article <1131@umn-d-ub.D.UMN.EDU> tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes: >1% /etc/ping multimax.encore.com >PING multimax.encore.com: 56 data bytes ... >64 bytes from 129.91.1.14: icmp_seq=3. time=213. ms >64 bytes from 129.91.1.14: icmp_seq=3. time=220. ms ... >64 bytes from 129.91.1.14: icmp_seq=8. time=284. ms >64 bytes from 129.91.1.14: icmp_seq=8. time=289. ms >Notice that I receive multiple replies on some of the requests. >I have no reason to believe that my ping program is in error. >What are some possible explanations for this behaviour, aside >from the obvious, that the recipient of the request is actually >generating multiple replies from a single ICMP echo request? Somehow, two copies of an ICMP request made it to the host in question. Are there redundant routes ? Could two datagrams have been forwarded by two different gateways out of your LAN ? / Lars Poulsen <lars@salt.acc.com> (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!
boykin@calliope.Encore.COM (Joseph Boykin) (07/01/89)
In article <1131@umn-d-ub.D.UMN.EDU> tperala@umn-d-ub.D.UMN.EDU (Tim Perala) writes: >I have been getting strange behaviour when pinging a particular >host on the Internet. I have not seen this behaviour with any >other host. >>In article <25908@agate.BERKELEY.EDU> cliff@violet.berkeley.edu (Cliff Frost) writes: >>Duplicate ICMP Echo Replies are an interesting phenomenon. I've >>seen a lot of them and in my experience they have never been caused >>by errors at the recipient, although that is always a possibility. ... >I don't think they always mean trouble. I see them occasionally >going across the NSFNet backbone and yet we have no problems >with the backbone. The Internet host being talked about is mine, and since I've done must of the TCP/IP hacking on this system I thought it would be useful for me to respond. Firstly, I have also seen multiple ICMP replies from various hosts (although never from multimax.encore.com). And as was also suggested, I've never seen these to cause problems, either when we've recieved them or in other cases. Our host is hooked up to the Internet (NEARnet) via a Cisco gateway box. In doing some experimentation we've found that the real cause of the problem is that the gateway box is the one duplicating the reply messages. At this point we don't know why, but we'll look into it (after the July 4th holiday!). In case anyone is interested... the system is an Encore Multimax 520 with eight NS32532 CPUS's (8+MIPS/CPU) running a parallelized version of the MACH operating system. ---- Joe Boykin Encore Computer Corp Vice-Chair, IEEE Computer Societies' Technical Activities Board Internet: boykin@encore.com UUCP: encore!boykin
karn@ka9q.bellcore.com (Phil Karn) (07/02/89)
Here's one conceivable cause of the multiple echo phenomenon that I don't think anybody has suggested yet. How about mismatched versions of Ethernet between a host and a transceiver at some point along the path? Since IEEE 802.3 calls for a collision presence test signal to be generated by the transceiver after each packet while controllers designed for Ethernet version 1.0 have never heard of such a thing, is it possible that some controllers might treat this as a collision even when the packet has been sent successfully? Let's hear it for standards bodies making gratuitous changes to established de-facto standards. (You didn't think I'd resist the opportunity to say this, did you?) Pil
david@ms.uky.edu (David Herron -- One of the vertebrae) (07/02/89)
an anecdote for which I don't have much evidence.
I started noticing repeated ICMP Echo Replies after a change in
our local network. Now, I'm not 100% certain that we weren't getting
them before this change, but I was surprised to see them happening
afterward.
The change? The campus backbone is an Ungermann Bass broadband
system. We were using UB buffered repeaters to attach our local net a
channel on the broadband. But the campus is converting to using the
Chipcom Ethermodem III with Lanbridge 100. Our local net has Sun 3's,
a Sequent, uVaxII's with DELQA's and a variety of uVax workstations,
and some 3b2's and 3b1's. There may be some mismatching of ethernet
versions in there like Phil suggested.
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- New word for the day: Obnoxity -- an act of obnoxiousnessdennis@gpu.utcs.utoronto.ca (Dennis Ferguson) (07/03/89)
Without implying that it is necessarily a cause of duplicated datagrams, I note that a receiver on a busy HDLC link can receive duplicate copies of the same frame quite often if the error rate is high and link-level retransmissions are being done. The acknowlegement-retransmission scheme HDLC uses requires that the transmitter resend not only a frame which was received in error, but also all subsequent frames that were sent before the acknowledgement indicating a frame was lost arrives. If the transmitter is busy this means that not only will the lost frame be retransmitted but almost certainly the frame following the one in error and perhaps several more as well. Thus the receiver may often receive one or more frames following an error twice. According to the spec the receiver is supposed to drop all frames until the errant frame is received successfully. If I were implementing this scheme, however, and knew the link was only going to be used for IP and protocols equally unaffected by out of order delivery, I would be very tempted to hedge my bets by sending on everything that arrived without error regardless, this allowing me to lie a little bit and keep the window advancing if an error occured in the retransmission of a frame I got right the first time. Then again, maybe not. What I have observed is that when our link to the NSFnet (30-some kbps, between Proteon routers) becomes loaded it will produce an occasional duplicated packet. I'm pretty sure this isn't an ethernet problem since the frequency of occurance seems to be intimately related to the load on the slow link. I always wondered why this happened. The above seemed a plausible guess. Dennis Ferguson University of Toronto
nccpriv@hyper0.lynn.ge.com ("Kundrot, Andy") (07/14/89)
:I started noticing repeated ICMP Echo Replies after a change in
:our local network.
[stuf deleted]
:the campus is converting to using the Chipcom Ethermodem III with
:Lanbridge 100. Our local net has Sun 3's,a Sequent, uVaxII's with DELQA's
:and a variety of uVax workstations, and some 3b2's and 3b1's. There may
:be some mismatching of ethernetversions in there like Phil suggested.
:--
:<- David Herron; an MMDF guy <david@ms.uky.edu>
:<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
:<-
:<- New word for the day: Obnoxity -- an act of obnoxiousness
:--------
Our extended ethernet has 20+ segments linked together via LB100's with
about half of these going through Chipcom Ethermodem III's to our Plant Wide
Broadband. Some of the equipment I have tried to plug directly into the
Chipcom does not function properly and may result in the problem you describe.
Amongst these is my trusty HP-LANalizer. The Chipcom claims to be 802.3 and
the HP compatible with both 802.3 and Ethernet. I suspect the Chipcom is the
strange one.
You should also determine if SQE is wanted or not by annything you plug into
your Chipcoms (or your trancivers, MAUs, etc). If you have SQE set wrong all
kinds of weirdness will plauge your network. The LB100 does not realy care
about SQE but most DEC hosts MUST have it and many others MUST NOT have it.
This feature is switch selectible in the Chipcom. BTW if a host does not
expect SQE and it is enabled it may think there was a collision and if it does
expect SQE and does not get it the host may decide there was a problem with
transmition. Ether way you MIGHT get an unexpected retransmition.
On page 4-3 of the manual under COLLISIONS ON BROADBAND they state that
detection of a collision by one node does not garantee that all transmitting
nodes on the network will be aware of it. [stuff deleted] Any node that
detects a collision sends a signal in the collision channel. [Thus making all
other nodes aware of it] That is the theory, in reality I see high collision
rates at the ends of broadband runs and lower collision rates near the headend.
I do not have a lot of confidance in Chipcoms BroadBand collision detection
system and suspect that it could cause one segment to think there was a
collision when the packet actualy went through. (quoted without permission)
Mark E. Baldwin baldwinm@hyper0.lynn.ge.com or
Network Analyst baldwinm%hyper0.lynn.ge.com@crdgw1.ge.com
GE
Please remember that I only work for GE, I do not speek for them.