Hi Kacheong -
    Thank you for your response.   My quick summary is by changing the  
VIP address, I was able to get it to work.  My full answers are in-line.

On Dec 22, 2009, at 11:51 PM, Kacheong Poon wrote:

> On 12/23/09 02:23, Bill Hathaway wrote:
>> Hi, I have tried using ILB for the last few days and had some  
>> comments
>> and questions
>
>
> Thanks for trying.
>
>
>> Background
>> -----------------
>> I am using a lab environment that consists of the following machines:
>> x4150 - machine running OpenSolaris b129 with ILB ip=10.250.1.51
>>
>> web1 - web server ip=10.250.1.12 running apache on port 80
>> web2 - web server ip=10.250.1.13 running apache on port 80
>>
>> My current config is:
>> create-servergroup prodweb
>> add-server -s server=10.250.1.12:80 prodweb
>> add-server -s server=10.250.1.13:80 prodweb
>> create-healthcheck -n -h
>> hc-test=TCP,hc-timeout=5,hc-count=3,hc-interval=30 webhc
>> create-rule -e -i vip=10.250.1.51,port=80,protocol=tcp -m
>> lbalg=roundrobin,type=NAT,proxy-src=10.250.1.51-10.250.1.51 -h
>> hc-name=webhc,hc-port=ANY -t nat-timeout=120 -o servergroup=prodweb  
>> prodweb
>
>
> What is the netmask used in this environment?  I asked
> because it seems that the ILB box has only 1 interface,
> and that interface and the back end servers' interfaces
> are all in the same network.  I'm trying to understand
> the packet flow.  There is an issue in this setup as
> the proxy src address is the same as the ILB box's interface
> address (and VIP).  This will create conflicts with ILB
> box's own network traffic when ILB does NAT.
>

The netmask is 255.255.255.0 everywhere.

The http traffic works fine in this scenario (the TCP health checks  
work,
and I can send HTTP traffic to ILB and get appropriate round-robin'ed  
responses sent back to my client)

The ICMP traffic looks fine on the wire, but appears to get consumed  
by ILB.
I tried also running 'ping' while in the mode described earlier and  
could see the request/response
via snoop but I never saw a response get back to the 'ping' application.

I have attached is the snoop file and also placed a copy at: 
http://williamhathaway.com/downloads/ilb.snoop
in case anything strips the attachment.



> If you must use NAT in this set up, I'd suggest that you
> assign another address in the network as the proxy src.
> Suppose you pick 10.250.1.52.  Then you tell the ILB box
> to do proxy arp for that address by doing
>


I just did some more testing and what seemed to matter was changing  
the VIP address.
I could have the proxy address be the same as the ILB machine's  
primary address, or use secondary address (via the proxy arp method  
you showed below
or adding a virtual interface like ifconfig e1000g0 addif 10.250.1.52  
up).  As long as the VIP address wasn't the machine's primary address,
whether the proxy address was the same or not did not matter.

So essentially, the ICMP health check issue appears to happen when the  
VIP address is the same as the ILB's default outgoing address towards  
the back-end machines


> arp -s 10.250.1.52 <mac address> pub permanent
>
> where <mac address> is the ILB box interface's MAC addr.
> ILB will then use 10.250.1.52 to talk to the web servers.
> Note that you do not need to plumb an interface in the
> ILB box for to host 10.250.1.52.  The proxy ARP is enough
> to tell the web server where to send packets.
>
>
>> 3) It appears that the the default ICMP based health checks don't  
>> work
>>
>> When I use a health check of:
>> ilbadm create-healthcheck -h hc-test=tcp webhc (note no '-n' flag)
>> I can see the ICMP request and responses come back fine, but no upper
>> level health checks occur
>> and the servers are marked offline.
>
>
> Can you send us a (raw) network trace of the ICMP echo
> traffic?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ilb.snoop
Type: application/octet-stream
Size: 352 bytes
Desc: not available
URL: 
<http://mail.opensolaris.org/pipermail/ilb-dev/attachments/20091223/f5f9a901/attachment.obj>
-------------- next part --------------
>
>
> -- 
>
>                                               K. Poon.
>                                               kacheong.poon at sun.com
>

Reply via email to