TMS behind a load balancer, single-arm vs double-arm sNAT

[Matthieu LIENART]

I setup our TMS (14.2) using the Cisco redundancy procedure described in the administrators manual.

It is sitting behind a load balancer setup in a one-arm mode. So all traffic coming from the endpoints are sNAT with the IP address of the load balancer.

Although they register properly, I noticed that after a while some endpoints show up with the sNAT address on the TMS or their IP address will go blank.

I read some slightly related post in the community:

https://supportforums.cisco.com/thread/2171993

https://supportforums.cisco.com/thread/2154545

And also reading the documention the fact that the endpoint IP is sNAT to the load balancer IP seems to be the issue. But then my questions are

1. Is the single-arm load balancer mode supported by TMS ?
   
2. Do we have to change to double-arm load balancing mode ?
   
3. If we stay in single-arm balancer mode do I have to force all endpoints connection settings as "behind firewall" ? But if I do, the "Enforce Management Settings on Systems" will be ineffective.
   

[Martin Koch]

Did you check out:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/config_guide/Cisco_TMS__Redundancy_Deployment_Guide_13-2.pdf

I did not see a later document but that should be the same for tms14. There is a section regards load balancing.

I am not so sure about the communication in these cases and actually I am not

100% sure about what the impact of single and double arm mode are.

In general its two parts, its the request hitting the TMS and then if TMS can reach the endpoint

It would also use snmp&http to disover the system and I am not 100% sure if its would be the tms

which got the request which will take that action or if its triggered through the database and could

come from any of the active TMS.

If the TMS can not reach the system or if the request and the repsonse seem to come from different

addresses it seems to be automatically defined as "behind firewall".

I have a feeling that setting direct connection and behind firewall has sometimes a life on its own

as TMS tries to be more clever in some scenarios as the admin, ....

There also seem to be some bugs around behind firewall mode at the moment.

These were just some thoughts.

Hopefully you will get a better answer, anyhow, keep us posted how you went deploying it and

what you learned out of it.

Please remember to rate helpful responses and identify helpful or correct answers.

[Matthieu LIENART]

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.