CMS and F5 load balancer

[Randall Jackson]

Hello,

I am running CMS 2.4.2 in a cluster with two nodes running the Webbridge component. I have setup an F5 where the Guest account client URI points towards and then the F5 distributes the connection to one of the two WB's. I'm having some inconsistent behavior with the F5 where it keeps redirecting the client back to the sign in page after the client selects to join the meeting and at other times just says "reconnecting". I've also, on occasion been able to join a meeting successfully.

If I access either WB independently, a meeting can be joined successfully 100% of the time on either node. Seems to be an issue with the F5 configuration. Does anyone have a guide or any documentation specifically around what F5 configurations are needed to load balance across the WB components? 

Thanks.

[Nick Halbert-Lillyman]

I'm not sure if CMS web bridge is supposed to work behind a load balancer, but in any case this sounds similar to what happens when TURN isn't working properly.  Are these connections all on the internal LAN (and potentially not behind NAT) or are you using an internet-facing F5 to service internal CMS servers?

If this is an internet facing service and you have TURN configured, what are you using as your TURN server/s?  The TURN servers (whether they are CMS Edge or Expressway) I would imagine would have to actually be internet facing and not behind a load balancer.

[Randall Jackson]

Thanks for the reply Nick. The Scalable deployment guide does mention a load balancer is supported for the web bridge component. Specific text below. These clients are all internal. We do have a turnServer defined in CMS that points to an Expressway-E. The connection status is up.

What is odd to me is that by going to the web bridge directly, I can join the meeting every time, but going through the load balancer, it is very flaky. If TURN was being invoked, why would it only be invoked when the connection is made by a load balancer? I am leaning toward the load balancer, and the F5 team is looking into, however, it would be best if someone may be able to provide specific configuration examples that are known to work outside of what is mentioned below in the guide.

Use a load balancer (see note below) in front of the Meeting Servers. In this situation, point
the DNS A record at the load balancer rather than the individual Web Bridges.

Cisco Meeting Server Release 2.4 : Scalable and Resilient Meeting Server Deployments 109
Note: HAproxy, a high performance TCP/HTTP load balancer, has been tested and has
shown to work in 2 modes: source-ip load balancing, and cookie-insertion. Other load
balancers are available, and Cisco is not recommending HAproxy.

[Nick Halbert-Lillyman]

When connecting, are you goiing F5 > Expressway-E > CMS?  Or going F5 > CMS and just using Expressway-E as a TURN server?  If you just use the Expressway-E Web proxy function to CMS, does that work?

[Randall Jackson]

Internal clients 

Browser -> F5 -> Webbridge 

External clients

Browser -> EXP-E -> EXP-C -> web bridge

We have not completed all of the external configurations yet, still waiting on a couple firewall rules. However, the internal functionality shouldn't need to rely on the Expressway at all to be able to use the WebRTC client. Unless I may be missing something. We use the the URL directly to the web bridge server and the WebRTC client connects to meetings without issue. Put a load balancer in front of it, and there are intermittent issues. Thinking this is some type of persistent connection issue. 

[Nick Halbert-Lillyman]

I'm wondering if CMS might be trying to invoke TURN even for local connections... it could be worth deleting Expressways from the TURN server list and trying again just as a test.

In addition, are you using call bridge groups or just normal clustering?

[Georg Kehrer]

Hello,

I have setup also 2 CMS with WB and in front of a Loadbalancer but its from Kemp

I had also in the first step problem, but after that I change in the config on my virtual Service "Persistent Option" to source IP adress

https://support.kemptechnologies.com/hc/en-us/articles/202040855-Persistence

There are situations where Source IP persistence may be undesirable or even ineffective in properly keeping persistence. These situations include:
• When many (or all) users appear to come from a single IP address
• When a user switches IP addresses

The first case is often encountered when a significant number of user requests traverse a single proxy, and thus appear to come from a single IP. With Source IP persistence, this would mean that all of those users would appear as a single user.

https://support.kemptechnologies.com/hc/en-us/articles/202040875-Layer-7-persistence-methods

Maybe this Info can help.

this config works very well in my lab.

BR

Georg