Juniper Space Security Director Policy Hit Counts Not Updated Automatically

Issue Symptons:

Normally, each firewall rule on the SRX auto-updates a snmp counter for hit-count, regardless of whether 'count' is configured or not. Juniper Space Security Director periodically polls these OIDs and updates the hit-count.
In Junper Space 16.1 R1, the issue found is unable to view policy hit counts from Juniper Space Security Director, but SRX itself is keep updating.

Actions Taken:

Verify Security Appliance Policy Hits from Command line

root@fw-mgmt-2> show security policies hit-count 
node1:
--------------------------------------------------------------------------

Logical system: root-logical-system
 Index   From zone        To zone           Name           Policy count
 1       Vlan2              Vlan1        Baramondi_Monitor 0            
 2       Vlan2              Vlan1        10             4428         
 3       Vlan2              Vlan1        50             0            
 4       Vlan2              Vlan1        40             11136        
 5       Vlan2              Vlan1        default-logdrop 0            
 6       Vlan2              Vlan1        53             2007         
 7       Vlan2              Vlan1        54             0            
 8       Vlan2              Vlan1        55             0            
 9       Vlan2              MGMT              6              538          
 10      Vlan2              MGMT              23             0            
 11      Vlan2              MGMT              74             2            
 12      Vlan2              MGMT              default-logdrop 81           
 13      Office              Vlan1        default-logdrop 0            
 14      Office              Vlan1        60             447          
 15      Office              Vlan1        Office_Archive    0            
 16      Office              Vlan1        58             0            
 17      Office              Vlan1        Baramondi_Monitor-1 0            
 18      Office              MGMT              Office_Archive-1  0            
 19      Office              MGMT              default-logdrop 0            
 20      Vlan1       Vlan2               Baramondi_Rules 0            
 21      Vlan1       Vlan2               VA             0            
 22      Vlan1       Vlan2               A_Office_2_Vlan2    292          
 23      Vlan1       Vlan2               default-logdrop 1696         
 24      Vlan1       Office               VA-1           0            
 25      Vlan1       Office               Baramondi_Rules-1 0            
 26      Vlan1       Office               Device-Zone-1  0            
 27      Vlan1       Office               4              1299         
 28      Vlan1       Office               default-logdrop 0            
   ........

It is clearly there is hit counts on SRX itself, but they are not being pulled/pushed into Space. Log collecter has beenconfigured and it is receiving logs from this SRX.

Solutions:

Let Juniper Space manually probe latest policy hits

From Firewall Policies page, you can manually

This is a known issue reported in 16.1R1 version and the workaround to resolve this issue is the following:

From Space CLI run the following command:

mysql -ujboss -pnetscreen sm_db -e "update RuntimePreferencesEntity set value='2' where name='POLICY_HIT_COUNT_MAX_SUBJOBS_PER_NODE';"

Space release 16.1R2.7 (381623)

Last login: Fri Sep  8 15:27:35 2017 from 10.94.200.168

Welcome to the Junos Space network settings utility.

Initializing, please wait


Junos Space Settings Menu

1> Change Password
2> Change Network Settings
3> Change Time Options
4> Retrieve Logs
5> Security
6> Expand VM Drive Size
7> (Debug) run shell

A> Apply changes
Q> Quit
R> Redraw Menu

Choice [1-7,AQR]: 7

[sudo] password for admin: 
[root@space-c6186f1b3edb ~]# 
[root@space-c6186f1b3edb ~]# 
[root@space-c6186f1b3edb ~]# 
[root@space-c6186f1b3edb ~]# mysql -ujboss -pnetscreen sm_db -e "update RuntimePreferencesEntity set value='2' where name='POLICY_HIT_COUNT_MAX_SUBJOBS_PER_NODE';"
Warning: Using a password on the command line interface can be insecure.
[root@space-c6186f1b3edb ~]#

RESTART JBOSS:

First, identify which node has the vip (eth0:0). Check each node with the following:

# ifconfig eth0:0

Recommended restart process (only if JBOSS restart is needed):

1. Stop processes on all JBOSS nodes
# service jmp-watchdog stop
# servicejboss stop
# service jboss-dc stop
Note: jboss-dc is only active on VIP node, but the command won't do any harm

2. Confirm if JBOSS has been turned off

# service jboss status

3. Start services on the vip node
# service jmp-watchdog start
Note: watchdog starts other processes

4. After you can login, start services on all of the other nodes
# service jmp-watchdog start


[root@space-c6186f1b3edb ~]# service jmp-watchdog stop
[root@space-c6186f1b3edb ~]# service jboss stop
found and stop jboss
[root@space-c6186f1b3edb ~]# service jboss-dc stop
stop domain controller
[root@space-c6186f1b3edb ~]# service jboss status
jboss is stopped
[root@space-c6186f1b3edb ~]# service jmp-watchdog start
jmp-watchdog running
[root@space-c6186f1b3edb ~]# ifconfig eth0:0
eth0:0    Link encap:Ethernet  HWaddr C6:18:6F:1B:3E:DB  
          inet addr:10.94.200.22  Bcast:10.94.200.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:145

Notes: Just got confirmation. It is a bug and it wont be fixed until Juniper Space 17.2.