Hello,
On Wed, Jun 07, 2000 at 05:13:22PM -0400, Jerome Etienne wrote:
> On Wed, Jun 07, 2000 at 11:53:49AM +0800, Andrey Savochkin wrote:
> > Keeping the policy decision in user-space is a wise solution.
> > But you may just set NOARP flag for the device and do all the stuff in
> > user-land merging your 'virtual MAC' logic with any ARP daemon.
>
> I am not sure i understand your suggestion. I made some tests, and if
> IFF_NOARP is set i dont receive any messages on a listening NETLINK_ARPD
> socket. I need 2 things:
Oh, I see. My quick thoughts appear to be wrong.
> - the kernel to keep a arp cache (no arp cache in the kernel implies
> a exchange with the userspace at each ip/other packet, so not a reasonable
> solution)
> - the kernel must not reply the native MAC when it receives a ARP request
> for a virtual ip.
>
> If there is a solution which doesnt require to modify the kernel, i dont
> see it. If your suggestion fits the needs, can you please elaborate
> to help me to understand.
>
> The other VRRP implementations just run everything in the kernel to solve
> this problem. My patch is 3 lines in net/ipv4/arp.c seemed a good solution
> when i wrote it. If anybody see a better one, please tell me...
Julian Anastasov also wanted some solution to block ARP replies for his
cluster project. Julian, I don't remember exactly your situation. May the
proposed patch solve some problems for you?
Best regards
Andrey V.
Savochkin
|