2015-03-09 06:15 AM
i've just installed mctb 2.1.4 and i need to know how to it check network connection regards this mctb log
2015-03-06 15:58:54,458 [fas8020-1-conn-1] DEBUG com.netapp.rre.bautils.NetUtils - Successful connect to: 10.70.160.27:80
Thanks ins advance,
2015-03-09 06:29 AM
You should download and install the latest MCTB (version 2.4.0) from the NetApp support site:
That specific message comes from a successful TCP connect to the IP address and port shown in the message. Connecting to one of several TCP ports is one of the tests MCTB uses to check the status of the controllers. Note, this test is deferred in version 2.4.0, and only conducted of all other conditions suggest a possible CFOD situation. This greatly speeds up the normal polling cycle, reduces OS resource consumption, and avoids a TCP port exhaustion issue on Windows platforms.
Let me know if you have any additional questions.
2015-03-09 06:35 AM
thanks abrian, sure, i've already install the latest version 2.4.0, i've some network problem on my cutomer site, so, do you have some details on how the TCP connect is detect ? to help me find what the problem is. The controller is down and TCP connet is true ...
2015-03-09 06:59 AM
I've seen this before. In the previous case there was a caching proxy, load balancer, or NAT/PAT gateway that was responding on behalf of the controller, even though the controller was actually down. Naturally, you want to avoid having anything between MCTB and the controllers that might cause these tests to behave incorrectly.
You can confirm this isn't an MCTB issue (which it really can't be, since all MCTB is doing is a TCP connect) by going to the MCTB host and running "telnet <IP> <port>" to confirm that the port still connects outside of MCTB. You might also be able to isolate the problem by doing a traceroute (or tracert on Windows), and then doing the telnet test above from a host in each of the networks indicated by the route, until you get a connection timeout. The problem would be at the boundry of that network and the previous one (working from the MCTB host inwards, towards the controller).
I'm not sure if there is anything in the actual MCTB host OS itself that might cause this behavior, but you might want to do the telnet from another host in the same network or even segment as the MCTB host to start.
Hope this helps. Let me know if you have more questions.
2015-03-10 05:53 AM
Hi Capella and Abrian.
The root problem is located on the Firewall at the main site.
Checkpoint Smartdefense is enable and initiate the HTTP connexion even if the Netapp is down.
For the other ports, il's work fine, but Http check always return connected.
I have tested whith SSL=true in config.xml, but the check il always in port 80.
I ask the network team to stop Smartdefense but it seem to be problematic.
THe port 80 is necessary for tiebreaker to work ?
2015-03-10 06:04 AM
You can effectively remove port 80 checking by assigning that port to another acceptable port, such as one of the other two that are succeeding. Although this means that the test is redundent, it shouldn't be a problem, especially in MCTB version 2.4.0. Here's how to do that
This will change the web port to be the same as the CIFS port. So, you'll have two tests that execute against 445 and one against 2049 (NFS). Assuming both those ports are working normally, you should be ok.
Let me know if that helps.
2015-03-24 08:28 AM
on this system we only have NFS protocol, so CIFS is always close, i've start NDMP and change web port to 10000 value, but what are the properties we can define in the mctb.properties file
2015-03-24 08:51 AM
Those properties allow you to assign laternate ports to use for the controller connection test. If you want to use NDMP instead of CIFS, you can assign that port to CIFS_PORT. It will just test a TCP connect, so the actual protocol on the port doesn't matter. You can't change the name, but you can assign any value.