It appears as long as LMS is bound to the one single floating virtual IP addr in gatekeeper.cfg, it should work. Nonetheless I'm wondering if there's any caveat. Does LMS play nice with IPMP's outbound load spreading feature, if at all?
Solved! Go to Solution.
Thanks! Which version of LMS does this bug apply to? How do I obtain this patch, for LMS 3.0 or 3.1?
Do we need to disable IPMP's outbound load spreading feature (if it's possible)?
The bug applies to all versions of LMS 2.5 and higher, but it was found in LMS 2.6. The patch is available via the TAC. While I don't think load sharing would cause issues, we never tested LMS with IPMP, and the more features you use, the more potential there are for bugs.
Just thought of another question: If we have IPMP set up beforehand and assign DNS names to the IP addrs on the two physical interfaces, does LMS pick one of these two hostnames and stick it in files such as /opt/CSCOpx/campus/etc/cwsi/ANIServer.properties, which will require manually adjusting later to the DNS name for the virtual one? Is there a list of such files that'd be modified?
LMS will use the servers hostname (basically the output of the hostname command) everywhere a hostname is required. If this changes for ANY reason, you need to follow the hostname change procedures. ANIServer.properties does not need to be changed as part of that, but you can if you like.
I got the patch (ctm.jar) from TAC, but without any installation steps. It's normally fine, except there're eight ctm.jars in /opt/CSCOpx/. Which one(s) should this replace?
This is only for LMS 3.0.1, and will not work with any other version. The file is designed to replace /opt/CSCOpx/MDC/tomcat/webapps/cwhp/WEB-INF/lib/ctm.jar.
Got it, will do. I assume this is because the bug was filed only against 3.0.1. Do I need concrete evidence (such as a live 3.1 install) to prove the need of a patch?