[Serusers] forward() and t_relay() differences

[Andrei Pelinescu-Onciul]

On Oct 05, 2004 at 00:31, Jiri Kuthan <jiri at 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