|
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
|
