5 Oct
2004
5 Oct
'04
6:43 a.m.
On Oct 05, 2004 at 00:31, Jiri Kuthan <jiri(a)iptel.org> wrote:
At 07:07 PM 10/4/2004, Michael Shuler wrote:
One small add-on :-)
You can force ser to put any address you want in Via and RR.. Use
advertised_address= virtual_ip (global config param), or
set_advertised_address(virtual_ip) (normal config commant).
Andrei
Thanks, I already read that. What I was concerned
about was more of if they
modified the SIP message differently before being sent.
I don't think there is a difference in the way these two functions modify
the outoging request. The difference is that the stateful forwarding needs
the reply to visit the same server. (Which should IMHO happen since it
prints its real IP in Via.)
For example I have
a layer 4 switch in front of 2 SER servers which runs a virtual IP of
198.88.216.84. The real servers ser0 and ser1 have IP's of 198.88.216.87
and 198.88.216.89 respectively. The problem I am having is that when I run
2 SER seems to get confused when a gateway starts talking to ser0 while a
client is talking to ser1.
So what happens is as follows?: a) ser0 forwards a request to a UAS
b) load balancer rewrites source IP to virtual IP c) UAS sends back to the
virtual IP (as in RFC3261, source transport address matters more than
content of Via does), d) LB forwards to SER1, e) SER0 times out.
I don't have sufficient information to judge if this is the problem you
are facing, I'm just speculating on what "SER gets confused" means.
If my wild guess are right, you should make sure that either:
- you use stateless forwarding -- there is then no proxy to time out. however,
all stateful features will be gone (see the URL I sent previously)
- you make sure that messages from SERs will not be translated. This may
be problematic too with replies to natted clients which are expecting
the replies to come back from the same IP (i.e., the virtual one).
To resolve these problem with the scheme you are using you would have
to differentiate between replies (to preserve virtual IP) and forward
requests (to preserve real IP). A way to do so would be an additional
hop (whose IP will not be translated for request forwarding) but I don't
think that one extra box in the chain is a good solution to dealing with load ;)
Another solution would be to force SER to use a speficic source address for
resending requests -- this address would not be SER0 and would not be
mangled by load balancer. There is however no such feature today. (We just
spoke with Andrei about it for some other reasons recently.)
Since the layer 4 switch is doing reverse NAT so
all traffic coming from the 2 ser servers appears as 198.88.216.84 this
causes a problem when they stick themselves in the Via line as their real IP
and not as 198.88.216.84.
I don't think that presence of the real IP in Via is exactly the problem.
On the contrary, the virtual IP in transport may be. If the other entities
used the real address then things would be just fine, I guess. I speculate
that the problem is that the load balancers dispatches different parts of
transaction to different servers.