--- title: "Using DNS Traffic Control Health Monitors" canonical: "https://docs.infoblox.com/space/nios85/35385694/Using%20DNS%20Traffic%20Control%20Health%20Monitors" format: markdown --- 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: - HTTP health monitors. See *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[HTTP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. - ICMP health monitors. See *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ICMP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. - PDP health monitors. See *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[PDP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - SIP health monitors. See *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[SIP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. - SNMP health monitors. See *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[SNMP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - TCP health monitors. See *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[TCP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitor](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Certificates](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. 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. # > Macro (anchor) > Macro (anchor) 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*](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35446562). 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[HTTP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) > ⚠️ **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** **Count**: Enter 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** **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 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 checkbox 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitor](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Certificates](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - **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. > Macro (legacy-content)      5. Click **Next** and complete the following: > Macro (legacy-content) > Macro (legacy-content) > Macro (legacy-content) 6. Click **Next** to add extensible attributes. For information, see *[Using](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*. 7. To schedule the change, click **Next** or **Schedule****for****Later**. In the *Schedule**Change* 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. ## > Macro (anchor) 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. ## > Macro (anchor) 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: > Macro (legacy-content) # > Macro (anchor) > Macro (anchor) 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** **Count**: Enter 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*. 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. # > Macro (anchor) > Macro (anchor) 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** **Count**: Enter 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). - **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 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*.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. # > Macro (anchor) > Macro (anchor) 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** **Count**: Enter 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitor](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Certificates](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. - **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. > Macro (legacy-content) 5. Click **Next** to add extensible attributes. For information, see *[Using](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*. 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. # > Macro (anchor) > Macro (anchor) 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** **Count**: Enter 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) **SNMPv3****User**: Click **Select** or **Create** to specify an SNMPv3 user. For information about SNMPv3 users, see *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385484/Configuring+SNMP#ConfiguringSNMP-bookmark2870)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385484/Configuring+SNMP#ConfiguringSNMP-bookmark2870)*[SNMPv3](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385484/Configuring+SNMP#ConfiguringSNMP-bookmark2870)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385484/Configuring+SNMP#ConfiguringSNMP-bookmark2870)*[Users](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35385484/Configuring+SNMP#ConfiguringSNMP-bookmark2870)*. 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. - **Engine****ID**: 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: > Macro (legacy-content) **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. > Macro (legacy-content) 5. Click **Next** to add extensible attributes. For information, see *[Using](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*. 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. # > Macro (anchor) > Macro (anchor) 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** **Count**: Enter 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*. 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. # > Macro (anchor) > Macro (anchor) 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 checkbox next to the issuer and click the Delete icon to delete it. - Print the data or export it in .csv format. # > Macro (anchor) > Macro (anchor) 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Extensible](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*[Attributes](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35448912/Managing+Extensible+Attributes#bookmark868)*. 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35446174)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35446174)*[Tasks](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35446174)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35446174) 5. Save the configuration. # > Macro (anchor) > Macro (anchor) 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: - Define new health monitors. For more information, see the following sections: - *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[HTTP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ICMP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[PDP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[SIP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[SNMP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - *[Configuring](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[TCP](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - Edit existing health monitors. For more information, see *[Modifying](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - Manage health monitor certificates. For more information, see *[Managing](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitor](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Certificates](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*. - Delete existing health monitors. For more information, see *[Deleting](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Health](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[Monitors](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85draft/pages/26478505) - Click the Export icon to export the list of monitors to a .csv file. - Click the Print icon to print the list of monitors. - Use filters and the **Go** **to** function to narrow down the list. With the autocomplete feature, you can just enter the first few characters of an object name in the **Go** **to** field and select the monitor from the possible matches. Create a quick filter to save frequently used filter criteria. For information, see *[Using](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35417138/Finding+and+Restoring+Data#FindingandRestoringData-UsingQuickFilters)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35417138/Finding+and+Restoring+Data#FindingandRestoringData-UsingQuickFilters)*[Quick](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35417138/Finding+and+Restoring+Data#FindingandRestoringData-UsingQuickFilters)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35417138/Finding+and+Restoring+Data#FindingandRestoringData-UsingQuickFilters)*[Filters](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35417138/Finding+and+Restoring+Data#FindingandRestoringData-UsingQuickFilters)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35417138/Finding+and+Restoring+Data#FindingandRestoringData-UsingQuickFilters) # > Macro (anchor) > Macro (anchor) 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](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35444565/Scheduling+New+IPAM+DHCP+Objects+and+Associated+Port+Configurations#SchedulingNewIPAM/DHCPObjectsandAssociatedPortConfigurations-bookmark145)*[ ](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35444565/Scheduling+New+IPAM+DHCP+Objects+and+Associated+Port+Configurations#SchedulingNewIPAM/DHCPObjectsandAssociatedPortConfigurations-bookmark145)*[Deletions](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35444565/Scheduling+New+IPAM+DHCP+Objects+and+Associated+Port+Configurations#SchedulingNewIPAM/DHCPObjectsandAssociatedPortConfigurations-bookmark145)*[.](https://infoblox-docs.atlassian.net/wiki/spaces/nios85/pages/35444565/Scheduling+New+IPAM+DHCP+Objects+and+Associated+Port+Configurations#SchedulingNewIPAM/DHCPObjectsandAssociatedPortConfigurations-bookmark145)