Hello Joseph, you will find some new test and some answer to your previous message :
>> why is the client talking directly to the realserver? (It shouldn't be) ? Actually, the client can't talk directly to the realserver. No route between the 2, and no icmp_redirect. But, in the tcpdump, like you say, we saw sequence like the following : (it's another Tcpdump, I hope it will be readable) 16:07:44.198761 IP 192.168.1.209.5064 > 192.168.1.231.sip: SIP, length: 439 16:07:44.198768 IP 192.168.1.209.5064 > 192.168.2.2.sip: SIP, length: 439 16:07:44.200147 IP 192.168.2.2.sip > 192.168.1.209.5064: SIP, length: 325 16:07:44.200154 IP 192.168.1.231.sip > 192.168.1.209.5064: SIP, length: 325 with CIP = 192.168.1.209, VIP = 192.168.1.231, DIP = 192.168.2.231 and RIP = 192.168.2.2 when I rewrite this, my sequence is : CIP.5064 > VIP.sip CIP.5064 > RIP.sip RIP.sip > CIP.5064 VIP.sip > CIP.5064 which seems coherent with the HOWTO (5.10 - How LVS-NAT works) packet source dest incoming CIP:3456 VIP:23 inbound rewriting CIP:3456 RIP1:23 reply (routed to DIP) RIP1:23 CIP:3456 outbound rewriting VIP:23 CIP:3456 As needed, my director is the gateway for the realserver. >> Have you read the first line in the section on sip in the HOWTO? "SIP is NAT'ed. It's unlikely that SIP will work out of the box with LVS." "SIP is an all UDP protocol for VoIP (voice over IP) telephony. We haven't got it to work with LVS (yet)." Actually, what I'm trying to test is a round robin for an UDP datagram. I choose an OPTIONS in SIP. It's a very simple test, with the following call flow : client ----------------------------------------- Application Server OPTIONS -----------------------------> <-----------------------------------------------200 OK It's very similar to HTTP Options, with a message composed of an header and a body, in clear text. The response is also a clear text (and unique) message, with header and body (if needed). It work fine if the couple <IP><port> is different (2 options with different port will be correctly balanced between my server) : 17:00:08.997286 IP 192.168.1.209.5064 > 192.168.1.231.sip: SIP, length: 436 17:00:08.997294 IP 192.168.1.209.5064 > 192.168.2.3.sip: SIP, length: 436 17:00:08.998105 IP 192.168.2.3.sip > 192.168.1.209.5064: SIP, length: 322 17:00:08.998113 IP 192.168.1.231.sip > 192.168.1.209.5064: SIP, length: 322 17:00:09.009066 IP 192.168.1.209.5065 > 192.168.1.231.sip: SIP, length: 436 17:00:09.009073 IP 192.168.1.209.5065 > 192.168.2.2.sip: SIP, length: 436 17:00:09.010425 IP 192.168.2.2.sip > 192.168.1.209.5065: SIP, length: 322 17:00:09.010434 IP 192.168.1.231.sip > 192.168.1.209.5065: SIP, length: 322 but, if I use a load tester (SIPp), which will generated hundred of differents messages, the director will consider all messages from one source like one connection. I know I will have to make some change, but I was (naively) hoping a system similar too http, with a balancing between the realservers. I will need to create something which will balance based on called-id so . --- Pierrick GRASLAND ENSSAT - LSI 3 _______________________________________________ LinuxVirtualServer.org mailing list - [email protected] Send requests to [EMAIL PROTECTED] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
