while going down the rabbit hole of bed network performance at work we’ve narrowed the problem cause to duplicate packets showing up on a specific segment of leased metro Ethernet service. tshark filter helped us to see when duplicates occurred on monitored link
we’ve got pair of computers – A and B connected at both ends of the leased line. on A, having address 10.99.0.1, we’ve run
iperf3 -s
on B:
iperf3 -c 10.99.0.1 -b 100m
tshark running in parallel on A:
tshark -Y " tcp.analysis.duplicate_ack " -n -i eno1 port 5201
gave us plenty of:
128517 184.731650531 10.99.0.1 → 10.99.0.2 TCP 78 [TCP Dup ACK 128510#3] 5201 → 54634 [ACK] Seq=1 Ack=123520206 Win=406784 Len=0 TSval=4096524269 TSecr=3598616679 SLE=123521654 SRE=123533238 128519 184.731754636 10.99.0.1 → 10.99.0.2 TCP 78 [TCP Dup ACK 128510#4] 5201 → 54634 [ACK] Seq=1 Ack=123520206 Win=406784 Len=0 TSval=4096524270 TSecr=3598616679 SLE=123521654 SRE=123536134 128521 184.732136484 10.99.0.1 → 10.99.0.2 TCP 78 [TCP Dup ACK 128510#5] 5201 → 54634 [ACK] Seq=1 Ack=123520206 Win=406784 Len=0 TSval=4096524270 TSecr=3598616679 SLE=123521654 SRE=123542678 128829 184.805138628 10.99.0.1 → 10.99.0.2 TCP 78 [TCP Dup ACK 128827#1] 5201 → 54634 [ACK] Seq=1 Ack=124427574 Win=408192 Len=0 TSval=4096524343 TSecr=3598616753 SLE=124429022 SRE=124431918
interestingly bbr tcp congestion control algorithm handles very well such link and significantly degraded performance was noticeable when sender was using cubic algorithm.