Known Issues

The following issues are still outstanding in the Junos Space Network Management Platform Release 16.1R3. For each entry, the identifier following the description is the tracking number in the Juniper Networks Problem Report (PR) tracking system.

• If you assign a device to a different domain and there are dependencies, Junos Space correctly blocks the assignment but sometimes the Junos Space user interface does not display an error message. [PR1003361]
• In some cases, the Execute Operation job displays a negative percentage completion rate. [PR1083829]
• The PostgreSQL process on the FMPM standby (secondary) node is not monitored.

  Workaround:

  1. Log in to the FMPM node (by using SSH) and open a debug (command) prompt.
  2. Navigate to the /etc/snmp/ directory.
  3. Use vi or any text editor to open the snmpd.conf file.
  4. Remove the comment tag from the exec Postgresql /bin/sh /etc/snmp/moniPostgresql.sh statement.
  5. Save the snmpd.conf file.
  6. Restart the SNMP agent on the node by executing the service snmpd restart command.

  [PR1116414]

• In a fabric with IPv4 and IPv6 addresses configured, if you modify the IP address of the VIP node using the Junos Space GUI (Administration > Fabric > Space Node Settings), then, in some cases, the Junos Space GUI is not accessible.

  Workaround:

  1. Log in to the VIP node to access the Junos Space CLI and open a debug (command) prompt.
  2. Restart the heartbeat service by using the service heartbeat start command.
  3. Log out of the Junos Space VIP node. [PR1178264]
• If you add X.509 parameters in the Modify Application Settings page (Administration > Applications > Network Management Platform > Modify Application Settings > X509CertificateParameters) and click the Modify button, Junos Space Platform parses the parameters from the certificate associated with users who do not have the parameters already processed. This means that users for whom the parameters were processed previously will not be processed again.

  Workaround: Do one of the following:

  • When you are adding the X.509 Certificate Parameters for the first time, ensure that you click the Save link to save the information and click the Modify button only after you have entered all the parameters.
  • If you already added the X.509 Certificate Parameters and need to modify them later, execute the /var/www/cgi-bin/parseUserCertificates script on the Junos Space VIP node.
  • If Junos Space Platform is not previously configured to authenticate using X.509 certificate parameters, then remove all the existing X.509 certificate parameters from the Modify Application Settings page and click the Modify button to remove all certificate parameters associated with users. Then, add the X.509 Certificate Parameters and click the Modify button, which triggers the parsing of the certificates associated with users.

  [PR1175587]

• If a device is discovered using a custom key, you cannot execute local scripts on the device.

  Workaround: None. [PR1213430]

• When you export operations from the Operations page (using the Export Operations workflow), the options specified for the operation in the Junos Space Platform UI are not exported to the XML file.

  Workaround: None. [PR1214022]

• Junos Space Platform fails to discover a device if the device is authenticated with a custom key generated using the openssl genpkey utility and one of the following is true:
  • The key is encrypted using one of the following passphrase ciphers: des, aes128, aes256, or aes 192.
  • The key is encrypted using the ECDSA algorithm.

  Workaround: Do one of the following:

  • Use a custom key generated using the ssh-keygen utility.
  • Use a custom key generated using the openssh genpkey utility, but use DSA or RSA as the encryption algorithm.

  [PR1214215]

• In a Junos Space fabric with both eth0 and eth3 interfaces enabled and only IPv6 addresses configured, if you try to add an FMPM node (configured with both IPv4 and IPv6 addresses) using the IPv6 address, the node addition fails.

  Workaround: None. [PR1217708]

• If you are running Junos Space Platform Release 15.2R2 and managing NATted devices (devices behind NAT) using the Model Devices workflow, when you upgrade to Junos Space Platform Release 16.1R1, the Device Network field for the devices behind NAT is marked as Internal.

  Workaround: Delete the devices marked Internal and rediscover them to ensure that the Device Network field for the devices is marked correctly. [PR1219391]

• In a Junos Space fabric that includes a Cassandra node, if you try to delete a non-Cassandra node, the node deletion operation fails in some cases.

  Workaround: Do one of the following:

  • Perform the following actions:
    1. Copy the /etc/hosts file from a Junos Space node to the Cassandra node.
    2. Log in to the Cassandra node as the admin user and open a debug (shell) prompt.
    3. Execute the service jmp-firewall reload command.
    4. Execute the service nma reload command.
    5. Log out of the Cassandra node.
    6. Trigger the delete node operation from the Junos Space UI.
  • Trigger the delete node operation from a UI session served by a Junos Space node that was added to the Junos Space fabric before the Cassandra node.

  [PR1220925]

• If some external devices managed by the Junos Space fabric are down and you add a new Junos Space node to the fabric with NAT enabled, the node is added to the fabric and the Update Devices job is triggered. This job is completed successfully even though the new NAT configuration is not pushed to the devices that are down.

  Workaround: Do one of the following:

  • Ensure that all the devices are in the 'Up' state before you add a new node.
  • For the devices that are down, manually configure the outbound-ssh and target-address (SNMP trap target) configuration statements on the device.

  [PR1221595]

• If you configure a Junos Space fabric with eth0 and eth3, Junos Space Platform does not validate all the possible IP address configuration combinations.

  Workaround: Ensure that you configure the Junos Space fabric in one of the following combinations:

  • Both eth0 and eth3 configured with only the IPv4 address
  • Both eth0 and eth3 configured with IPv4 and IPv6 addresses (dual stack)

  [PR1224070]

• If some devices managed by the Junos Space fabric are down and you configure disaster recovery with NAT enabled, the disaster recovery configuration for the standby site is not pushed to the devices that are down. However, the job associated with the device updates completes successfully.

  Workaround: Do one of the following:

  • Ensure that all the devices are in the Up state before you add a new node.
  • For the devices that are down, manually configure the outbound-ssh and target-address (SNMP trap target) configuration statements on the device.

  [PR1227196]

• If you configured a Junos Space fabric containing one or two dedicated database nodes and one or two FMPM nodes without configuring NAT and try to configure NAT from the Junos Space CLI of the FMPM node, the job is triggered but the configuration is not updated in the FMPM node or on the devices. In addition, if you configure NAT from the Junos Space Platform UI, the NAT configuration is updated successfully. However, the option to disable NAT is not available in the CLI of the FMPM node and the NAT configuration is shown as NULL in the CLI of the FMPM node.

  Workaround: For FMPM nodes, configure or disable NAT only from the Junos Space Platform UI. [PR1227595]

• If you have configured disaster recovery in your Junos Space setup and create a modeled device, the configlet generated as part of the model device creation contains only the details of the active setup and not the standby setup.

  Workaround: None. [PR1228421]

• When you try to upgrade an low-end SRX series cluster device that has the upgrade dual-root partition and ISSU/ICU options enabled, the image upgrade is executed successfully for both the nodes (node0, node1) and deployment job is successful. However, for one of the nodes (either node0 or node1), the primary partition snapshot is not copied to alternate root partition.

  Workaround: Log in to the VIP node of the SRX series cluster and execute the request system snapshot slice alternate command; this takes a snapshot from the primary partition and copies it to alternate partition on both nodes. [PR1228763]

• After you upgrade from Junos Space Platform Release 15.2R2 to Release 16.1R1, in some cases, you cannot modify the settings on the Modify Application Settings page.

  Workaround:

  1. Log in to the Junos Space CLI (of the VIP node) and open a debug (shell) prompt.
  2. Stop the MySQL service by executing the service mysql stop command.
  3. Restart the MySQL service by executing the service mysql start command.
  4. After the MySQL service is restarted, log out of the Junos Space CLI.

  [PR1229459]

• If you discover a device that is authenticated by using a custom key or a Junos Space key encrypted with the Digital Signature Algorithm (DSA) and try to execute a local script on the device, the script execution fails.

  Workaround: Delete the device and rediscover the device using a Junos Space key encrypted using RSA or ECDSA and execute the local script. [PR1231409]

• If you try to deploy an image on an EX Series device with the Remove the package after successful installation check box selected (in the Common Deployment Options section of the Deploy Image on Devices page), the job fails.

  Workaround: None. [PR1232485]

• The authentication status of a clustered device remains as Unverified even after the SSH fingerprint of the device is acknowledged.

  Workaround: None. [PR1241912]