On Oct 05, 2004 at 00:31, Jiri Kuthan jiri@iptel.org wrote:
At 07:07 PM 10/4/2004, Michael Shuler wrote:
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.
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