Configure specific nodes

[This is the Context-Sensitive Help topic for the Specific Node Settings tab on the Communication Configuration form.]

Configuring communication protocols for specific devices is optional unless you want NNMi to monitor hypervisor devices that are authorized using Self-Signed Certificates - which requires configuration for each node (NNMi Advanced).

NNMi supports the following ways to configure communication protocol for devices:

• Use the Specific Node Settings tab from the Communication Configuration form.

  Use the Specific Node Settings tab when you want to provide exceptions to the Communication Region configurations rather than to directly manage settings for a large numbers of nodes. The Specific Node Settings tab enables you to fine tune communication protocol usage and settings for a particular device within your environment. For example, provide settings for your most important devices, or disable communication with the least important devices. 

  When you leave a field blank, NNMi uses the next applicable configuration setting for that field in the following order:

  • The value configured for a Region that includes this device. If multiple Region definitions include this device (for example, buildings, floors within those buildings, or work groups within a particular floor), the first match applies (the matching region with the lowest Ordering number) .
  • The default value for this field.

  You can use the Specific Node Settings tab to configure Communication Protocol for a Node before it is discovered. During discovery, NNMi uses the Node host name to match the Specific Node Communication Configuration settings. If the Node host name changes, the Specific Node Communication Configuration settings no longer match and NNMi uses the settings configured in the Communication Configuration Regions tab.

• Use the Locked SNMP Agent Settings Mode to directly manage communications parameters.
  

  Use the SNMP Agent Form Mode attribute when you want to directly manage Communication Configuration settings for one or more nodes.

  Set Mode to Locked when you want full control over the communication configuration settings. When the SNMP Agent Settings Mode is set to Locked, NNMi ignores the Communication Configuration Settings and uses the SNMP Agent values configured in the SNMP Agent Form.

  Using Locked Mode is only available after the Node is discovered. The SNMP Agent Settings will be used for the Node even if the Node host name changes.

  Use the SNMP Agent Form or nnmcommunication.ovpl to set the Mode value and any additional SNMP Agent Settings for one or more nodes.

  If you change the SNMP Agent Form configuration settings, note the following:

  • If you do not set a node's SNMP Agent Form Settings Mode to Locked, your changes might be subsequently overwritten by the Communication Configuration settings.
  • Editing the SNMP Agent Settings using the SNMP Agent Form is most useful after you have used nnmcommunciation.ovpl to set configuration values for a large number of nodes and then need to change the one or more SNMP Agent Settings for a small number of nodes.
  • You can also use the listSnmpAgentSettings and updateSnmpAgentSettings options to nnmconfiguration.ovpl to view the current SNMP Agent Settings for a specified node.

• Load Communication Settings from a File

  NNMi enables you to bulk load or update any of the Communication Configuration or SNMP Agent Settings that you can configure when using nnmcommunication.ovpl.

  Specific Node Settings form

  [This is the Context-Sensitive Help topic for the Communication Node form.]

  Create specific node settings to control the way NNMi monitors your most important devices or least important devices.  

  Tip If no value is provided for an attribute in the Communication Node form, NNMi uses the applicable Region settings and if none match, NNMi uses the default settings.

  To configure communication protocol settings for a specific node:

  1. Access the Specific Node Settings form.

     1. From the workspace navigation panel, select the  Configuration workspace.
     2. Select the Communication Configuration.
     3. Navigate to the Specific Node Settings tab.

     4. Do one of the following:

        • To establish settings for a node, click the New icon, and continue.
        • To edit settings for a node, select a row, click the Open icons, and continue.
        • To delete settings for a node, select a row and click the Delete icon.

  2. Provide the communication protocol settings for the node.

  3. Optional. Make additional configuration choices. Click here for a list of choices .
  4. Click  Save and Close to return to the Communication Configuration form.
  5. Click  Save and Close to apply your changes.

  Basic Settings for this Device

  Attribute	Description
  Target Hostname	Enter the fully-qualified hostname as registered in your Domain Name System (DNS). The Hostname attribute value from the Node form of the discovered node must match what is entered here. Case-insensitive, NNMi automatically converts the hostname to all lowercase on the Node form. NNMi follows a set of rules to dynamically generate the value stored in the NNMi database for each Node's Hostname. Click here for details. If the Node supports SNMP, NNMi requests the Hostname using the IP Address of the associated SNMP agent (the Management Address attribute value on the Node form). When the NNMi administrator chooses Enable SNMP Address Rediscovery  in the Communication Configuration: If the SNMP Agent does not respond, NNMi checks for another Management Address to request the Hostname, and the Hostname could change. If the SNMP Agent associated with the node changes, the Management Address and Hostname could change. When the NNMi administrator disables Enable SNMP Address Rediscovery  in the Communication Configuration, when the current management address (SNMP agent) becomes unreachable, NNMi does not check for other potential management addresses. If the Node does not support SNMP, no Management Address is available. NNMi requests a Hostname starting with the lowest IP Address associated with the node (a Discovery Seed value or an IP address value gathered from a neighboring device). NNMi uses the first Hostname provided. The Hostname might change during a future discovery cycle. NNMi administrators can use NNMi property file settings to change the way NNMi determines Hostname values: nms-topology.properties file settings: If DNS is the source of the Node's Hostname, there are three choices. By default NNMi uses the exact Hostname from your network configuration. It is possible to change NNMi behavior to convert Hostnames to all uppercase or all lowercase. nms-disco.properties file settings: The Hostname is either requested from the Node's lowest loopback interface IP address that resolves to a Hostname or requested from the Node's designated Management Address (SNMP agent address). With either choice, when no IP address resolves to a Hostname, the IP address itself becomes the Hostname.
  Preferred Management Address	Do one of the following: Specify the address you want NNMi to use for SNMP communications with this device. If you enter an invalid or unreachable address, the device is not discovered or monitored. Leave this attribute empty. NNMi dynamically selects the management address, based on responses from the device's SNMP agent and your choices in the default SNMP, Management Address, and ICMP settings.  The NNMi administrator can over-ride this setting.
  Description	Optional. Provide a description for this configuration that would be useful for communication purposes within your team. Type a maximum of 255 characters. Alpha-numeric, spaces, and special characters (~ ! @ # $ % ^ & * ( ) _+-) are permitted.

  SNMP Settings for this Device

  Attribute	Description
  Enable SNMP Communication	If  enabled, the Discovery Process and State Poller Service generate network traffic with SNMP protocol to discover and monitor this device. Your choice might be overridden if Monitoring Configuration settings disable SNMP usage for the State Poller Service. If  disabled, NNMi does not generate any SNMP traffic to this device. Caution With no SNMP data, Spiral Discovery interprets each IP Address as a separate node, Causal Engine calculates Status based only on IP address State, previously discovered Interfaces show a State attribute value of "Not Polled" and a Status attribute value of "No Status" with the Interface map-symbol color set to beige, and no new Interfaces are discovered.
  Enable SNMP Address Rediscovery	The NNMi administrator can over-ride this setting. If  enabled, NNMi automatically identifies which management address (SNMP agent) to use for each device. If the initially configured address becomes unreachable, NNMi automatically locates another address, if possible, and changes the management address attribute value. Click here for more information. When NNMi first discovers a node, the seed address (provided by the NNMi administrator) or discovered address (for non-seeded nodes) becomes the initial address used for SNMP communication. After NNMi builds an inventory of all IP addresses associated with the node, NNMi follows a set of rules to determine which address is the best choice for each node's Management Address: (NNMi Advanced) The NNMi administrator specifies whether NNMi prefers IPv4 addresses, IPv6 addresses, or dual-stack (both) when selecting the Management Address. NNMi ignores the following addresses when determining which Management Address is most appropriate: Any address of an administratively-down interface. Any address that is virtual (for example, VRRP). Any IPv4 Anycast Rendezvous Point IP Address or IPv6 Anycast address. Any address in the reserved loopback network range. IPv4 uses 127/24 (127.*.*.*) and IPv6 uses ::1. Any IPv6 link-local address. If the NNMi Administrator chooses Enable SNMP Address Rediscovery  in Communication Configuration, NNMi prefers the last-known Management Address (if any). If the Management Address does not respond and the NNMi Administrator specifies Enable SNMP Address Rediscovery in Communication Configuration, NNMi uses the Communication Configuration settings for Management Address Selection. The NNMi Administrator chooses the order in which NNMi checks the following: Seed IP / Management IP - If the NNMi Administrator configures a Seed, NNMi uses the Seed address (either a specified IP address or the DNS address associated with a specified hostname) only during initial Discovery. NNMi then requests the current Management Address (the address from which the node's SNMP Agent responds) and uses that IP address for all communication after initial discovery. Lowest Loopback - If a node supports multiple loopback address, NNMi queries each loopback addresses, starting with the lowest number. NNMi uses the loopback address with the lowest number from which the SNMP agent responds (for example, 10.16.42.197 is a lower number than 10.16.197.42). Highest Loopback - If a node supports multiple loopback address, NNMi queries each loopback addresses, starting with the highest number. NNMi uses the loopback address with the highest number from which the SNMP agent responds. Interface Matching - The NNMi Administrator chooses which interface MIB variable NNMi queries to detect changes. NNMi can use the following MIB-II attribute values: ifIndex, ifName, ifDescr, ifAlias, or a combination of these (ifName or ifDescr, ifName or ifDescr or ifAlias). NNMi searches current database entries for information about the interface in this order: index, alias, name, and description. If multiple IP addresses are associated with the interface, NNMi starts by querying the lowest IP address and selects the first responding address in ascending order. If no response, NNMi queries any remaining IP addresses in the node's IP address inventory, starting with the lowest number. NNMi uses the address with the lowest number from which the SNMP agent responds. If no response, NNMi checks for any Mapped Address configured for one of the currently known addresses (see the Mapped Address column in the Custom IP Addresses view). The address represents a static Network Address Translation (NAT) pair's external IP address from the internal/external IP address pair. NNMi Administrators configure these pairs using the Overlapping IP Address Mapping form. NNMi uses this list of addresses starting with IPv4 from low to high, then IPv6 from low to high. If no response, NNMi might be configured to repeat the sequence using SNMPv1, SNMPv2c, or SNMPv3 in the order specified by the NNMi administrator (Communication Configurations SNMP Minimum Security Level settings). When all else fails, NNMi retains the last known Management Address (if any) and automatically changes the State of that SNMP Agent object to Critical. This process is repeated during each Spiral Discovery cycle, and the Management Address can change. For example, NNMi's inventory of addresses for the node expands, or the current Management Address does not respond to SNMP queries due to network problems or node reconfiguration. The NNMi administrator can prevent changes to the management address using the Communication Configurations Enable SNMP Address Rediscovery  (disabled) or Preferred Management Address setting. If  disabled, when the current management address (SNMP agent) becomes unreachable, NNMi does not check for other potential management addresses.
  Get-Bulk Enabled	Applies only to SNMPv2 or higher. If you have devices in your network environment that have trouble responding to GetBulk commands, you can instruct NNMi to use Get or GetNext instead of GetBulk. If  enabled, NNMi uses the SNMPv2c GetBulk command to gather information from this device. If  disabled, NNMi uses the SNMP Get or GetNext command to gather information from this device (requesting responses for one SNMP OID at a time).
  SNMP Timeout	(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999 milliseconds. Time that NNMi waits for a response to an SNMP query before reissuing the request. Both the Discovery Process and the State Poller Service use this setting for this device.
  SNMP Retries Count	Maximum number of retries that NNMi issues for an SNMP query before determining the query result to be "unresponsive". Zero means no retries. Both the Discovery Process and the State Poller Service use this setting for this device.
  SNMP Port	Default is 161. Specifies the management server's port that NNMi uses when generating SNMP traffic. Both the Discovery Process and the State Poller Service use this setting for this device.
  SNMP Proxy Address	Optional. IP address of the your SNMP Proxy Server (for example, a proxy that gathers data from non-SNMP devices and can use that data to respond to NNMi SNMP requests). To enable a proxy, you must also provide the port number of your SNMP Proxy Server. See SNMP Proxy Port (next attribute). When you configure NNMi to use a Proxy Server, you must ensure that the Proxy Server vendor supports the Object Identifiers used to handle SNMP requests and responses.
  SNMP Proxy Port	Optional. Port number of the SNMP Proxy Server. To enable a proxy, you must also provide the IP address of your SNMP Proxy Server. See SNMP Proxy Address (previous attribute). When you configure NNMi to use a Proxy Server, you must ensure that the Proxy Server vendor supports the Object Identifiers used to handle SNMP requests and responses.
  SNMP Preferred Version	This setting determines whether each NNMi Rediscovery cycle automatically detects the best SNMP choice (v1, v2, or v3) for this Node (automatically detects any upgrade to the SNMP agent on each Node), or uses only the SNMP version that you specify. Specifies the SNMP version that NNMi should use when communicating with a device. Select one of the following options: 1 Indicates you want NNMi to try only SNMPv1 settings. Tip Use this option when you do not want NNMi to use GetBulk commands on the device. 2 Indicates you want NNMi to use SNMPv2c settings, and, if that fails, try SNMPv1 settings. If both SNMPv2c and SNMPv1 fail, NNMi tries SNMPv3 settings if any are available. 3 Indicates you want NNMi to use SNMPv3 settings for this device. NNMi uses the SNMPv3 Settings configuration to determine which of the following User-based Security Module (USM) levels of security to provide: No Authentication, No Privacy Authentication, No Privacy Authentication, Privacy

  The SNMP Minimum Security Level is determined by the settings on the Communication Configurations' Specific Node Settings form, SNMPv3 Settings tab where SNMPv3 Settings for this Node are established.

  ICMP Settings for this Device

  Attribute	Description
  Enable ICMP Communication	If  enabled, NNMi generates network traffic with ICMP protocol to this device. If  disabled, NNMi does not generate any ICMP traffic to this device: Addresses in this Node (both previously discovered and newly discovered) have a State attribute value of "Not Polled" and a Status attribute value of "No Status" with the IP Address map-symbol color set to beige. If both ICMP and SNMP are disabled, the Node has a Status attribute value of "No Status" have a map-symbol background shape color set to beige. Your choice might be overridden if Monitoring Configuration settings disable ICMP usage for the State Poller Service.
  ICMP Timeout	(Seconds:Milliseconds) Maximum 1 millisecond less than a minute: 59 seconds 999 milliseconds. Time that NNMi waits for a response to an ICMP query before reissuing the request to this device.
  ICMP Retries Count	Maximum number of retries that NNMi issues for an ICMP query to this device before logging an error. Zero means no retries.

  Configure SNMPv1/v2c community strings for a specific node

  Optional. Configure the SNMPv1 or SNMPv2c community strings for each node.

  NNMi uses the SNMPv2c settings to discover the SNMPv2c information about your network. This also determines whether NNMi receives or discards incoming SNMPv2c traps. Click here for more information.

  • If the incoming trap's Source Node (and sometimes Source Object, such as card or interface) has not yet been discovered by NNMi, NNMi discards the trap.
  • If the Source Node was not discovered using SNMv3, NNMi discards any incoming SNMPv3 traps from that Node.
  • NNMi discards traps that have no incident configuration or with an incident configuration set to Disabled. To ensure that NNMi retains all received Trap instances when your network environment includes SNMP agents using a variety of SNMPv1, SNMPv2c, and SNMPv3 protocol, you must configure two Incidents: one for the SNMPv1 version and one for the SNMPv2c/3 version of that trap.

  • If either the Source Node or Source Object has Management Mode set to Not Managed or Out of Service in the NNMi database, NNMi always discards the incoming trap.

    NNMi provides the Management Mode workspace so that you can quickly view lists of all nodes, interfaces, IP addresses, chassis, cards, node sensors, or physical sensors that NNMi is not currently discovering or monitoring.

  • NNMi discards most incoming traps from network objects that are not monitored. For example, you can configure NNMi to exclude specified interfaces from being monitored.

  To provide SNMPv1/v2c community strings for a specific device:

  1. Navigate to the Specific Node Settings form.

     1. From the workspace navigation panel, select the  Configuration workspace.
     2. Select Communication Configuration.
     3. Navigate to the Specific Node Settings tab.

     4. Do one of the following:

        • To establish a node definition, click the New icon.
        • To edit a node definition, select a row, click the Open icon.
  2. Navigate to the SNMPv1/v2c Community Strings tab.

  3. To provide a read community string, navigate to the Read Community String attribute and provide the appropriate string (see table).

     Tip If you do not provide any read community string, NNMi uses the applicable Region settings and if none match, NNMi uses the default settings.

  4. To provide a write community string, navigate to the Write Community String attribute and provide the appropriate string (see table).

     Tip If you do not provide any write community string, NNMi uses the applicable Region setting and if none match, NNMi uses the default setting .

  5. Click  Save and Close to return to the Communication Configuration form.
  6. Click  Save and Close to apply your changes.

  SNMPv1 or SNMPv2c Community String for this Device

  Attribute	Description
  Read Community String	The SNMPv1 or SNMPv2c "Get" (read-only) Community String that is used for this device (case-sensitive). Tip If you do not provide any read community string, NNMi uses the applicable Region settings and if none match, NNMi uses the default settings . Many proxy vendors use the read community string for specifying remote target information. NNMi supports substitution parameters within read community strings for SNMPv1 or SNMPv2c proxy environments. Click here for more information. Copy and paste these codes at the end of your read community string to provide the values required by your proxy environment. NNMi substitutes the actual attribute values from the NNMi database at runtime: ${contextName} = Used for specifying VLAN context for switches (VLAN associated with the remote target node) ${managementAddress} = Node form, Management Address attribute value (the remote target node) ${snmpPort} = SNMP Agent form, UDP Port attribute value (SNMP agent associated with the remote target node) Type a maximum of 255 characters. Alpha-numeric, spaces, and special characters (~ ! @ # $ % ^ & * ( ) _+ -) are permitted.
  Write Community String	Optional. For use with the nnmsnmpset.ovpl command line tool. The SNMPv1 or SNMPv2c "Set" (write) Community String that is used for the SNMP Agent for each node specified (case-sensitive). Tip SNMP Agents are often configured with different community strings for "Set" requests than for "Get" (read) requests. SNMPv1 and SNMPv2c require that you know the SNMP agent's write community string before you can change settings on any device. The nnmsnmpset.ovpl command can use the value you provide here, rather than requiring that you type the write community string each time you invoke the command. Tip If you do not provide any write community string, NNMi uses the applicable Region setting and if none match, NNMi uses the default setting. Type a maximum of 255 characters. Alpha-numeric, spaces, and special characters (~ ! @ # $ % ^ & * ( ) _+ -) are permitted. Because this is a type of password, you must enter the value twice.

  Configure SNMPv3 settings for a specific node

  NNMi can use SNMPv3 user-based security model (USM) settings to access devices.

  NNMi uses the current SNMPv3 Settings provided for a node, if available.

  To configure an SNMPv3 Settings for a specific node:

  1. Navigate to the Specific Node Settings form.

     1. From the workspace navigation panel, select the  Configuration workspace.
     2. Select Communication Configuration.
     3. Navigate to the Specific Node Settings tab.

     4. Do one of the following:

        • To establish a node definition, click the New icon, and continue.
        • To edit a node definition, select a row, click the Open icon, and continue.
  2. Navigate to the SNMPv3 Settings tab.

  3. Click the SNMPv3 Settings  Lookup icon and select one of the options from the drop-down menu:

     •   Show Analysis to display Analysis Pane information for the currently configured (selected) SNMPv3 Setting name.
     •  Quick Find to view and select from the list of all existing SNMPv3 Settings.
     •  Open to display the details of the currently configured (selected) SNMPv3 Setting.
     •  New to create a new SNMPv3 Setting.
  4. Click  Save and Close to return to the Specific Node Settings form.
  5. Click  Save and Close to return to the Communication Configuration form.
  6. Click  Save and Close to apply your changes.

  Configure credential settings for a specific node

  [This is the Context-Sensitive Help topic for the Device Credentials tab on the Specific Node Settings form (and the Specific Node Device Credentials form).]

  NNMi uses the Device Credentials settings for the following:

  • Device discovery of some vendor-specific devices that require non-SNMP communication, such as Netconf over SSH. For a list of the these devices see the NNMi Device Support Matrix.

  • Device Diagnostics

    Requires Network Node Manager iSPI Network Engineering Toolset Software (NNM iSPI NET) and requires installation of a Diagnostic Server.

  NNMi uses the following sequence to determine Device Credentials:

  • Use the Specific Node Device Credentials. If none match, continue.
  • Use the Region Device Credentials. If none match, continue.
  • Use the Default Credential settings.

  To provide credential settings for a specific node:

  1. Navigate to the Specific Node Device Credentials form.

     1. From the workspace navigation panel, select the  Configuration workspace.
     2. Select Communication Configuration.
     3. Navigate to the Specific Node Settings tab.

     4. Do one of the following:

        • To establish a definition, click the New icon.
        • To edit a definition, click the Open icon in the row representing the configuration you want to edit.
     5. In the Specific Nodes Settings form, navigate to the Device Credentials tab.

     6. Do one of the following:

        • To establish a credential setting, click the  New icon, and continue.
        • To edit a credential setting, click the  Open icon in the row representing the configuration you want to edit, and continue.
        • To delete a credential setting, select a row and click the  Delete icon

  2. Provide the attribute values of credentials for this node (see table).

     NNMi tries to use the Specific Node Device Credentials provided here. If none match, NNMi tries the Region Device Credential settings. If none match, NNMi tries the Default Device Credentials.

  3. Click  Save and Close to return to the Specific Node Settings form.
  4. Click  Save and Close to return to the Communication Configuration form.
  5. Click  Save and Close to apply your changes.

  NNM iSPI NET uses the Default Credentials setting to access devices when running Diagnostics either automatically or when the Actions > Run Diagnostics option is used.

  You can also right-click any object in a table or map view to access the items available within the Actions menu.

  At each level in the sequence to determine the Device Credentials (see bullet list above), NNMi first uses Secure Shell (SSH) to establish a secure connection, and if the SSH attempt fails, NNMi tries Telnet protocol as the communication method.

  Caution By default, neither Microsoft Internet Explorer nor Mozilla Firefox defines the telnet command nor the SSH command, so using either of these menu items produces an error message.

  Specific Node Device Credential Attributes

  Attribute	Description
  Type	Select one of the following: Shell Use this setting to provide credentials for NNMi to use when communicating with devices using Secure Shell (SSH) or Telnet protocol. VMware Use this setting to provide credentials for NNMi to use when communicating with VMware ESXi servers using VMware VSphere® WebService.
  User Name	Type the user name that you want NNMi to use for logging into this device.
  Password	Type the password that you want NNMi to use for logging into this device. NNMi encrypts the password and displays asterisks for this attribute. If you want to change the password, first clear the asterisks displayed in the Password attribute and enter the new Password value.

  Configure trusted certificate settings for a specific node

  [This is the Context-Sensitive Help topic for the Trusted Certificate tab on the Specific Node Settings form (and the Specific Node Trusted Certificate form).]

  (NNMi Advanced) NNMi uses certificates to securely communicate with virtual machines running on hypervisors. By using the Trusted Certificates tab, you can upload trusted certificates that help NNMi create this secure communication channel. You can use a CA-signed certificate or a certificate that is generated by the VMware ESXi host.

  By default, NNMi communicates with virtual machines running on hypervisors by using the HTTPS protocol. If your hypervisors are specifically configured to support HTTP communication, you can configure NNMi to use the HTTP protocol while communicating with virtual machines, and in that case, you do not need trusted certificates.

  NNMi uses the following sequence to determine which certificate to use while communicating with virtual machines:

  • Use the Specific Node Trusted Certificate (provided here). If none match, continue.
  • Use the Region Trusted Certificate. If none match, continue.
  • Use the Default Trusted Certificate settings.

  To provide credential settings for a specific node:

  1. Navigate to the Specific Node Trusted Certificate form.

     1. From the workspace navigation panel, select the  Configuration workspace.
     2. Select Communication Configuration.
     3. Navigate to the Specific Node Settings tab.

     4. Do one of the following:

        • To establish a definition, click the New icon.
        • To edit a definition, click the Open icon in the row representing the configuration you want to edit.
     5. In the Specific Nodes Settings form, navigate to the Trusted Certificate tab.

  2. Click Upload Certificate. The Open window appears.

  3. Select a file to upload the certificate to the NNMi management server, and then click Open. The certificate information appears in a table in the Trusted Certificates tab. You can upload multiple certificates.

     You can use only the following certificate formats:

     • .pem

     • .crt

     • .cer

     • .der

     If you upload multiple certificates at this tab, NNMi uses one out of all uploaded certificates to establish HTTPS connection with Web Agents.

     The table in the Trusted Certificates tab shows basic attributes of all uploaded certificates.

  4. Click  Save and Close to return to the Communication Configuration form.
  5. Click  Save and Close to apply your changes.

  The table in the Trusted Certificates tab shows basic attributes of all uploaded certificates. To view additional information about each certificate, click the certificate in the table in the Trusted Certificates tab.

  Specific Node Trusted Certificate Attributes

  Attribute	Description
  Subject DN	The Subject Distinguished Name (Subject DN) of the certificate.
  Valid From	The Valid From and Valid To values together define the validity period of the certificate.
  Valid To

  Related topics

  • Configure regions
  • Discover Your Network