You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Packet loss occurs whenever a network packet doesn't reach its intended destination. Some packet loss is normal, and doesn't always cause higher-level networking issues. At other times, packet loss can reduce performance, and cause application programming interfaces (APIs) or applications to fail.
17
17
@@ -23,31 +23,47 @@ If pktmon diagnostics are inconclusive, more exhaustive component-level traces c
23
23
24
24
If the network interface card (NIC) is suspected as a cause of the packet loss, you can monitor its discard counters through any [performance counters](/windows-server/networking/technologies/network-subsystem/net-sub-performance-counters) interface or the [Get-NetAdapterStatistics](/powershell/module/netadapter/get-netadapterstatistics) cmdlet.
25
25
26
-
## Common causes of packet loss
27
-
28
-
### Local packet loss
26
+
## Common causes of local packet loss
29
27
30
28
Local packet loss is fully observable and can be caused by various internal and external factors.
31
29
32
-
- Local policy: inspection software might cause packets from remote machines to be dropped by default, such as when the Windows Firewall rejects inbound connection attempts. Cybersecurity or anti-malware software on the system can also cause these issues.
33
-
- Low resources: if the system or socket has run out of resources to handle the packet, the packet will be dropped. Examples of resource limits include physical memory on the system and socket send or receive buffers. Depending on the resource limit, these events might last only microseconds, such as when the system's CPU can't react quickly enough to a full receive buffer.
34
-
- ARP/ND failure: if the next hop for an outbound packet doesn't respond to Address Resolution Protocol (ARP) or neighbor discovery (ND) requests, then packets sent to that next hop will be dropped on the local system. Packets might also be dropped during ARP/ND processes if the ARP/ND packet queue limit is exceeded. The ARP/ND packets themselves are typically not dropped locally and belong to the remote packet loss category.
35
-
- No route: if the network layer can't find a valid route to the destination, packets might be dropped.
36
-
- Invalid packet: if the packet headers are invalid, the packet might be dropped. For example, the packet headers contain an invalid checksum or field value.
30
+
- Local policy
31
+
32
+
Inspection software might cause packets from remote machines to be dropped by default, such as when the Windows Firewall rejects inbound connection attempts. Cybersecurity or anti-malware software on the system can also cause these issues.
33
+
- Low resources
34
+
35
+
If the system or socket has run out of resources to handle the packet, the packet will be dropped. Examples of resource limits include physical memory on the system and socket send or receive buffers. Depending on the resource limit, these events might last only microseconds, such as when the system's CPU can't react quickly enough to a full receive buffer.
36
+
- ARP/ND failure
37
+
38
+
If the next hop for an outbound packet doesn't respond to Address Resolution Protocol (ARP) or neighbor discovery (ND) requests, then packets sent to that next hop will be dropped on the local system. Packets might also be dropped during ARP/ND processes if the ARP/ND packet queue limit is exceeded. The ARP/ND packets themselves are typically not dropped locally and belong to the remote packet loss category.
39
+
- No route
40
+
41
+
If the network layer can't find a valid route to the destination, packets might be dropped.
42
+
- Invalid packet
43
+
44
+
If the packet headers are invalid, the packet might be dropped. For example, the packet headers contain an invalid checksum or field value.
37
45
38
-
### Remote packet loss
46
+
##Common causes of remote packet loss
39
47
40
48
Remote packet loss isn't directly observable to the local machine when the packet is dropped. The IP (Internet Protocol) protocol and most layers below it are "best effort" and not reliable. The [end-to-end principle](https://en.wikipedia.org/wiki/End-to-end_principle) requires endpoints to implement reliability within their protocols if resilience to packet loss is required. In some scenarios, the network or remote endpoint sends a protocol-specific error message indicating the reason for the loss. However, in many cases, the only indication of packet loss is a lack of response.
41
49
42
-
- Congestion: loss-based congestion control algorithms send faster and faster until a packet is lost. If the algorithm infers the loss is caused by [congestion](https://en.wikipedia.org/wiki/Network_congestion), it temporarily reduces the rate of sending in response. These algorithms require a small amount of loss to provide a feedback signal.
43
-
- Remote policy: the network or remote machine might drop packets according to its own policy.
44
-
- Destination unreachable: this can occur if the remote machine doesn't have a socket bound to the remote port, remote machine is offline, or the network can't find a path to the remote machine.
45
-
- Session loss: if the network (including stateful Network Address Translation (NAT), firewalls, load balancers, and so on) or the remote machine is reset or hasn't received a packet recently, its session context might expire, and subsequent packets are dropped.
46
-
- Maximum Transmission Unit (MTU) drops: this might produce an Internet Control Message Protocol (ICMP) fragmentation required or packet too big error if the size of the packet exceeds the maximum transmission size of a network link along the path to the remote machine.
50
+
- Congestion
47
51
48
-
## Examples
52
+
Loss-based congestion control algorithms send faster and faster until a packet is lost. If the algorithm infers the loss is caused by [congestion](https://en.wikipedia.org/wiki/Network_congestion), it temporarily reduces the rate of sending in response. These algorithms require a small amount of loss to provide a feedback signal.
53
+
- Remote policy
49
54
50
-
### Pktmon
55
+
The network or remote machine might drop packets according to its own policy.
56
+
- Destination unreachable
57
+
58
+
This can occur if the remote machine doesn't have a socket bound to the remote port, remote machine is offline, or the network can't find a path to the remote machine.
59
+
- Session loss
60
+
61
+
If the network (including stateful Network Address Translation (NAT), firewalls, load balancers, and so on) or the remote machine is reset or hasn't received a packet recently, its session context might expire, and subsequent packets are dropped.
62
+
- Maximum Transmission Unit (MTU) drops
63
+
64
+
This might produce an Internet Control Message Protocol (ICMP) fragmentation required or packet too big error if the size of the packet exceeds the maximum transmission size of a network link along the path to the remote machine.
65
+
66
+
## Example of Packet Monitor traces
51
67
52
68
Running the following commands:
53
69
@@ -66,7 +82,7 @@ The resulting **PktMon.txt** file contains lines such as:
66
82
67
83
This information indicates the inbound UDP packet destined to port 50005 was dropped because there was no local socket bound to the port.
68
84
69
-
### Component traces
85
+
##Example of Network Shell traces
70
86
71
87
Running the following commands:
72
88
@@ -86,7 +102,7 @@ This information indicates the outbound ICMP packet was dropped due to Windows F
86
102
87
103
In another scenario, a previously sent TCP segment hasn't been acknowledged by the remote endpoint, and eventually a local retransmit timer fires, causing TCP to resend some of the potentially lost data:
88
104
89
-
```txt
105
+
```output
90
106
[31]0000.0000::<DateTime> [Microsoft-Windows-TCPIP]TCP: Connection 0xFFFFE189BD811AA0 0(RetransmitTimer) timer has expired.
Copy file name to clipboardExpand all lines: support/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting.md
+4-2Lines changed: 4 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,14 @@
1
1
---
2
2
title: TCP/IP connectivity issues troubleshooting
3
3
description: Learn how to troubleshoot TCP/IP connectivity and what you should do if you come across TCP reset in a network capture.
4
-
ms.date: 01/15/2025
4
+
ms.date: 04/28/2025
5
5
ms.topic: troubleshooting
6
6
manager: dcscontentpm
7
7
ms.collection: highpri
8
8
ms.custom:
9
9
- sap:network connectivity and file sharing\tcp/ip connectivity (tcp protocol,nla,winhttp)
10
10
- pcy:WinComm Networking
11
-
ms.reviewer: dansimp
11
+
ms.reviewer: dansimp, mifriese, guhetier
12
12
audience: itpro
13
13
---
14
14
# Troubleshoot TCP/IP connectivity
@@ -53,6 +53,8 @@ When a TCP peer sends packets without receiving a response, the peer retransmits
53
53
54
54
Simultaneous network traces at both the source and destination can verify this behavior. On the source side, you can see the retransmitted packets. On the destination side, these packets don't be present. This scenario indicates that a network device between the source and destination is dropping the packets.
55
55
56
+
For more information about diagnosing packet loss issues, see [Diagnose packet loss](diagnose-packet-loss.md).
57
+
56
58
### Scenario 1: Packet loss during initial TCP handshake
57
59
58
60
If the initial TCP handshake fails due to packet drops, the TCP SYN packet is retransmitted three times by default.
0 commit comments