When testing IPFIX functionality on Hyper-V, we noticed that the templates and flows would randomly be dropped without any Socket Send Error. On further debugging, we determined that the UDP based packets are dropped by the Windows stack only if there is no ARP entry present for the collector. This seems to be a common occurence on Windows with the way UDP based sockets are implemented.
If there is only 1 UDP packet sent over the socket, then Windows would try to resolve ARP and then send the packet. However, if the sender sends too many UDP packets, then Windows would start dropping packets at random until the ARP resolution is done.
ARP queues only one outbound IP datagram for a given destination address while that IP address is being resolved to a MAC address. If a UDP-based application sends multiple IP datagrams to a single destination address without any pauses between them, some of the datagrams might be dropped if there is no ARP cache entry present. An application can compensate for this by calling the Iphlpapi.dll routine SendArp() to establish an arp cache entry, before sending the stream of packets. See the platform Software Development Kit (SDK) for additional information.
The proposed solution expects the sender to trigger an explicit "SendArp()" prior to sending the packet. This would mean modifying the collectors struct to maintain the IP addresses of the remote collectors and triggering this function on Windows.
Currently, the IPFIX Collector is the only one that's relying on UDP based socket for Sending packets. Should the fix be scoped to the collectors_send() or keep it generic enough to trigger the SendArp() if it's an UDP based socket.
When testing IPFIX functionality on Hyper-V, we noticed that the templates and flows would randomly be dropped without any Socket Send Error. On further debugging, we determined that the UDP based packets are dropped by the Windows stack only if there is no ARP entry present for the collector. This seems to be a common occurence on Windows with the way UDP based sockets are implemented.
If there is only 1 UDP packet sent over the socket, then Windows would try to resolve ARP and then send the packet. However, if the sender sends too many UDP packets, then Windows would start dropping packets at random until the ARP resolution is done.
From MSDN: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc940021(v=technet.10)
Socket Creation: https://github.com/openvswitch/ovs/blob/master/ofproto/collectors.c#L66 Send Function: https://github.com/openvswitch/ovs/blob/master/ofproto/collectors.c#L117
Related stackoverflow/google group articles: https://stackoverflow.com/questions/11812731/first-udp-message-to-a-specific-remote-ip-gets-lost https://groups.google.com/forum/#!topic/comp.os.ms-windows.networking.tcp-ip/kDusE_QbKC4
The proposed solution expects the sender to trigger an explicit "SendArp()" prior to sending the packet. This would mean modifying the collectors struct to maintain the IP addresses of the remote collectors and triggering this function on Windows.
Currently, the IPFIX Collector is the only one that's relying on UDP based socket for Sending packets. Should the fix be scoped to the collectors_send() or keep it generic enough to trigger the SendArp() if it's an UDP based socket.