[ovs-dev] OvsIpHelper vs the ARP method

Samuel Ghinet sghinet at cloudbasesolutions.com
Fri Aug 22 01:10:09 UTC 2014


Hello Nithin,

Thanks for the clarifications!

Some notes:
- AFAIK, RARP is long since obsolete, so I don't know if we actually need to take it into account.
- When you say GARP, you mean the Gratuitous Address Resolution Protocol, right? not the Generic Attribute Registration Protocol.
If it's the former, then I don't see what problem could be with it.

on a:
The main advantage I see over IpHelper is that it's much less code.

b: I don't quite understand.
c: I'm not sure I agree. The main difference is you have an icmp6 packet instead of arp, and you keep a pair <ipv6, eth> instead of <ipv4, eth>.
The only problem would be that ipv6 addresses would mean more code.
d: the 'arp method' is used for tunneling only. If there is no PIF, then there is no tunneling => arp requests not sent.

[QUOTE]
But implementing our own ARP stack, maybe we can get rid of #3 by processing the ARP packets inline, but still we might need a thread to do cleanup of stale ARP entries. Otherwise, the data structure can bloat up.
[/QUOTE]
We could use a simple thread that, e.g., every 1h cleans up the stale entries.

[QUOTE]
While reviewing the cloudbase code, I inferred that the reason for implementing ARP stack was to be able to operate in the "AllowManagementOS = FALSE" mode.
[/QUOTE]
I'm not sure ARP method is the only way, for allow manag os = false.
Have you looked up GetIpNetTable2? It doesn't require a param to the physical interface.

Thanks,
Sam

________________________________________
From: Nithin Raju [nithin at vmware.com]
Sent: Wednesday, August 20, 2014 9:27 PM
To: Samuel Ghinet; Ben Pfaff
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] OvsIpHelper vs the ARP method

hi Samuel,
Thanks for resending.

I'm CCing Ben if he as more points.


At a high level, IP helper uses the host Hyper-V's ARP and IP routing stack functionality. At a high level it consists of the following parts:
1. Data structures the maintain the L2 and L3 cache.
2. Functionality to Query the L2 and L3.
   * We rely on the host's routing table to figure out the best interface to reach a destination. This gives the L3 source IP.
   * We rely on the host's ARP table to figure out the mapping between the L3 destination and its L2 address.
3. A thread since we cannot call into IP helper in DPC level as DISPATCH_LEVEL.

Some advantages of doing so are:
a. We don't have to implement an ARP stack as well as a routing table, and the related functionality of:
   * Populating the routing table
   * Listening to ARP, RARP and GARP messages and marking entries as stale etc. It is easer with IP helper since the host provides a nice callback.
b. It is easier to support multiple VTEPs in terms of IP routing stack (Even though OVS on Hyper-V does not support multiple VTEP today).
c. In the future when underly network (ie. VTEP IP) is an IPv6 address, it is complicated to implement and ND6 stack. I mean, Nd6 is a beast in itself compared to ARP.
d. We can work in a mode where there are no PIF bridges (though we don't support this mode today).

I am all for simplifying the IP helper code if you think of better ways of doing it, but changing the model to do ARP ourselves is a little non-scalable I think. Even with an ARP stack implementation, we cannot get away from doing #1 and #2.

But implementing our own ARP stack, maybe we can get rid of #3 by processing the ARP packets inline, but still we might need a thread to do cleanup of stale ARP entries. Otherwise, the data structure can bloat up.

While reviewing the cloudbase code, I inferred that the reason for implementing ARP stack was to be able to operate in the "AllowManagementOS = FALSE" mode. If this discussion is leading into that, then it is a much bigger discussion.

thanks,
Nithin


On Aug 20, 2014, at 11:09 AM, Samuel Ghinet <sghinet at cloudbasesolutions.com>
 wrote:

> Re-sent.
> ________________________________
> From: Samuel Ghinet
> Sent: Friday, August 08, 2014 8:57 PM
> To: dev at openvswitch.org
> Subject: OvsIpHelper vs the ARP method
>
> Hello guys,
>
> I wanted to ask you about this since a week or so.
>
> I have seen that you use the OvsIpHelper to find dest eth for a given target ip (to be used for destination hypervisor).
> I find the OvsIpHelper functionality quite complicated, and with calls to it in quite some places within the project (as in OvsConnectNic).
>
> The method we used in our implementation was:
> o) have an arp table (list of arp entries: mappings between eth address and ip address)
> o) have a lock (for snyc)
>
> And the operations:
> o) add / update an arp entry whenever you receive an ARP reply
> o) originate an ARP request whenever a tunnel is added (for a dest hyper-v), or when trying to out to tunneling port and you don't have the destination eth address.
>
> I had found the OvsIpHelper functionality quite intricate, as it requires the creation of a new thread, more lists and locks, it is a lot of code, an IOCTL for it, and also more dependencies in code. Also, quite any information that we'd want to gather about the physical NIC we can get via the nic OIDs or issuing OID requests.
>
> Could you please share with me some reasons you have for why you consider the OvsIpHelper approach better?
>
> Thanks!
> Samuel





More information about the dev mailing list