Mailing List Archive: Linux Virtual Server: Users

[lvs-users] LVS-NAT - Problem with round robin

Index | Next | Previous | View Threaded

pierrick.grasland at gmail

Mar 14, 2008, 3:49 AM

Post #1 of 6 (558 views)
Permalink

[lvs-users] LVS-NAT - Problem with round robin

Hello,

I'm actually trying to setup my first LVS from scratch, so I'm currently
testing with NAT. (System for director : debian etch, kernel 2.6.18-5-k7,
with ipvsadm 1.24 for ipvs1.21 (standard package in debian repository))

After following instructions in the wiki and the howto, I obtain the
following configuration with one client, the director and one realserver :

*client
192.168.1.209
|
|
-------192.168.1.231 / 192.168.2.231 director
|
|
192.168.2.2
realserver*

After some trials (I had to handle ICMP_redirect, because I only have one
physical network, and one network card on my director), my setup is working
in this configuration for tcp on port 80, and a basic OPTIONS message for
SIP (on port 5060)

But now, I'm working on the next step, with 2 realservers :

*client
192.168.1.209
|
|
-------192.168.1.231 / 192.168.2.231 director
|
|
|
---------192.168.2.3 realserver2
|
192.168.2.2
realserver1*

So, based on my previous setup, I actually try the following configuration :

*director:~# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
UDP 192.168.1.231:sip rr
-> 192.168.2.2:sip Masq 1 0 0
-> 192.168.2.3:sip Masq 1 0 0
TCP 192.168.1.231:sip rr
-> 192.168.2.2:sip Masq 1 0 0
-> 192.168.2.3:sip Masq 1 0 0
TCP 192.168.1.231:www wlc
-> 192.168.2.2:www Masq 1 0 0*

Just a classic round robin, without weight, for UDP on 5060 (no persistence,
nothing particular, just a SEND / REPLY test with an OPTIONS for SIP).

But, when I test this configuration, I only reach one realserver, and no
message are scheduled to the other

*Tcpdump | grep sip :*

*
director:~# tcpdump | grep sip
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:39:26.957524 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:26.957545 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:26.960106 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:26.960126 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:28.961514 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:28.961538 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:28.963505 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:28.963523 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:30.963117 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:30.963127 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:30.965067 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:30.965077 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:32.964288 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:32.964300 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:32.966314 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:32.966329 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:34.965530 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:34.965539 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:34.967514 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:34.967529 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:36.966793 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:36.966810 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:36.968854 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:36.968869 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:38.968410 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:38.968419 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:38.970371 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:38.970379 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:40.970842 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:40.970854 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:40.972820 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:40.972834 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:42.972524 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:42.972532 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:42.975148 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:42.975156 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
11:39:44.974240 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
11:39:44.974253 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
11:39:44.976160 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
11:39:44.976173 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
193 packets captured
193 packets received by filter
0 packets dropped by kernel*

When I check the log for my service, I have confirmation of the tcpdump :
realserver1 get all, realserver2 get nothing.

So, if someone have an hint in order to resolve this problem, thanks.

PS : I also try with lc, but it's the same, only one get traffic)

--
Grasland Pierrick
ENSSAT - LSI 3
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

jmack at wm7d

Mar 14, 2008, 6:39 AM

Post #2 of 6 (479 views)
Permalink

Re: [lvs-users] LVS-NAT - Problem with round robin [In reply to]

On Fri, 14 Mar 2008, pierrick grasland wrote:

>
> After some trials (I had to handle ICMP_redirect, because I only have one
> physical network, and one network card on my director), my setup is working
> in this configuration for tcp on port 80, and a basic OPTIONS message for
> SIP (on port 5060)
>

> 11:39:26.957524 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:26.957545 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302

why is the client talking directly to the realserver? (It
shouldn't be)

Have you read the first line in the section on sip in the
HOWTO?

Joe

--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!

_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

pierrick.grasland at gmail

Mar 14, 2008, 7:05 AM

Post #3 of 6 (476 views)
Permalink

Re: [lvs-users] LVS-NAT - Problem with round robin [In reply to]

Hello,

with further search, I think I have find my problem :

I actually use UDP connections for my test, during a short time scale.

In the HOWTO ( 5.18 - Scheduling TCP/UDP), I found the following definition
:

* Here's the official LVS definition of a UDP "connection" *

* Wensong Zhang wensong (at) iinchina (dot) net 2000-04-26 *

* For UDP datagrams, we create entries for state with the timeout of
IP_MASQ_S_UDP (5*60*HZ) by default. Consequently all UDP datagrams from the
same source to the same destination will be sent to the same realserver.
Therefore, we call data communication between a client's socket and a
server's socket a "connection", for both no TCP and UDP.*

Does someone know if some solutions exists in order to remove / decrease
this timeout ? I didn't find any references to this timeout in another place
(maybe I'm using wrong keyword)

On Fri, Mar 14, 2008 at 11:49 AM, pierrick grasland <
pierrick.grasland [at] gmail> wrote:

> Hello,
>
> I'm actually trying to setup my first LVS from scratch, so I'm currently
> testing with NAT. (System for director : debian etch, kernel 2.6.18-5-k7,
> with ipvsadm 1.24 for ipvs1.21 (standard package in debian repository))
>
> After following instructions in the wiki and the howto, I obtain the
> following configuration with one client, the director and one realserver :
>
> *client
> 192.168.1.209
> |
> |
> -------192.168.1.231 / 192.168.2.231 director
> |
> |
> 192.168.2.2
> realserver*
>
> After some trials (I had to handle ICMP_redirect, because I only have one
> physical network, and one network card on my director), my setup is working
> in this configuration for tcp on port 80, and a basic OPTIONS message for
> SIP (on port 5060)
>
> But now, I'm working on the next step, with 2 realservers :
>
> *client
> 192.168.1.209
> |
> |
> -------192.168.1.231 / 192.168.2.231 director
> |
> |
> |
> ---------192.168.2.3 realserver2
> |
> 192.168.2.2
> realserver1*
>
> So, based on my previous setup, I actually try the following configuration
> :
>
> *director:~# ipvsadm
> IP Virtual Server version 1.2.1 (size=4096)
> Prot LocalAddress:Port Scheduler Flags
> -> RemoteAddress:Port Forward Weight ActiveConn InActConn
> UDP 192.168.1.231:sip rr
> -> 192.168.2.2:sip Masq 1 0 0
> -> 192.168.2.3:sip Masq 1 0 0
> TCP 192.168.1.231:sip rr
> -> 192.168.2.2:sip Masq 1 0 0
> -> 192.168.2.3:sip Masq 1 0 0
> TCP 192.168.1.231:www wlc
> -> 192.168.2.2:www Masq 1 0 0*
>
> Just a classic round robin, without weight, for UDP on 5060 (no
> persistence, nothing particular, just a SEND / REPLY test with an OPTIONS
> for SIP).
>
> But, when I test this configuration, I only reach one realserver, and no
> message are scheduled to the other
>
> *Tcpdump | grep sip :*
>
> *
> director:~# tcpdump | grep sip
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:39:26.957524 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:26.957545 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:26.960106 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:26.960126 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:28.961514 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:28.961538 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:28.963505 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:28.963523 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:30.963117 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:30.963127 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:30.965067 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:30.965077 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:32.964288 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:32.964300 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:32.966314 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:32.966329 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:34.965530 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:34.965539 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:34.967514 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:34.967529 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:36.966793 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:36.966810 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:36.968854 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:36.968869 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:38.968410 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:38.968419 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:38.970371 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:38.970379 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:40.970842 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:40.970854 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:40.972820 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:40.972834 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:42.972524 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:42.972532 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:42.975148 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:42.975156 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:44.974240 IP 192.168.1.209.sip > 192.168.1.231.sip: SIP, length: 302
> 11:39:44.974253 IP 192.168.1.209.sip > 192.168.2.2.sip: SIP, length: 302
> 11:39:44.976160 IP 192.168.2.2.sip > 192.168.1.209.sip: SIP, length: 326
> 11:39:44.976173 IP 192.168.1.231.sip > 192.168.1.209.sip: SIP, length: 326
> 193 packets captured
> 193 packets received by filter
> 0 packets dropped by kernel*
>
>
> When I check the log for my service, I have confirmation of the tcpdump :
> realserver1 get all, realserver2 get nothing.
>
> So, if someone have an hint in order to resolve this problem, thanks.
>
> PS : I also try with lc, but it's the same, only one get traffic)
>
>
> --
> Grasland Pierrick
> ENSSAT - LSI 3

--
Grasland Pierrick
ENSSAT - LSI 3
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

pierrick.grasland at gmail

Mar 14, 2008, 9:16 AM

Post #4 of 6 (479 views)
Permalink

Re: [lvs-users] LVS-NAT - Problem with round robin [In reply to]

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 - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

jmack at wm7d

Mar 14, 2008, 11:17 AM

Post #5 of 6 (475 views)
Permalink

Re: [lvs-users] LVS-NAT - Problem with round robin [In reply to]

On Fri, 14 Mar 2008, pierrick grasland wrote:

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

> with CIP = 192.168.1.209, VIP = 192.168.1.231, DIP = 192.168.2.231 and
> RIP = 192.168.2.2

makes it easier for me.

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

yes. I didn't know which machine/ethernet card was running
the tcpdump, so your packets are OK, and I was wrong.

> 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

OK. don't know it, but I'm following along.

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

I'm lost. "is different" from what? What makes it work/not
work?

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

is this good/bad? Why?

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

sip with all its ports is going to be difficult to
loadbalance. You probably will need something like the
ip_vs_ftp module.

Joe

--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!

_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

pierrick.grasland at gmail

Mar 15, 2008, 1:24 AM

Post #6 of 6 (471 views)
Permalink

Re: [lvs-users] LVS-NAT - Problem with round robin [In reply to]

Hello,

> > 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) :
>
> I'm lost. "is different" from what? What makes it work/not
> work?

When IP:port1 and IP:port2, the identifier is different for LVS, and I
will see 2 connections in ipvsadm

> > 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.
>
> is this good/bad? Why?
>

For me, it is good if I have a lot of client, like this configuration :

client1 |
...........|--------------director ---------realserver 1 to n
clientn |

In this case, it will work fine for me, because I use SIP proxy or
something very similar.

But, one case is used when we create a IMS/SIP network :

client1 --- clientn
...........|
IMS box which will receive call, but forward them in one udp socket
(or one tcp socket)
...........|
director (only one connection in basic setup so)
...........|
-----------------------------------
realserver1...............realservern

In this case, I will not loadbalance correctly.

So, It's my turn to work ;)

PS : when I was searching, I found some references to a SIP adaptation
for LVS. I know it's not complete, but can someone link me to the last
version ?

Thanks for your help,

--
Grasland Pierrick
ENSSAT - LSI 3

_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users [at] LinuxVirtualServer
Send requests to lvs-users-request [at] LinuxVirtualServer
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads