10-02-2010 07:05 PM
Hi,
We are using a CSS11503 to loadbalance SIP traffic. There are no SIP proxies involved and we only want to loadbalance the SIP invites. The CSS is connected in a one-armed set-up. We do not want to NAT the source address so we have no group configuration.
We now have a problem because the loadbalancer is doing a PAT on the source port. The clients can't handle this, because the server is responding directly to the clients with the PATed address as destination port.
We have similar setups with the same CSS and very similar configuration, but the behaviour is different. For the other setup the CSS does not do a source PAT. The only difference is that we use a different client. The clients in our case are Acces Servers, on which E1s terminate.
Some of our clients reside in the same subnet as the servers, but as far as I can determine this should not be an issue, since we want the traffic to return directly and only use the CSS to loadbalance the invites. For us this has working before but with different client Access Servers.
The invites into the CSS are as follows:
UDP: CLIENT-IP:5060 -- VIP-IP:5060
The invites out of CSS towards server:
UDP: CLIENT-IP:31234 -- SERVER-IP:5060
Configuration:
!Active version: sg0820001
!*************************** GLOBAL ***************************
udp-ip-fragment enabled
flow-state 5060 udp flow-disable nat-enable
!************************** SERVICE **************************
service SERVER-1
protocol udp
port 5060
keepalive frequency 10
keepalive retryperiod 7
ip address "SERVER-IP"
active
!*************************** OWNER ***************************
owner SIP
content SIP-TRAFFIC
add service SERVER-1
protocol udp
port 5060
application sip
advanced-balance sip-call-id
vip address "VIP-IP"
active
Do you have any suggestions to turn of the source PAT?
Kind Regards,
Sander
10-04-2010 04:53 AM
I believe this was fixed with this bug :
CSCea28717 CSS is incorreclty nating a RSH source port
I have tested latest 8.x version and there is no source port pating.
You should consider an upgrade to a more recent version.
Gilles.
10-09-2010 08:29 PM
Hi Gilles,
Thanks for your time and answer. I have tested with version sg0820407, but I still experience this issue.
I am just wondering whether this is correct behaviour or not, perhaps this happens because of the "application sip" command.
I have tried configuring a group and do source IP nat, and then configure the command "portmap disable" under the group, but even then the source port is natted. But actually NATing the source IP is not a solution for us because it is causing problems on an application level. At one point the application hands the IP communicationover to the real ip addresses of the client and server.
Do you have any other ideas?
Regards,
Sander
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide