[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: ARP match
From:       Jefferson Ogata <Jefferson.Ogata () noaa ! gov>
Date:       2002-01-31 7:10:05
[Download RAW message or body]

Victor wrote:
> > I see. I'm not familiar with the specific application you're using. Dumb
> > question: have you tried explicitly deleting the arp entry for the virtual
> IP
> > after the IP is assigned, using arp -d?
> 
> That wouldn't work. The next client would again send an arp request. One
> solution is to force a route but that means the router would have to be
> updated if director goes down and the secondary director takes over
> 
>          Client
>            |
>          Router
>            |
>            +--- Director1
>            |
>            +--- Director2
>            |
>        +---+---+
>        |       |
>       WEB1   WEB2
> 
> What happens is the client requests Virtual IP 192.168.1.110 (VIP). Director
> is supposed to respond. Director then rewrites the Hardware Address in the
> packet to WEB1 or WEB2 and send them the packet. WEB1 and WEB2 are listening
> on 192.168.1.110 VIP and when they get the packet from Director, respond to
> the client (Direct Routing setup). However, as you noticed, the Director is
> the one that supposed to respond when Client sends an ARP request on
> 192.168.1.110. Even though both Web1 and Web2 listen on the address, they
> should never reply to the arp request for that address. Director pings their
> real IP, gets their hardware addr, and then rewrites the packet to send to
> the VIP on Web1/2. Client however should never be able to get the arp reply.
> 
> The software is linuxvirtualserver.org. Really nice package. But the arp
> problem is one issue. Solaris seems to handle this great
> 
> ifconfig interface:blah -arp (example)
> 
> works like a charm on solaris. But not on linux (there is a lengthy
> explanation why on the lvs site). BSD has a slightly different way of
> defining aliases, so I can't do the solaris example. I was trying to find a
> way to do this on a bsd box. Thought an easy fix would be to filter arp
> requests. But ...

I'm not sure you understand what I'm saying. On WEB1, configure the
192.168.1.110 virtual IP so it will bind services to that IP. This will add an
implicit static arp to WEB1's arp table. Now use arp -d to delete that arp
entry. The host should no longer answer arps for 192.168.1.110. Do the same on
WEB2.

-- 
Jefferson Ogata <Jefferson.Ogata@noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt@noaa.gov>
[prev in list] [next in list] [prev in thread] [next in thread]