TMS behind a load balancer, single-arm vs double-arm sNAT
Thanks for your answer. I did read the documentation before and re-read it. Page 7 explains that the TMS servers IP addresses are NATted with a virtual IP address which is fine. But I can't find in this documentation a clear explanation (maybe it is because I am not a load balancer expert) of the one-arm vs double-arm settings.
In other words, it doesn’t' talk at all about the problem that in the one-arm setup, the IP address of the endpoint is NATted to the NLB IP address.
For traffic initiated from the endpoint to the TMS, the NLB keeps the information for each traffic of the real originator IP address. So that even if the TMS will reply by sending the answer to the NLB IP address, the NLB will then send the response back to the proper endpoint.
The problem is the other way. When the TMS initiate by itself a communication to the endpoint (to push a scheduled meeting, force configuration change made from the TMS...) the TMS will send the traffic to the NLB IP address which has no trace of such a communication and thus should not know where to route the traffic to.
The weird thing is that in our current one-arm NLB test config, sometimes the endpoint shows up with the correct IP address. Not only I am not sure of how the TMS can figure out the real IP address, but then when is means that TMS will bypass the NLB when initiating a communication to the endpoint, which I guess should be avoided.
So If my understanding is correct, the double-arm should be the configuration to use (but if I am correct the case in the above paragraph should not happen, so…), but again I am missing information of how the whole thing works and the documentation is not that detailed on that aspect.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...