Interesting Traces - Bogus Duplicate Packets
This trace was captured with Ethereal off a span port on a Cisco switch spaning a VLAN. As you can see from the summary Ethereal is reporting a lot of duplicate ACKs. In fact every packet from 10.1.1.146 is duplicated. However, there does not seem to be any reason for the duplicate packets and a look at the delta time shows that the duplicates occur really fast.
No. Time Source Destination Protocol Info
147 0.007741 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=81761 Win=8192 Len=0
148 0.000003 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 147#1] ftp-data > 49440 [ACK] Seq=1 Ack=81761 Win=8192 Len=0
149 0.031977 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
150 0.000250 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
151 0.000376 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
152 0.000013 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=84681 Win=8192 Len=0
153 0.000002 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 152#1] ftp-data > 49440 [ACK] Seq=1 Ack=84681 Win=8192 Len=0
154 0.037586 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
155 0.000251 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
156 0.000003 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=87601 Win=8192 Len=0
157 0.000003 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 156#1] ftp-data > 49440 [ACK] Seq=1 Ack=87601 Win=8192 Len=0
158 0.000494 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
159 0.000375 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=90521 Win=8192 Len=0
160 0.000004 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 159#1] ftp-data > 49440 [ACK] Seq=1 Ack=90521 Win=8192 Len=0
161 0.036347 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
162 0.000376 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
163 0.000376 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=93441 Win=8192 Len=0
164 0.000004 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 163#1] ftp-data > 49440 [ACK] Seq=1 Ack=93441 Win=8192 Len=0
165 0.000994 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
166 0.001749 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
167 0.000379 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=96361 Win=8192 Len=0
168 0.000003 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 167#1] ftp-data > 49440 [ACK] Seq=1 Ack=96361 Win=8192 Len=0
169 0.034972 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
170 0.001874 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
171 0.000250 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
172 0.000125 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=99281 Win=8192 Len=0
173 0.000003 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 172#1] ftp-data > 49440 [ACK] Seq=1 Ack=99281 Win=8192 Len=0
174 0.000245 192.168.1.14 10.1.1.146 FTP-DATA FTP Data: 1460 bytes
175 0.000253 10.1.1.146 192.168.1.14 TCP ftp-data > 49440 [ACK] Seq=1 Ack=102201 Win=8192 Len=0
176 0.000009 10.1.1.146 192.168.1.14 TCP [TCP Dup ACK 175#1] ftp-data > 49440 [ACK] Seq=1 Ack=102201 Win=8192 Len=0
I closer look at one of the originals and its duplicate show that the IP Identification value is the same so this is a real duplicate packet and not something generated by the host. The Time to Live values are also the same so its not a routing loop. I would expect a bridging loop to generate a lot more duplicates.
Frame 152 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:12:44:31:9c:40, Dst: 00:13:1a:ae:d5:08
Internet Protocol, Src Addr: 10.1.1.146 (10.1.1.146), Dst Addr: 192.168.1.14 (192.168.1.14)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0xeec4 (61124)
Flags: 0x00
Fragment offset: 0
Time to live: 58
Protocol: TCP (0x06)
Header checksum: 0x960f (correct)
Source: 10.1.1.146 (10.1.1.146)
Destination: 192.168.1.14 (192.168.1.14)
Transmission Control Protocol, Src Port: ftp-data (20), Dst Port: 49440 (49440), Seq: 1, Ack: 84681, Len: 0
Frame 153 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:12:44:31:9c:40, Dst: 00:13:1a:ae:d5:08
Internet Protocol, Src Addr: 10.1.1.146 (10.1.1.146), Dst Addr: 192.168.1.14 (192.168.1.14)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 40
Identification: 0xeec4 (61124)
Flags: 0x00
Fragment offset: 0
Time to live: 58
Protocol: TCP (0x06)
Header checksum: 0x960f (correct)
Source: 10.1.1.146 (10.1.1.146)
Destination: 192.168.1.14 (192.168.1.14)
Transmission Control Protocol, Src Port: ftp-data (20), Dst Port: 49440 (49440), Seq: 1, Ack: 84681, Len: 0
The solution has to do with how Cisco treats VLAN spans. If the span is configured for both ingress and egress then a packet will be copied when it enteres the VLAN and when it leaves the VLAN so the analyzer sees two copies.
This page was last modified on 05-06-26
Send comments and suggestions
to ndav1@cox.net