14 Oct
2008
14 Oct
'08
11:33 p.m.
El Martes, 14 de Octubre de 2008, Martin Hoffmann escribió:
Iñaki Baz Castillo wrote:
Thanks for your comment. Please let me understand what you mean:
" the trick is to give them all the same IP and have the balancers work one
layer below"
Do you mean having various LB proxies all of them with same IP? If it, them
all the proxies behind the LB's will always see the same source IP, and will
reply to that IP, so the responses will arrive, at least, to one LB, am I
wrong?
Anyway, I don't understand the purpose and advantages of this method. If I
understood correctly, it could occur the following:
---------------------------------------------------------------------
proxy1 proxy2 proxy3 proxy4 proxy5
LB1 LB2 LB3
UA
---------------------------------------------------------------------
(all LB's have the same IP (1.1.1.1) in their interface with the proxies
behind).
- UA sends an INVITE to LB1.
- LB1 forwards the INVITE to proxy1.
- proxy1 sees 1.1.1.1 as source IP so add "received=1.1.1.1" to top Via (the
top Via can be Via added by LB1 or the Via added by UA if LB's don't add
Via).
- proxy1 replies to 1.1.1.1.
- Since that IP is shared by all the LB's the response arrives to LB3.
I suppose I didn't understant well since I see no benefict in this scenario.
Thanks a lot for your comment.
--
Iñaki Baz Castillo
2008/10/13 Jiri Kuthan <jiri(a)iptel.org>rg>:
We do have garden variety proxies behind our load balancers and they are
not aware of the presence of those load balancers. The trick is to give
them all the same IP and have the balancers work one layer below. From
the IP perspective, they are all one. Or something. The thing here is that actually a load-balancer
vendor is free to build
stuff his way -- he is not compelled to build a proxy or B2BUA and go
to some certification authority, he is supposed to build something that
load-balances well. I'm intimately aware of some load-balancers that
are close to being a kind of "transparent proxy", which is just fine:
it doesn't put itself in signaling and it handles routing by state
table.
Well, but what I mean is that the vendor needs, not just a custom LB
which doesn't add "Via" header, but also devices behind the LB (other
proxies or gateways) being not SIP compliant in points 18.2.1 & 18.2.2
of RFC3261.