This KB document the behavior seen on all EVO platform with respect to TCP session of BGP and LDP wherein duplicate Ack

customer might observe duplicate ack on TCP session of BGP and LDP even though there is no physical issue on the media also no out of order neither retransmission of TCP packet received from peer device 

Below log in monitor traffic command shows the symptoms observed by the customer

13:52:45.268555 IP 10.10.10.18.49248 > 10.10.10.44.bgp: Flags [P.], seq 1261532:1261551, ack 722, win 31303, options [nop,nop,TS val 4205705348 ecr 3156865677], length 19: BGP
13:52:45.268789 IP 10.10.10.44.bgp > 10.10.10.18.49248: Flags [.], ack 1261551, win 31856, options [nop,nop,TS val 3156868074 ecr 4205705348], length 0
13:52:45.269041 IP 10.10.10.44.bgp > 10.10.10.18.49248: Flags [.], ack 1261551, win 31856, options [nop,nop,TS val 3156868075 ecr 4205705348], length 0

The observed behavior is inherent to NSR (Non-Stop Routing) and is consistent across all EVO platforms that support NSR
To better understand this, it is important to analyze the handling of TCP ACK packets in an NSR environment.
In NSR, maintaining connection continuity during a Routing Engine switchover (master -> backup) is critical. The system must ensure that no byte is lost within the TCP sequence space, as any loss could lead to session disruption.
A TCP ACK packet conveys two key pieces of information:
 - Acknowledgment number (ACK number)
 - Advertised receive window size

Under normal circumstances, the Linux TCP stack generates ACK packets upon receiving data from the peer. However, in an NSR setup, this behavior is modified:

The ACK number generated by the Linux stack is overwritten by NSR using the sequence number replicated to the backup RE, ensuring synchronization between master and backup.
The advertised window size is adjusted to reflect the minimum available window between the master and backup RE, maintaining consistency across both nodes.

When the application on the backup RE processes a PDU, it updates the TCP receive window. Consequently, a window update must be propagated to the peer to accurately indicate available buffer space for further data transmission.

As a result, even though tools like Wireshark may classify certain packets as duplicate ACKs, these packets can actually carry updated window size information and are therefore functionally meaningful.
In some cases, packets may appear with both identical ACK numbers and window sizes, potentially indicating redundant transmissions generated by the NSR logic. While there may be scope to optimize this behavior, any such changes require careful validation to ensure that TCP state synchronization and NSR resiliency are not compromised.