Page tree

Contents

Health monitors determine the availability of DTC servers. You associate health monitors with pools. Every health monitor checks each server that is associated with the pool. Additionally, if you use multi-tier architecture, you can assign health monitors to individual IP addresses of a DTC server. You can use pre-defined health monitors or create custom monitors.
You can configure health monitors of the following types:

When you install the DNS Traffic Control license, each Grid member that is associated with an LBDN independently monitors the health of a server. The appliance resolves the server FQDN using the system resolver. The appliance performs a health check on both the IPv4 and IPv6 addresses. If the member does not have the same IP address types as the server or if the DNS name resolution for A or AAAA records fail to return results, the corresponding health check is considered to be a failure. The appliance caches the addresses that are resolved.
Note that monitoring is done by each Grid member that has a DNS Traffic Control license and is associated with a zone that has an LBDN record. This implies that firewall policies should be such that the member can reach every server it is monitoring. Otherwise, DNS Traffic Control cannot direct responses to servers that are not accessible.
By default, all monitor checks are initiated from the virtual interface of the member that is performing the health check. If the monitored server has only an IPv4 or IPv6 address, then the interface must have the corresponding IP address type.
You can configure the DTC monitor source to use the VIP, MGMT, LAN2 (WHERE), or ANY (normal routing) NIOS network interface, or one of the loopback additional IP addresses for the Grid member. You can configure the loopback IP address in the Grid member editor or network configuration.
The status of a DTC server for a specific pool depends upon the status of all the health monitors that are checking it. The status of a pool depends upon the status of all the servers in the pool. The status of an LBDN depends upon the status of all the pools assigned to the LBDN.
For the HTTPS and SIP monitor types, you can upload client certificates and associate them with the monitors to provide when connecting to a DTC server. For information, see Managing Health Monitor Certificates.
Vice versa, DTC servers provide certificates to authenticate themselves to the HTTPS and SIP monitors. You enable DTC server certificate validation when configuring HTTPS and SIP health monitors.

Configuring HTTP Health Monitors

An HTTP health monitor sends either an HTTP or HTTPS request to the server. The health monitor then examines the response received from the server. The validation is successful if the server returns a response with the expected result code.
The HTTP/HTTPS monitor can validate the response code and response content. The response content is checked only when the response code is valid. You can define regular expressions to use for the response content check. The supported regular expression syntax is POSIX Extended Regular Expression. For information, see Supported Expressions for Search Parameters.
If the DTC server certificate validation is enabled in the HTTPS health monitor, you can use the Server Name Indication (SNI) feature for remote DTC servers. SNI is an extension to the TLS computer networking protocol by which a client indicates which hostname it attempts to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number. Thus, multiple secure (HTTPS) websites (or any other service over TLS) can be served off the same IP address without all those sites having to use the same certificate.
After you configure an HTTP/S monitor, you can test its performance. See Testing HTTP Health Monitors.

Note

The HTTP health monitor does not support user name or password authentication.


To configure an HTTP health monitor, complete the following:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the arrow next to the Add icon and select HTTP Health Monitor.
  3. In the HTTP Health Monitor Wizard, complete the following:
    • Name: Enter a name for the HTTP monitor.
    • Interval (seconds): Enter the interval value in seconds. The interval value is measured from the end of the previous monitor cycle. The default value is five.
    • Timeout (seconds): Enter the timeout value in seconds. The monitor waits for the number of seconds that you specify after sending a response. If it does not receive a response within the number of seconds that you specify, then the appliance considers this check as failed. The monitor discards any response it receives after the timeout. The default value is 15.
    • Retry Up CountEnter a retry up count integer value. Retry up count is a value that determines how many valid responses or good health checks in a row must be received by the Grid member from the DTC server for setting the DTC server health status to green. When you specify a value, the appliance computes the duration for which health check must be performed based on the following:
      interval*retry up count
      For example, If the DTC server has had a red status for a long time because all the HTTP health checks have failed, and when the Grid receives the first good HTTP health check result, the health check counter is set as 1; however, the status of the DTC server is still retained as red. If you specify the Retry Up Count as 3 and the health check interval as 5, when three consecutive good health check results are received, the health check counter value becomes 3 and the DTC server health status now changes to green (3 good health check results in a row at an interval of 5 seconds each over a span of 3*5=15 seconds).
    • Retry Down CountEnter a retry down count integer value. It is the opposite of the retry up count. Retry down count is a value that determines how many red status health checks (server is unavailable) in a row must be collected by the Grid member from the DTC server to switch the health status from green to red.
      For example, for a Grid member whose connection to the DTC server is not stable and has its Retry Down Count set as 5, if the health check results received by the Grid member is in the sequence: green, red, red, red, green, then the health status of the DTC server will be retained as green.
      Note that red health status is set when the health monitor reaches the timeout value that is [health check interval + timeout] seconds without a valid response.

    • Comment: Enter information about the HTTP monitor.
  4. Click Next and complete the following:
    • Port: For HTTP, the appliance displays port number 80 by default. If you select Use HTTPS, the appliance displays 443 by default.
    • Use HTTPS: Select the check box to enable HTTPS. Specify any of the following options that become available when you select to use HTTPS:
      • Client Certificate: Optionally, you can select a certificate to use while opening the SSL connection for HTTPS. The monitor does not inspect or validate the server certificate, if any. For information about how to upload certificates, see Managing Health Monitor Certificates.
      • Ciphers: Specify a list of SSL ciphers in an OpenSSL format. You can specify cipher texts up to 1024 characters. The client certificate and cipher list are only used for HTTPS transport. The following example commands list some available ciphers:

Example 1:

$ openssl ciphers 'HIGH:!DES'
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:
DHE-DSS-CAMELLIA256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:AES256-SHA: CAMELLIA256-SHA:PSK-AES256-CBC-SHA:EDH-RSA-DES-CBC3-SHA:
EDH-DSS-DES-CBC3-SHA:ADH-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:
PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:DHE-RSA-AES128-SHA: DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:
ADH-AES128-SHA:ADH-CAMELLIA128-SHA:AES128-SHA:CAMELLIA128-SHA: PSK-AES128-CBC-SHA


Example 2:

$ openssl ciphers 'DEFAULT:!EDH+aRSA'
DHE-DSS-AES256-SHA:DHE-DSS-CAMELLIA256-SHA:AES256-SHA:CAMELLIA256-SHA:
PSK-AES256-CBC-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA: KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:DHE-DSS-AES128-SHA:DHE-DSS-SEED-SHA: DHE-DSS-CAMELLIA128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:
PSK-AES128-CBC-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5: EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5:
EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC2-CBC-SHA: EXP-KRB5-DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-RC4-MD5: EXP-KRB5-RC4-SHA:EXP-KRB5-RC4-MD5


Note

The DHE cipher list family ("Diffie-Hellman key agreement" plus "RSA authentication") could consume excessive CPU and is excluded from the defaults used by DNS Traffic Control health monitors. Although you can enable these ciphers by explicitly configuring them in the cipher list for HTTPS and SIP monitors, you should be aware that doing so will increase CPU usage. Since health monitoring in general does not require high security, Infoblox recommends that you enable these ciphers only for target servers that do not accept other types of ciphers.


    • Enable Certificate Validation: It is highly recommended to select this for the DTC server certificate to be validated by NIOS.
      • Enable SNI (Server Name Indication): Specify if you want to use SNI for the health monitor to connect to a specific DTC server by hostname. In addition, you should indicate an alternate SNI hostname in the DTC server editor.

     5. Click Next and complete the following:

    • HTTP Request: Specify the HTTP request to send the query from the client to the server. The appliance displays GET/ by default. You can specify an HTTP request up to 1024 characters. For more information, see Editing HTTP Request for HTTP Health Monitor.
    • Response Code Check: Specify in which case the response code from the server is valid:
      • Select Any response code is valid, if any response code from the server is required.
      • Select A valid response code, select equals or does not equal, and then specify a value. The default value is 200.
    • Response Content Check: Specify an option for checking the server response content:
      • Select Do not check the response content to not perform any content check.
      • Select Search for a string in the response content to search for a string in the response content. Then do the following:
        1. In the Search in drop-down list, choose where to perform the search for a string: in Both the header or body, Body, or Headers of the HTTP request. The search is limited to the first five kilobytes of the response.
        2. In the Regular Expression field, specify a regular expression that will be used to search for a string in the response content.
        3. In the drop-down list The content is valid if the regular expression is, select either found or not found. If you select found, the content is valid if it corresponds to the regular expression you specify. If you select not found, the content is valid if it does not correspond to the regular expression you specify.
      • Select Extract content from the response and compare it to a value to extract a certain part of the content and compare it to a specific string or integer value. Then do the following:
        1. In the Search in drop-down list, choose where to perform the search for a string: in Both the header or body, Body, or Headers of the HTTP request. Note that the search is limited to the first five kilobytes.
        2. In the Regular Expression field, specify a regular expression for content extraction. The regular expression can contain subexpressions that you may specify in the next step. If you set 1st as the value for Check content that is extracted using the <...> subexpression, the format of the Regular Expression must be expression(sub_expression1). The number of subexpressions must be same as or can be more than the value you specify for Check content that is extracted using the <...> subexpression. For example, the format must be expression(sub_expression1)(sub_expression2)when the Check content that is extracted using the <...> subexpression is set to 2nd, which means that there must be at least two subexpressions. 
        3. Select Check all extracted content to or select Check content that is extracted using the <...> subexpression and choose a number of the subexpression from the drop-down list. You can choose from the first to the eighth subexpression previously defined in the Regular Expression field.
        4. In the field The extracted content is valid if it is a, select the expected data type of the extracted content, string or integer, and select a comparison operator. Then specify a value in the text field.

6. Click Next to add extensible attributes. For information, see Using Extensible Attributes.

7. To schedule the change, click Next or ScheduleforLater. In the ScheduleChange panel, click Now to immediately execute this task. Or, click Later to schedule this task, and then specify a date, time, and time zone.

8. Save the configuration.

Editing HTTP Request for HTTP Health Monitor

You can specify a multi-line message and include HTTP headers in the request by using the HTTP Request field in the HTTP health monitor properties. The header lines of an HTTP request have the simple name: value syntax. The request headers are used to pass cookies, authentication, and provide information about the client to the server, etc.
The HTTP 1.1 contains a request line and a single host header:

Example 1:

GET / HTTP/1.1
Host: www.yoursite.com
Connection: close

Example 2:

GET /index.html HTTP/1.1
Host: www.example.com

Note that the lines are terminated with two chars

\r\n. The whole request terminates with an empty line "\r\n\r\n" character sequence. NIOS adds \r\n\r\n string if it is absent. You can request  GET / instead of "GET/index.html".
The host header differentiates between several HTTP servers that are running on a single IP address on the same port.
In HTTP 1.1, the server keeps the connection alive by default after the response is sent. You can disable the connection by adding a Connection: close header line to the request.

An HTTP 1.0 request may consist of a single line followed by the automatically added \r\n\r\n:

GET /index.html HTTP/1.0

Or in the most simple form:

GET / HTTP/1.0

The server closes the connection after the response has been sent. You can use Connection: Keep-Alive header to alter this behavior. The Content-Length header is important to determine the end of the response for keep-alive connections.
Apart from HTTP 1.0/1.1, NIOS also supports a request format known as HTTP 0.9:

GET /index.html

or

GET /

Normally, the response header consists of a response line, such as HTTP/1.1 200 OK or HTTP/1.0 400 Bad Request, followed by a couple of header lines, and then by an empty line which signals the end of the response header. With HTTP 0.9, the response immediately starts with the content of the requested file, which means that there is no HTTP return code for an HTTP 0.9 request.

Testing HTTP Health Monitors


After the HTTP health monitor is configured, you can test the configuration for a specific DTC server. Note that if you make changes to the HTTP health monitor settings, you must save the configuration so you can run the test.
To test the HTTP health monitor, do the following:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the Action icon  next to the HTTP health monitor name and select Edit.
  3. Select the Request/Response tab.
  4. Click Test HTTP Health Monitor.
  5. In the field Select a DTC Server or enter the IP address or domain name of an HTTP server, do one of the following to specify the server to test:
    • Click Select to select an existing DTC server.
    • Enter the IP address or host name of an HTTP server. The IP address can be IPv4 or IPv6.
  6. In the field Select a Grid member that is running DTC, select a DTC server on which the test will be run.
    If there is only one DTC server with the DTC license, it is selected by default. If there are several DTC servers with the license, the Grid Master is selected by default. If there is no Grid Master with the DTC license and there are several member servers with the license, click Select and choose a server.

     7. Click Test.

     8. In the result of the test, the following information is returned:

    • Test status
    • Status message

Configuring ICMP Health Monitors

An ICMP monitor sends an ICMP or ICMPv6 echo request to the IP address of the target server and expects an ICMP/ICMPv6 echo response. The ICMP monitor determines the health of a server by monitoring the response to an ICMP ping.

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the arrow next to the Add icon and select ICMP Health Monitor.
  3. In the ICMP Health Monitor Wizard, complete the following:
    • Name: Enter a name for the ICMP health monitor.
    • Interval (seconds): Enter the interval value in seconds. The health monitor runs only for the specified interval and it is measured from the end of the previous monitor cycle. The default value is five.
    • Timeout (seconds): Enter the timeout value in seconds. The monitor waits for the number of seconds that you specify after sending a response. If it does not receive a response within the number of seconds that you specify, then the appliance considers this check as failed. The monitor discards any response it receives after the timeout. The default value is 15.
    • Retry Up CountEnter a retry up count integer value. Retry up count is a value that determines how many valid responses or good health checks in a row must be received by the Grid member from the DTC server for setting the DTC server health status to green. When you specify a value, the appliance computes the duration for which health check must be performed based on the following:

      interval*retry up count
      For example, If the DTC server has had a red status for a long time because all the ICMP health checks have failed, and when the Grid receives the first good ICMP health check result, the health check counter is set as 1; however, the status of the DTC server is still retained as red. If you specify the Retry Up Count as 3 and the health check interval as 5,  when three consecutive good health check results are received, the health check counter value becomes 3 and the DTC server health status now changes to green (3 good health check results in a row at an interval of 5 seconds each over a span of 3*5=15 seconds).
    • Retry Down Count: Enter a retry down count integer value. It is the opposite of the retry up count. Retry down count is a value that determines how many red status health checks (server is unavailable) in a row must be collected by the Grid member from the DTC server to switch the health status from green to red.
      For example, for a Grid member whose connection to the DTC server is not stable and has its Retry Down Count set as 5, if the health check results received by the Grid member is in the sequence: green, red, red, red, green, then the health status of the DTC server will be retained as green.
      Note that red health status is set when the health monitor reaches the timeout value that is [health check interval + timeout] seconds without a valid response.

    • Comment: Enter information about the ICMP health monitor.

4. Click Next to add extensible attributes. For information, see Using Extensible Attributes.

5. To schedule the change, click Next or Schedule for Later. In the Schedule Change panel, select Now to immediately execute this task. Or select Later to schedule this task, and then specify a date, time, and time zone.

6. Save the configuration.

Configuring PDP Health Monitors

A PDP (Packet Data Protocol) monitor sends a standard  GTP ECHO request to the server. The GTP (GPRS Tunneling Protocol) echo message is used to ping the server. The connection is successful when the monitor receives an ECHO response from the server. If the server does not respond after a specified number of echo requests, the server is declared down by the monitor. You cannot modify the request or response.

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the arrow next to the Add icon and select PDP Health Monitor.
  3. In the PDP Health Monitor Wizard, complete the following:
    • Name: Enter a name for the PDP health monitor.
    • Interval (seconds): Enter the interval value in seconds. The health monitor runs only for the specified interval and it is measured from the end of the previous monitor cycle. The default value is five.
    • Timeout (seconds): Enter the timeout value in seconds. The monitor waits for the number of seconds that you specify after sending a response. If it does not receive a response within the number of seconds that you specify, then the appliance considers this check as failed. The monitor discards any response it receives after the timeout. The default value is 15.
    • Retry Up CountEnter a retry up count integer value. Retry up count is a value that determines how many valid responses or good health checks in a row must be received by the Grid member from the DTC server for setting the DTC server health status to green. When you specify a value, the appliance computes the duration for which health check must be performed based on the following:

      interval*retry up count
      For example, If the DTC server has had a red status for a long time because all the PDP health checks have failed, and when the Grid receives the first good PDP health check result, the health check counter is set as 1; however, the status of the DTC server is still retained as red. If you specify the Retry Up Count as 3 and the health check interval as 5,  when three consecutive good health check results are received, the health check counter value becomes 3 and the DTC server health status now changes to green (3 good health check results in a row at an interval of 5 seconds each over a span of 3*5=15 seconds).
    • RetryDownCount: Enter a retry down count integer value. It is the opposite of the retry up count. Retry down count is a value that determines how many red status health checks (server is unavailable) in a row must be collected by the Grid member from the DTC server to switch the health status from green to red.
      For example, for a Grid member whose connection to the DTC server is not stable and has its Retry Down Count set as 5, if the health check results received by the Grid member is in the sequence: green, red, red, red, green, then the health status of the DTC server will be retained as green.
      Note that red health status is set when the health monitor reaches the timeout value that is [health check interval + timeout] seconds without a valid response.

    • Port: Specify a port for PDP connection. The appliance displays 2123 by default. You can specify a value between zero and 65535.
    • Comment: Enter information about the PDP health monitor.

4. Click Next to add extensible attributes. For information, see Using Extensible Attributes.To schedule the change, click Next or Schedule for Later. In the Schedule Change panel, select Now to immediately execute this task. Or select Later to schedule this task, and then specify a date, time, and time zone.

5. Save the configuration.

Configuring SIP Health Monitors

A SIP monitor sends a standard SIP OPTIONS request to the server. You cannot modify this request. The monitor accepts only direct responses from the server and does not open alternate connections. The SIP monitor determines the health of the SIP server such as SIP proxies and session border controllers, and SIP gateways by issuing SIP OPTIONS to the server and examining the response provided by the server. The service is considered available if the response received from the server matches the expected response.
The SIP monitor does not support SCTP transport. It does not receive SIP connections. Responses are normally received over the same connection as the request was sent. The server does not attempt to open a new connection to send the response when it encounters an error message.

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the arrow next to the Add icon and select SIP Health Monitor.
  3. In the SIP Health Monitor Wizard, complete the following:
    • Name: Enter a name for the SIP health monitor.
    • Interval (seconds): Enter the interval value in seconds. The health monitor runs only for the specified interval and it is measured from the end of the previous monitor cycle. The default value is five.
    • Timeout (seconds): Enter the timeout value in seconds. The monitor waits for the number of seconds that you specify after sending a response. If it does not receive a response within the number of seconds that you specify, then the appliance considers this check as failed. The monitor discards any response it receives after the timeout. The default value is 15.
    • Retry Up CountEnter a retry up count integer value. Retry up count is a value that determines how many valid responses or good health checks in a row must be received by the Grid member from the DTC server for setting the DTC server health status to green. When you specify a value, the appliance computes the duration for which health check must be performed based on the following:

      interval*retry up count
      For example, If the DTC server has had a red status for a long time because all the SIP health checks have failed, and when the Grid receives the first good SIP health check result, the health check counter is set as 1; however, the status of the DTC server is still retained as red. If you specify the Retry Up Count as 3 and the health check interval as 5,  when three consecutive good health check results are received, the health check counter value becomes 3 and the DTC server health status now changes to green (3 good health check results in a row at an interval of 5 seconds each over a span of 3*5=15 seconds).
    • Retry Down Count: Enter a retry down count integer value. It is the opposite of the retry up count. Retry down count is a value that determines how many red status health checks (server is unavailable) in a row must be collected by the Grid member from the DTC server to switch the health status from green to red.
      For example, for a Grid member whose connection to the DTC server is not stable and has its Retry Down Count set as 5, if the health check results received by the Grid member is in the sequence: green, red, red, red, green, then the health status of the DTC server will be retained as green.
      Note that red health status is set when the health monitor reaches the timeout value that is [health check interval + timeout] seconds without a valid response.

    • Comment: Enter information about the SIP health monitor.
      When the DTC server is up, health checks are sent from the Infoblox member every number of seconds specified in the Interval field. When the DTC server is down, health checks are sent every number of seconds specified in the Interval field + the Timeout field. 
  4. Click Next and complete the following:
    • Expected Return Code: The response code expected from the server. Select a value from the drop-down list: any, equals, and does not equals. When you select equals or does not equals, the appliance displays 200 by default. You can specify a value between zero and 999.
    • Port: Specify a port for SIP connection. The appliance displays 5060 for TCP and UDP transport by default. When you select SIPS and TLS transport options, the appliance displays 5061 by default. You can specify a value between zero and 65535.
    • Transport: Select a transport option from the drop-down list: SIPS, TCP, TLS, and UDP. If you select SIPS or TLS, specify any of the following related options that become available
      • Client Certificate: Click Certificate to select a client certificate. Select a certificate from the dialog box. Click Clear to delete the certificate that you have uploaded. The monitor does not inspect or validate the server certificate, if any. For information about how to upload certificates, see Managing Health Monitor Certificates.
      • Ciphers: Specify a list of SSL ciphers in an OpenSSL format. You can specify text up to 1024 character.

The following example commands list some available ciphers:

Example 1:

$ openssl ciphers 'HIGH:!DES'
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:
DHE-DSS-CAMELLIA256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:AES256-SHA: CAMELLIA256-SHA:PSK-AES256-CBC-SHA:EDH-RSA-DES-CBC3-SHA:
EDH-DSS-DES-CBC3-SHA:ADH-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:
PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:DHE-RSA-AES128-SHA: DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:
ADH-AES128-SHA:ADH-CAMELLIA128-SHA:AES128-SHA:CAMELLIA128-SHA: PSK-AES128-CBC-SHA

Example 2:

$ openssl ciphers 'DEFAULT:!EDH+aRSA'
DHE-DSS-AES256-SHA:DHE-DSS-CAMELLIA256-SHA:AES256-SHA:CAMELLIA256-SHA:
PSK-AES256-CBC-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA: KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:DHE-DSS-AES128-SHA:DHE-DSS-SEED-SHA: DHE-DSS-CAMELLIA128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:
PSK-AES128-CBC-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5: EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5:
EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC2-CBC-SHA: EXP-KRB5-DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-RC4-MD5: EXP-KRB5-RC4-SHA:EXP-KRB5-RC4-MD5


Note

The DHE cipher list family ("Diffie-Hellman key agreement" plus "RSA authentication") could consume excessive CPU and is excluded from the defaults used by DNS Traffic Control health monitors. Although you can enable these ciphers by explicitly configuring them in the cipher list for HTTPS and SIP monitors, you should be aware that doing so will increase CPU usage. Since health monitoring in general does not require high security, Infoblox recommends that you enable these ciphers only for target servers that do not accept other types of ciphers.


    • Enable Certificate Validation: It is highly recommended to select this for the DTC server certificate to be validated by NIOS.

5. Click Next to add extensible attributes. For information, see Using Extensible Attributes.

6. To schedule the change, click Next or Schedule for Later. In the Schedule Change panel, select Now to immediately execute this task. Or select Later to schedule this task, and then specify a date, time, and time zone.

7. Save the configuration.

Configuring SNMP Health Monitors

An SNMP health monitor sends an SNMPv1, SNMPv2c, or SNMPv3 request to the monitored server. The SNMP agent in the managed server provides the data in the form of variables, and each variable is associated with an unique OID (object identifier). An OID is a dotted-decimal number that defines the location of the object in the universal MIB tree. You can manually enter up to 15 OIDs to be monitored by the SNMP monitor. The server is considered available if the response received from the server matches the expected result for all OIDs. If the server does not respond after a specified number of requests, the server is declared down by the monitor.

To configure an SNMP OID health monitor, complete the following:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the arrow next to the Add icon and select SNMP Health Monitor.
  3. In the SNMP Health Monitor Wizard, complete the following:
    • Name: Enter a name for the SNMP monitor.
    • Interval (seconds): Enter the interval value in seconds. The health monitor runs only for the specified interval and it is measured from the end of the previous monitor cycle. The default value is five.
    • Timeout (seconds): Enter the timeout value in seconds. The monitor waits for the number of seconds that you specify after sending a response. If it does not receive a response within the number of seconds that you specify, then the appliance considers this check failed. The monitor discards any responses it receives after the timeout. The default value is 15.
    • Retry Up CountEnter a retry up count integer value. Retry up count is a value that determines how many valid responses or good health checks in a row must be received by the Grid member from the DTC server for setting the DTC server health status to green. When you specify a value, the appliance computes the duration for which health check must be performed based on the following:

      interval*retry up count
      For example, If the DTC server has had a red status for a long time because all the SNMP health checks have failed, and when the Grid receives the first good SNMP health check result, the health check counter is set as 1; however, the status of the DTC server is still retained as red. If you specify the Retry Up Count as 3 and the health check interval as 5,  when three consecutive good health check results are received, the health check counter value becomes 3 and the DTC server health status now changes to green (3 good health check results in a row at an interval of 5 seconds each over a span of 3*5=15 seconds).
    • Retry Down Count: Enter a retry down count integer value. It is the opposite of the retry up count. Retry down count is a value that determines how many red status health checks (server is unavailable) in a row must be collected by the Grid member from the DTC server to switch the health status from green to red.
      For example, for a Grid member whose connection to the DTC server is not stable and has its Retry Down Count set as 5, if the health check results received by the Grid member is in the sequence: green, red, red, red, green, then the health status of the DTC server will be retained as green.
      Note that red health status is set when the health monitor reaches the timeout value that is [health check interval + timeout] seconds without a valid response.

    • Port: Specify a port for the SNMP connection. The appliance displays 161 by default. You can specify a value between zero and 65535.
    • Comment: Enter information about the SNMP health monitor.
  4. Click Next and complete the following:
    • Version: Select the SNMP version, v1, v2c, or v3. Note that the available options for versions v1 and v2c differ from those for v3 version.
    • (SNMPv1 and SNMPv2c only) Community: Enter the text string that the SNMP monitor must send along with the queries to the server for authentication. The community string is similar to a password and the server accepts queries only from the SNMP monitor that provide the correct community string. Note that this community string must match exactly what you enter in the management system. The default value is public.
    • (SNMPv3 only) SNMPv3User: Click Select or Create to specify an SNMPv3 user. For information about SNMPv3 users, see Configuring SNMPv3 Users.
      If you are modifying an already existing SNMPv3 health monitor in the SNMP Health Monitor editor, two additional optional fields become available:
      • Context: enter an arbitrary string.
      • EngineID: enter an arbitrary string that can contain from 10 to 64 hexadecimal digits (5 to 32 octet numbers).
    Click the Add icon above the Health Monitor SNMP OIDs table to add an SNMP OID entry. Complete the following:
    • OID: Specify the object identifier. An OID is a unique dotted-decimal number that identifies the location of the object in the MIB tree. For more information about OIDs, see SNMP MIB Hierarchy.
    • Type: Select either String or Integer from the drop-down list.

Note: If you use this SNMP monitor with the Ratio: Dynamic load balancing method, note that only integer OID type is supported for this method.

    • Operator: Select one of these operators from the drop-down list: Any, Equals, Larger or equals, Range, and Smaller or equals.
    • Value: If the operator is Equals, Larger or equals, or Smaller or equals, enter a value. If the operator is Range, enter the minimum and maximum values in the Min value and Max value fields respectively.
    • Comment: Enter information about the SNMP OID entry.
    • Click Add to add the SNMP OID to the table.

5. Click Next to add extensible attributes. For information, see Using Extensible Attributes.

6. To schedule the change, click Next or Schedule for Later. In the Schedule Change panel, select Now to immediately execute this task. Or select Later to schedule this task, and then specify a date, time, and time zone.

7. Save the configuration.

Configuring TCP Health Monitors

A TCP monitor opens a TCP connection to communicate between the appliance and server. The connection is successful only when the handshake is complete. A successfully opened connection will be immediately closed or reset.

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the arrow next to the Add icon and select TCP Health Monitor.
  3. In the TCP Health Monitor Wizard, complete the following:
    • Name: Enter a name for the TCP health monitor.
    • Interval (seconds): Enter the interval value in seconds. The health monitor runs only for the specified interval and it is measured from the end of the previous monitor cycle. The default value is five.
    • Timeout (seconds): Enter the timeout value in seconds. The monitor waits for the number of seconds that you specify after sending a response. If it does not receive a response within the number of seconds that you specify, then the appliance considers this check as failed. The monitor discards any response it receives after the timeout. The default value is 15.
    • Retry Up CountEnter a retry up count integer value. Retry up count is a value that determines how many valid responses or good health checks in a row must be received by the Grid member from the DTC server for setting the DTC server health status to green. When you specify a value, the appliance computes the duration for which health check must be performed based on the following:

      interval*retry up count
      For example, If the DTC server has had a red status for a long time because all the TCP health checks have failed, and when the Grid receives the first good TCP health check result, the health check counter is set as 1; however, the status of the DTC server is still retained as red. If you specify the Retry Up Count as 3 and the health check interval as 5,  when three consecutive good health check results are received, the health check counter value becomes 3 and the DTC server health status now changes to green (3 good health check results in a row at an interval of 5 seconds each over a span of 3*5=15 seconds).
    • Retry Down Count: Enter a retry down count integer value. It is the opposite of the retry up count. Retry down count is a value that determines how many red status health checks (server is unavailable) in a row must be collected by the Grid member from the DTC server to switch the health status from green to red.
      For example, for a Grid member whose connection to the DTC server is not stable and has its Retry Down Count set as 5, if the health check results received by the Grid member is in the sequence: green, red, red, red, green, then the health status of the DTC server will be retained as green.
      Note that red health status is set when the health monitor reaches the timeout value that is [health check interval + timeout] seconds without a valid response.

    • Port: Specify a port for TCP connection. You can specify a value between zero and 65535.
    • Comment: Enter information about the TCP health monitor.
  4. Click Next to add extensible attributes. For information, see Using Extensible Attributes.
  5. To schedule the change, click Next or Schedule for Later. In the Schedule Change panel, select Now to immediately execute this task. Or select Later to schedule this task, and then specify a date, time, and time zone.
  6. Save the configuration.

Managing Health Monitor Certificates

You can upload multiple certificates to the appliance and associate them with HTTP and SIP health monitors. The appliance supports certificates that are in PEM or PKCS#12 format only. A PEM file can contain more than one certificate. Note that the uploaded certificate must include both the client certificate and the private key. You can add, delete or view certificates.
To upload a health monitor certificate:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the Manage Health Monitor Certificates icon.
  3. In the Health Monitor Certificates window, click the Add icon.
  4. In the Upload window, click Select and navigate to the certificate you want to upload.
  5. Select the file and click Upload.

Grid Manager displays the following information in the Health Monitor Certificates window:

  • Issuer: The name of the trusted CA that issued the certificate.
  • Valid From: The date from which the certificate becomes valid.
  • Valid To: The date until which the certificate is valid.
  • Subject: The name of the certificate.

To upload a certificate from a web browser:

  1. Export a PEM file from a web browser.
  2. Generate a private key using the following command:
    — openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem
  3.  Copy the private key section out of mycert.pem and add it to the PEM file from the web browser.
  4.  Or add both the PEM and the private key together as PKCS#12.

You can also do the following in the Health Monitor Certificates window:

  • Click the check box next to the issuer and click the Delete icon to delete it.
  • Print the data or export it in .csv format.

Modifying Health Monitors

To modify a health monitor:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the Action icon next to the health monitor name, and select Edit from the menu.
  3. The Health Monitor editor contains the following tabs from which you can modify data:
    • General: This tab displays the health monitor Name, Comment, Interval, Timeout, Retry Up Count, and Retry Down Count fields. You can edit the values.
    • (HTTP, SIP, and SNMP health monitors) Protocol: This tab displays the protocol data that you can modify.
    • (HTTP/S health monitors only) Request/Response: This tab displays HTTP request and response check options for HTTP/S health monitors.
    • Extensible Attributes: Add and delete extensible attributes that are associated with the pool. You can also modify the values of extensible attributes. For information, see Using Extensible Attributes.

For information about modifying the details of specific monitors, see the corresponding sections above.

4. To schedule this task, click the Schedule icon at the top of the wizard. In the Schedule Change panel, select Later and enter a date, time, and time zone. The Schedule icon is green when there is a pending scheduled task. For information, see Scheduling Tasks.

5. Save the configuration.

Viewing Health Monitors

You can view health monitors that you have created. You can add new health monitors, delete existing monitors, modify health monitors, or associate extensible attributes to them. You can also upload and manage health monitor certificates.
To view health monitors:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. The Health Monitors Manager displays the following information:
    • Name: The name of the health monitor.
    • Type: The type of health monitor.
    • Comment: Displays information about the health monitor.
    • Interval: The interval value in seconds.
    • Timeout: The timeout value in seconds.
    • Retry Up Count: The retry up count specified for the respective health monitor.
    • Retry Down Count: The retry down count specified for the respective health monitor.
    • Port: The port number specified for the respective health monitor. Note that this is not valid for an ICMP monitor.
    • Site: Value that was entered for the respective health monitor.

You can do the following in the Health Monitors Manager:

Deleting Health Monitors

To delete a health monitor:

  1. From the Data Management tab, select the DNS tab -> Traffic Control tab, and then click Manage Health Monitors in the Toolbar.
  2. In the Health Monitors Manager, click the Action icon next to the health monitor name and select Delete from the menu.
  3. In the Delete Confirmation dialog box, click Yes to delete or No to cancel.

Click Schedule Deletion and in the Schedule Change panel, enter a date, time, and time zone to schedule deletion at a later date and time. For more information, see Scheduling Deletions.

This page has no comments.