LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] LVS-DR Director doesn't rewrite MAC nor send to RIP when

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] LVS-DR Director doesn't rewrite MAC nor send to RIP when CIP is not local to subnet
From: Jessie <lists@xxxxxxxx>
Date: Thu, 19 Jul 2007 11:50:17 -0700
Hi Graeme,


On Jul 19, 2007, at 11:32 AM, Graeme Fowler wrote:

> On Thu, 2007-07-19 at 11:11 -0700, Jessie wrote:
>> We are seeing a case where our directors are not rewriting the MAC
>> address when the client IP is not within the same subnet as the VIP.
>
> In that case I'd surmise that the realservers have not been sorted  
> from
> the point of view of "the ARP problem".

Ah perhaps I am mistaken. I thought the MS Loopback did not send out  
ARPs.
In either case, my linux RIPs which are not arping for the VIP (via  
sysctl settings)
have the same problem described.



> As you mention using a sniffer on a mirror port from a switch, I don't
> think the director is *seeing* the packets - they're going to the
> realserver(s) directly, at least some of the time.


>
> The fact that you're using Windows realservers, however, means this is
> unlikely. Can you run tcpdump directly on your director when  
> connections
> are coming in, and see what that tells you? Better to do it there than
> on an L2 device doing mirroring.
>


Believe it or not, the packet captures I included are from the director.

Another engineer has them on his laptop still :(

We used tcpdump -i eth0 -w file.pcap and then I later filtered out  
the cruft.

I also ran Wireshark on the RIP (Windows 2003) and don't see any  
traffic.
I attached Wireshark to the LAN adapter (not the MS Loopback) and  
filtered on
all traffic containing the directors MAC address:

display filter = eth.addr contains 8a:79
...no matches.

An obvious piece of Info I forgot to mention is the director can  
communicate to the RIP in all aspects.
If I send a ping from the director to the RIP I will see that in  
Wireshark (rip), and in tcpdump (director).


I also forgot to include the ipvsadm output:

IP Virtual Server version 1.2.1 (size=32768)
Prot LocalAddress:Port Scheduler Flags
   -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
      TCP  172.16.10.20:80 rr
   -> 172.16.10.11:80              Route   1      0          0


I cracked up the debug levels in /proc/sys/net/ipv4/vs/debug_level  
and cannot find any identifying traffic for the VIP



-Jessie


<Prev in Thread] Current Thread [Next in Thread>