2

I have a TCP session captured via switch port mirroring and tcpdump. When viewing it (in Wireshark), I see the same pattern whenever I send a message; here's an excerpt of the outbound packets (I don't capture the inbound ones...yet):

[PSH, ACK] Seq=34477 Ack=46645 Len=51 # sending first message
[ACK] Seq=34528 Ack=46714 Len=0 # acknowledge response (not shown)
[ACK] Seq=34528 Ack=46714 Len=0 SLE=46645 SRE=46714 # TCP Dup Ack!

[PSH, ACK] Seq=34528 Ack=46714 Len=51 # sending second message
[ACK] Seq=34579 Ack=46783 Len=0 # acknowledge response (not shown)
[ACK] Seq=34579 Ack=46783 Len=0 SLE=46714 SRE=46783 # TCP Dup Ack!

The question is, why do I get these "dup ack" packets, which in fact are TCP Selective Acknowledgement (SACK) packets that seem to be fully redundant with the regular ACK packets which precede them?

I see the above pattern all the time for this TCP flow. The machine is running RHEL7. When I run tcpdump on the regular interface (rather than the mirror), I do not see duplicate acks.

John Zwinck
  • 281
  • 2
  • 4
  • 17
  • Did you run tcpdump on the host these packets are supposedly originating from to be certain it is in fact not producing such duplicates? Given that your symptoms are pointing towards the port mirroring feature being a possible source of the duplication, you should really tell us, which switch model you are using. – kasperd Nov 07 '15 at 11:16
  • The packets are originating from the same machine (but on a different interface than the mirror input). The switch is an Arista 7150S-64. The host has two Ethernet intefaces connected to the switch: one for regular use and one for the mirroring/capture. – John Zwinck Nov 07 '15 at 11:39
  • Sending the mirrored packets to one of the TCP endpoints could potentially influence the outcome. Can you reproduce the problem if you let a different machine receive the mirrored packets? – kasperd Nov 07 '15 at 12:02

1 Answers1

2

The host recieves duplicate packets in your scenario - one copy comes from initial source, the other on mirror port. It replies to both, and then you see both answers on the mirror port.
The interface won't matter, as long as packet gets to be process to kernel only parameters that application care about is IP and port.

DukeLion
  • 3,259
  • 1
  • 18
  • 19
  • It should be noted that the act of starting tcpdump on the interface receiving the mirrored packets can also affect the outcome. By default tcpdump will switch the interface in promiscuous mode, which will let the kernel see packets it might otherwise not have seen. (And using tcpdump on a port mirror requires promiscuous mode in order to be useful, so the `-p` flag wouldn't be useful here.) – kasperd Nov 07 '15 at 12:05
  • not exactly, you can receive packets without promiscuous mode if your interface has rp_filter disabled. But scenario when you have mirrored traffic on the same box as source/origin of tcp flow you're monitoring has shitload of things that can go wrong. – DukeLion Nov 07 '15 at 12:10
  • The destination MAC on the mirrored packets would not match the address of the interface you connect to the mirror port. So if promiscuous mode is not enabled, the interface would drop the packets without the kernel ever seeing them. Enabling promiscuous mode and enabling rp_filter should however allow tcpdump to see the packets while the kernel IP stack will ignore them. – kasperd Nov 07 '15 at 12:27