[ovs-dev] [PATCH v3] ofproto-collectors: Windows - Trigger an ARP request before sending IPFIX packet

Ben Pfaff blp at ovn.org
Thu May 24 17:09:35 UTC 2018


The MSDN entry is really unclear.  It says that it sends an ARP request,
if necessary.  I cannot find anything in the entry that says whether, if
it sends an ARP request, it waits for a reply.

However, this stackoverflow entry implies that it does wait for a reply:
https://stackoverflow.com/questions/43626184/any-way-to-change-the-behavior-of-synchronous-windows-api-sendarp

I think that's probably unacceptable because blocking the OVS main
thread will break lots of stuff.  If it's necessary to block for ARP
resolution, then I think it will have to happen in a thread dedicated to
that purpose.

On Thu, May 24, 2018 at 03:13:58PM +0000, Sairam Venugopal wrote:
> This is the snippet from MSDN:  https://msdn.microsoft.com/en-us/library/windows/desktop/aa366358(v=vs.85).aspx
> 
> The SendARP function is used to request the physical hardware address (sometimes referred to as the MAC address) that corresponds to a specified destination IPv4 address. If the information requested is not in the ARP table on the local computer, then the SendARP function will cause an ARP request to be sent to obtain the physical address. If the function is successful, the physical address that corresponds to the specified destination IPv4 address is returned in the array pointed to by the pMacAddr parameter.
> 
> I don't think this would end up blocking every other thread in OVS. I might've relayed this information incorrectly. There isn't an argument to specify timeout for the SendArp function.
> 
> Thanks,
> Sairam
> 
> On 5/23/18, 1:19 PM, "Ben Pfaff" <blp at ovn.org> wrote:
> 
>     On Fri, May 18, 2018 at 03:16:43PM -0700, Sairam Venugopal wrote:
>     > IPFIX templates and flow packets are silently dropped when a corresponding
>     > ARP entry is missing for the Collector. The fix is to explicitly trigger an
>     > ARP request before sending UDP packets to the collector.
>     > 
>     > Making changes in Windows to maintain the destination IP address as part
>     > of the Collector Structure. Since the SendARP is a blocking call, we do
>     > not necessarily need to check for a response before sending the IPFIX
>     > packets. Keeping the fix specific to Windows since this behavior cannot be
>     > reproduced in Linux.
>     
>     When you say that SendARP is a blocking call, do you mean that it sends
>     a packet and then waits for a response?  That will delay everything else
>     happening in the OVS main thread for an arbitrary amount of time.
>     Usually this is not acceptable.
>     
> 


More information about the dev mailing list