Searching for backup configuration files in JunosSpace

Within the Junos Space you can find all the .conf files ‘Configuration Files > Config Files Management’ path . But you want to back it up via bach/script file that runs automatically instead of exporting it from the Space GUI , and you don’t know where those files are stored in the JS directories :

First, good luck with that 🙂

Second, here is the path :

# cd /usr/local/jboss/domain/tmp/servers/server1/.conf/RCS/

# ls



Junos Space /VMware Tools

While you’re trying to backup your Junos Space VM machine via the VMware Tools, and you receive the following error:

FTL – vfm_freeze: method: VMware_v2, type: FIM, function: VMware_v2_freeze


as part of my research in Junos space resources I can see that “Junos Space Network Management Platform is not certified to be used with VMware tools

According to:

This should work From Junos Space Network Management Platform Release 16.1R1 onward.

EX mib2 errors

The following MIB2D error is viewed in the log messages:

VC10 mib2d[1282]: MIB2D_KVM_FAILURE: tu_kread: kvm_read returns error: short read

Here is a description of the problem:

The error is generated because SNMP is trying to collect data on the TCP connections of the switch and this data might be incorrect.
What actually is happening is that mib2d is working on 32 bits whereas the kernel is using 64 bits.
When mib2d is requesting data from the kernel, it’s receiving an 8byte pointer, which is truncated by mib2d to 4 byte pointer.
Then the mib2d is requesting that data by providing the 4 byte pointer. If that pointer doesn’t exist, then this message is returned.

The work-around for this is the following steps:

restart mib-process

restart snmp

These two commands will restart both the snmp and mib2d process. There will be no traffic impact doing this. Should this not work, you will want to reboot the switch.

This is not a permanent fix however and the messages may reappear in some time.
This bug has been reported and deal in this PR 1007305 [Confidential, Mistaken] – “DAEMON-3-MIB2D_KVM_FAILURE: tu_kread: kvm_read returns error: short read” messages seen in the logs
A more robust approach for mib2d to gather kernel information was implemented in Junos version R15.1
The fix for this situation is in Junos 15.1 version.
Please do an upgarde.

commit failed error

So you’re having a ‘commit failed’ error whenever you’re issuing the commit command in your SRX device


And you have trying everything you know to troubleshoot this problem, such as:

  • rebooting the device
  • issuing the ‘request system storage cleanup’ command
  • issuing the ‘commit full’ hidden command

Here I give another solution that might be helpful for you:

While connected via console:

1. show configuration | no-more | save current-config (I’d also recommend to take a local backup to your workstation as well, just in case)

2. start shell user root

3. cd /config

4. rm -f juniper.conf+

5. exit from shell

6. enter configuration mode and do a ‘load override current-config’ & commit

SRX Clustering primary\lost

Many of you came across configuring cluster in SRX firewall and got lost after they tried almost everything but they still stuck in “primary\lost” mode .

A lot of engineers are not aware of one important thing which is “cabling arrangement” . And this issue is the most of all “primary\lost” issues !!

So this table will show you where to put fxp0-1 and fab links in every node in cluster


Also you can use SRX HA Configuration Generator tool. It will help you build the best HA  configuration .

You also want to consider interfaces numbering when it comes to configure fab link. Take a look at this table :