Version 1.00000 –  8 October 2018

John Alvord, IBM Corporation

jalvord@us.ibm.com

Follow on twitter

Inspiration

In August 2014, the Database Health Checker began running at IBM ECUREP as an Analysis On Arrival task on each incoming hub and remote TEMS pdcollect. Since then TEMS Audit and Event History Audit reports have been added. The reports are very useful for by identifying known error condition and thus speeding ITM diagnosis of issues. Each of the tools can be run by any customer, but the AOA reports are not immediately visible. Any customer could ask for them but not being visible no one ever asks.  At the same time the reports have become more complex and challenging to digest.

With a recent change, the process has been extended to create a short list of critical issues which will automatically be added to the S/F Case or PMR as a short email text. That creates visibility for critical issues. This document presents one specific critical issue – port scanning of ITM processes.

Please note that the conditions identified may not be the issue the problem case was opened for. For example one recent case was a FTO hub TEMS switch to backup that was unexpected. After close study, the major issues was mal-configured agents including duplicate name cases, Virtual Hub Table Update floods and several other items. There are also rare cases where a report will be produced concerning an obsolete TEMS that is definitely installed but not in action use. In that case the report could be ignored – although uninstalling the TEMS would be a good idea.

Getting more information

If you are viewing this document as an customer working with IBM Support, you are welcome to request copies of the Analysis On Arrival reports if they are available. Be sure to mention the unpack directory from the AOA Critical Issue report.

TEMS Audit – temsaud.csv [any hub or remote TEMS]

Database Health Checker – datahealth.csv [any hub TEMS]

Event History Audit – eventaud.csv [any hub or remote TEMS]

There are cases when no report is generated. Sometimes that means there were no advisories. TEMS Audit is not produced when the relevant log files cannot be identified. Database Health checker is run but skipped if it appears to be a remote TEMS. Event History Audit and Database Health Checker are not run if there are errors detected in the table extract process.

Visit the links above to access the AOA programs if you want to run the AOA programs at your own schedule.

Port Scanning Testing

temsaud.crit: Definite Evidence of port scanning [$scantype] which can destabilize any ITM process including TEMS

Read the following development approved document for how ITM behaves in response to port scanning tests

APM: Port scanner usage and known limitations with IBM Tivoli Monitoring  

ITM will do its best to defend against such conditions, but that usually involves stopping existing connections and thus breaking communications and monitoring. Do not perform port scanning on ITM processes. The alternative is to be prepared to recycle ITM processes after such a test.

Warning When Not Port Scanning

There have been recent cases where “port scanning” type error messages are seen when there is some other condition. One example was when access to a TEMS was set up via a network proxy. The TEMS communications did not understand that sort of communications and rejected it. As time goes by we may see other issues which show as Port Scanning when another issue is happening.

Summary

This documents how to handle Port Scanning testing which can cause ITM processes to become unstable.

History

1.00000

Initial release

Note: 2018 – Home Grown Meyer Lemons