Thanks for pointing this out. It might be better to simply add a static ARP entry when adding an IPFIX collector. This way we do not trigger this for every packet.
We are currently documenting this as a workaround for using IPFIX collectors on the same subnet as the Hyper-V host. This patch was an RFC to see if we could improve this mechanism. Calling SendArp in a separate thread means that we will somehow need to block the IPFIX packet send until ARP resolves. Otherwise, Windows might just continue to drop UDP packets. We can also check if there is a route to the Collector from the Host and drop the IPFIX packets, but this should've somehow been handled better by the Windows Sockets routine. Thanks, Sairam On 5/24/18, 10:09 AM, "Ben Pfaff" <[email protected]> wrote: 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://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_43626184_any-2Dway-2Dto-2Dchange-2Dthe-2Dbehavior-2Dof-2Dsynchronous-2Dwindows-2Dapi-2Dsendarp&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=8GsX0EVrqINs9sASEjOQ9sRGoswFi0dSVQQ7_SEBrfU&s=_TGWYeiurUno6rosPRGPjkeSNycWHjHfqs3e_sWVjL4&e= 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://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en-2Dus_library_windows_desktop_aa366358-28v-3Dvs.85-29.aspx&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z6vowHUOjP5ysP_g372c49Nqc1vEKqHKNBkR5Q5Z7uo&m=8GsX0EVrqINs9sASEjOQ9sRGoswFi0dSVQQ7_SEBrfU&s=XtI9PPWyM9PyrQpzlOEv9m1FFEKysRnXiuYlqImusn8&e= > > 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" <[email protected]> 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. > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
