| 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 |
On a DEC7000 with DEMFA running OSF/1 V1.3, we get ICMP ECHO_RESPONSE duplicate packets quite often when we use the ping command. 137.132.1.1 is a proteon router on the same ring. Anyone know what the general cause of this is? Script started on Thu Oct 21 14:36:44 1993 leonis:~> ping 137.132.1.1 PING 137.132.1.1 (137.132.1.1): 56 data bytes 64 bytes from 137.132.1.1: icmp_seq=0 ttl=59 time=2 ms 64 bytes from 137.132.1.1: icmp_seq=1 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=2 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=3 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=4 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=5 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=6 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=7 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=8 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=9 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=10 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=11 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=12 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=13 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=14 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=15 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=16 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=17 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=18 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=19 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=19 ttl=59 time=2 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=20 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=21 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=22 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=23 ttl=59 time=15 ms 64 bytes from 137.132.1.1: icmp_seq=24 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=24 ttl=59 time=2 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=25 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=26 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=27 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=28 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=29 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=30 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=31 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=32 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=33 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=34 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=35 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=36 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=37 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=38 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=39 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=40 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=41 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=42 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=42 ttl=59 time=1 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=43 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=44 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=45 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=46 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=47 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=48 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=49 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=50 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=50 ttl=59 time=1 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=51 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=52 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=53 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=54 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=55 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=56 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=57 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=58 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=59 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=60 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=60 ttl=59 time=1 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=61 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=61 ttl=59 time=2 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=62 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=63 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=64 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=65 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=66 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=67 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=68 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=69 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=70 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=71 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=71 ttl=59 time=1 ms (DUP!) 64 bytes from 137.132.1.1: icmp_seq=72 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=73 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=74 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=75 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=76 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=77 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=78 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=79 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=80 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=81 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=82 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=83 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=84 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=85 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=86 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=87 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=88 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=89 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=90 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=91 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=92 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=93 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=94 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=95 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=96 ttl=59 time=3 ms 64 bytes from 137.132.1.1: icmp_seq=97 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=98 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=99 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=100 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=101 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=102 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=103 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=104 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=105 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=106 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=107 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=108 ttl=59 time=2 ms 64 bytes from 137.132.1.1: icmp_seq=109 ttl=59 time=1 ms 64 bytes from 137.132.1.1: icmp_seq=110 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=111 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=112 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=113 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=114 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=115 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=116 ttl=59 time=0 ms 64 bytes from 137.132.1.1: icmp_seq=117 ttl=59 time=0 ms ^C ----137.132.1.1 PING Statistics---- 118 packets transmitted, 118 packets received, +7 duplicates, 0% packet loss round-trip (ms) min/avg/max = 0/0/15 ms leonis:~> exit script done on Thu Oct 21 14:38:52 1993
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1121.1 | NETRIX::thomas | The Code Warrior | Thu Oct 21 1993 08:21 | 4 | |
Are you sure it isn't the proteon? Have you put an FDDI sniffer on LAN? Considering the way DEC OSF/1 does network input, I doubt it's being duplicated in the DEMFA input path. Could the proteon not be stripping its packets properly? Are you running the Ring Purger on this ring? | |||||
| 1121.2 | more information | ZPAC20::rick | Richard Tan - it's now or never | Thu Oct 21 1993 21:16 | 82 |
> Have you put an FDDI sniffer on LAN?
We will try to do this.
> Are you running the Ring Purger on this ring?
No - if I did, the DEMFA would freeze (literally) within minutes!
anyway, here's the output from "netstat -s -I mfa0":
mfa0 FDDI counters at Fri Oct 22 07:59:22 1993
65535 seconds since last zeroed
4294967295 ANSI MAC frame count
0 ANSI MAC frame error count
0 ANSI MAC frames lost count
4294967295 bytes received
2742590340 bytes sent
32557797 data blocks received
19510962 data blocks sent
207152955 multicast bytes received
854410 multicast blocks received
1844752 multicast bytes sent
24342 multicast blocks sent
0 transmit underrun errors
0 send failures
0 FCS check failures
0 frame status errors
0 frame alignment errors
0 frame length errors
0 unrecognized frames
0 unrecognized multicast frames
0 receive data overruns
0 system buffers unavailable
0 user buffers unavailable
0 ring reinitialization received
36 ring reinitialization initiated
0 ring beacon process initiated
0 ring beacon process received
0 duplicate tokens detected
0 duplicate address test failures
0 ring purger errors
0 bridge strip errors
0 traces initiated
0 traces received
0 LEM reject count
0 LEM events count
0 LCT reject count
0 TNE expired reject count
1 Completed Connection count
0 Elasticity Buffer Errors
mfa0 FDDI status
Adapter State: Running State
LED State: Yellow/Green
Link State: On Ring Running
Duplicate Address Condition: Absent
Ring Purger State: Purger off
Negotiated TRT: 7.987 ms
Upstream Neighbor Address: 00-00-93-00-C0-F6
UNA Timed Out: False
Downstream Neighbor Address: 08-00-2B-34-B6-5B
Ring Error Reason: Ring Init Received
Physical Port State: In Use
Neighbor Physical Port Type: Master
Reject Reason: Unknown
Physical Link Error Estimate: 15
mfa0 FDDI characteristics
Link Address: 08-00-2B-37-DC-63
Firmware Revision: V1.4
Hardware Revision: V5
SMT Version ID: 1
Requested TRT: 7.987 ms
Maximum TRT: 173.015 ms
Valid Transmission Time: 2.621 ms
LEM Threshold: 8
Restricted Token Timeout: 7705.600 ms
PMD Type ANSI Multimode
| |||||
| 1121.3 | NETRIX::thomas | The Code Warrior | Thu Oct 21 1993 22:13 | 1 | |
Why would the DEMFA freeze if you ran Ring Purger? | |||||
| 1121.4 | same (sort of) question | CSC32::PITT | Thu Aug 18 1994 09:44 | 14 | |
Similar problem: when customer ran netsetup and configured his defta,
he got "duplicate token found". As with the basenote, he does also
ocasionally get the dup packet on ping.
His ring consists of 7 alpha boxes (3000/300s with DEFTAs) a Cray and a
mystery...(may be a Proteon- he's not sure). He doesn't remember
getting that duplicate token found when configuring his other nodes.
Can you explain what a Ring Purger is? Would it eliminate this
problem? Is this what it sounds like it might be--some sort of echo
that the system is seeing as a valid packet???? Thanks!!!!!!!
| |||||
| 1121.5 | koning.lkg.dec.com::koning | Paul Koning, B-16504 | Thu Aug 18 1994 18:37 | 8 | |
Yes, the ring purger may help. Certainly it will help detect duplicate token problems (and as soon as they are detected, they are corrected by doing a Claim). However, a significant rate of duplicate tokens (more than a few per day) is a sign of something quite strange going on in your network. paul | |||||