We have several SRX300 and SRX345 (with and without cluster), and I never saw a commit time between 5 and 10 seconds at all on this platform. Unfortunately I'm not aware of any tweak possibilities, maybe someone with more SRX experience knows a possibility.
By the way, to get a device into factory default state, you can perform "request system zeroize".
HI A.Vanson,
This template is using for downloading and Predefined IDP Policy Templates, normally procedure is that after download and install template, we should delete it, it will not cause any impact. https://www.juniper.net/documentation/en_US/junos12.1x47/topics/task/configuration/idp-predefined-policy-template-downloading-and-using-cli.html
Please delete or deactive the script file, command like below
user@host# delete system scripts commit file templates.xsl
user@host# deactivate system scripts commit file templates.xsl
it will fix it.
LilDexx, I turned off the log report setting, but still the same.
This SRX was very slow from the start, even after a factory reset. Compared to our other SRX it's night and day in terms of commit times. Seems like something's missing here, but not sure what.
I even loaded the same configs from our other SRX onto this one and commit times are still over the top.
If I do a commit | display detail on our other SRX, the commit logs are very short, nothing compared to this one, e.g.:
2020-07-01 09:41:24 MST: Obtaining lock for commit 2020-07-01 09:41:24 MST: updating commit revision 2020-07-01 09:41:24 MST: start loading commit script changes 2020-07-01 09:41:24 MST: no commit script changes 2020-07-01 09:41:24 MST: no transient commit script changes 2020-07-01 09:41:24 MST: finished loading commit script changes 2020-07-01 09:41:24 MST: copying juniper.db to juniper.data+ 2020-07-01 09:41:24 MST: finished copying juniper.db to juniper.data+ 2020-07-01 09:41:24 MST: exporting juniper.conf 2020-07-01 09:41:24 MST: expanding interface-ranges 2020-07-01 09:41:24 MST: finished expanding interface-ranges 2020-07-01 09:41:24 MST: expanding groups 2020-07-01 09:41:24 MST: finished expanding groups 2020-07-01 09:41:24 MST: setup foreign files 2020-07-01 09:41:24 MST: update license counters 2020-07-01 09:41:24 MST: finish license counters 2020-07-01 09:41:24 MST: propagating foreign files 2020-07-01 09:41:24 MST: mustd returns = 7(persist groups is not configured (needed for cdg)) 2020-07-01 09:41:25 MST: complete foreign files 2020-07-01 09:41:25 MST: dropping unchanged foreign files 2020-07-01 09:41:25 MST: executing 'ffp propagate' 2020-07-01 09:41:25 MST: daemons checking new configuration 2020-07-01 09:41:25 MST: commit wrapup... 2020-07-01 09:41:25 MST: start ffp activate 2020-07-01 09:41:25 MST: executing 'ffp activate' 2020-07-01 09:41:26 MST: activating '/var/etc/inetd.conf' 2020-07-01 09:41:26 MST: activating '/var/etc/rc.conf.inc' 2020-07-01 09:41:26 MST: activating '/var/etc/pam.conf' 2020-07-01 09:41:26 MST: activating '/var/etc/pam_radius.conf' 2020-07-01 09:41:26 MST: activating '/var/etc/pam_tacplus.conf' 2020-07-01 09:41:26 MST: activating '/var/etc/issue' 2020-07-01 09:41:26 MST: activating '/var/etc/certs' 2020-07-01 09:41:26 MST: activating '/var/etc/motd' 2020-07-01 09:41:26 MST: activating '/var/etc/max-db-size-cfg' 2020-07-01 09:41:26 MST: activating '/var/etc/subs-mgmt-cfg' 2020-07-01 09:41:26 MST: activating '/var/etc/vmm.conf' 2020-07-01 09:41:26 MST: activating '/var/etc/db_ext-cfg' 2020-07-01 09:41:26 MST: activating '/var/etc/ephinst.conf' 2020-07-01 09:41:26 MST: executing foreign_commands 2020-07-01 09:41:26 MST: /bin/sh /etc/rc.ui ui_setup_users (sh) 2020-07-01 09:41:26 MST: executing ui_commit in rc.ui 2020-07-01 09:41:33 MST: finish ffp activate 2020-07-01 09:41:33 MST: copying configuration to juniper.save 2020-07-01 09:41:33 MST: db_check_constraint_ids_clear start 2020-07-01 09:41:34 MST: db_check_constraint_ids_clear done 2020-07-01 09:41:34 MST: db_groups_info_clear start 2020-07-01 09:41:34 MST: db_groups_info_clear done 2020-07-01 09:41:34 MST: activating '/var/run/db/juniper.data' 2020-07-01 09:41:34 MST: Rotate backup configs 2020-07-01 09:41:34 MST: ssync begins 2020-07-01 09:41:34 MST: ssync ends 2020-07-01 09:41:34 MST: notifying daemons of new configuration 2020-07-01 09:41:34 MST: notifying inetd(31) 2020-07-01 09:41:34 MST: signaling 'Inet process', pid 1741, signal 1, status 0 with notification errors enabled 2020-07-01 09:41:34 MST: ssync begins 2020-07-01 09:41:34 MST: ssync ends 2020-07-01 09:41:34 MST: commit complete commit complete
Thanks for your assistance, but looks like on this SRX there's nothing like that on there:
[edit] root@vilton# delete system scripts commit file templates.xsl warning: statement not found [edit] root@vilton# deactivate system scripts commit file templates.xsl warning: statement not found
request system zeroize did the trick, cleared out everything. Factory reset button doesn't zeroize on the SRX345
Hello,
All You need is to configure a trap-group with category "configuration" as described here
- and specify a target IP address within this trap group to send the traps to.
The trap-group name serves as community for v2c traps.
HTH
Thx
Alex
thanx for reply alex. can you please tell what config will be done at junos space side for notification ?
thanx
erfan
Hello,
Please see if this helps
HTH
Thx
Alex
hello,
im getting snmp notfication from 0.0.0.0 interface . which are causing huge email.
please help
thanx
Hi Erfanxp,
Good day!!
Tracking Router Configuration Changes
Problem
You want an NMS system to track when the router’s configuration has been changed.
Solution
First, define the NMS system and its password:
[edit snmp v3]
aviva@router1# set
usm local-engine user nms2 authentication-sha authentication-
password $0212roZH
aviva@router1# set usm local-engine user nms2 privacy-des privacy-password 0212roZH
Then, define two views that allow the NMS access to the configuration information. The first view defines what the NMS can read from the MIB:
[edit snmp v3]
aviva@router1# set view config-info-read oid jnxCfgMgmt include
The second view sets what the router includes in notifications sent to the NMS:
[edit snmp v3]
aviva@router1# set view config-info-notify oid jnxCfgMgmt include
aviva@router1# set view config-info-notify oid jnxCmNotifications include
aviva@router1# set view config-info-notify oid snmpMIBObjects include
aviva@router1# set view config-info-notify oid system include
Finally, create groups and their users and assign access privileges for the groups:
[edit snmp v3]
aviva@router1# set vacm security-to-group security-model usm security-name nms2 group
config-only
aviva@router1# set vacm access group config-only default-context-prefix security-
model usm security-level privacy read-view config-info-read
aviva@router1# set vacm access group config-only default-context-prefix security-
model usm security-level privacy notify-view config-info-notify
Discussion
To use SNMP to extract the router configuration, use the Juniper Networks configuration management MIB extension, which tracks who made changes to the configuration and when. This recipe gives the NMS system called nms2 access to configuration information.
The first commands in this recipe configure USM for security, with SHA1 authentication and DES message payload encryption. You then create two views, one that defines what nms2 can read from the MIB and a second that sets what the router can include in notifications. The final commands configure the VACM to provide access to desired groups.
Again, this recipe is somewhat involved, so here’s what the resulting configuration looks like after you issue the commands in this recipe, with some added comments:
aviva@router1# show | except SECRET-DATA
v3 {
usm { # <-- which NMS systems can access the router
local-engine {
user nms2 {
authentication-sha {
privacy-des {
}
}
}
}
vacm { # <-- what the NMS systems can access on the router
security-to-group { # <-- which access group each NMS is in
security-model usm {
security-name nms2 {
group config-only;
}
}
}
access { # <-- which MIB views the NMS systems can access
group config-only {
default-context-prefix {
security-model usm {
security-level privacy {
read-view config-info-read;
notify-view config-info-notify;
}
}
}
}
}
}
}
view config-info-read { # <-- view of enterprise configuration management objects
oid jnxCfgMgmt include;
}
view config-info-notify { # <-- view for objects used by SNMPv3 traps
oid jnxCfgMgmt include;
oid jnxCmNotifications include;
oid snmpMIBObjects include;
oid system include;
}
https://www.oreilly.com/library/view/junos-cookbook/0596100140/ch04.html
Please mark "Accepted Solution" if this helps you solve your query. Kudos are always appreciated.
Thanks
Suraj
Hi Exfanxp,
Greetings,
Are these some public clients who are unauthorized to access SNMP agent ?
If yes , then try restricting them using the below command:
user@host# set snmp community public clients 0.0.0.0/0 restrict
Link: Restrict SNMP access to certain sources.
Hope this helps. 
Please mark "Accept as solution" if this answers your query. Kudos are appreciated too!
Regards,
Sharat Ainapur
I've been using the dynamic VPN feature on my SRX a lot, but more for surfing the internet and less for accessing internal resources. I needed to transfer a 20GB file to my Synology and noticed it was only transferring between 2 and 4Mbps. When using the VPN to browse the internet, split tunneling is not used and all traffic travels back to the SRX and then is NAT'd and sent out the untrusted-zone. I can max out the connection speed when doing a speedtest.net test, but cannot get higher than 4Mbps when doing an iperf3 test end-to-end. Originally, I thought this was due to packet fragmentation so I lowered the TCP mss using "set security flow tcp-mss ipsec-vpn mss 1200" and that made no difference. When I'm home and inside the LAN, without the VPN enabled of course, iperf3 speeds on WiFi are a little over 600Mbps, which is great. I've removed the policer PROTECT-RE, but no change. Maybe I'm overlooking something, but I cannot understand why I'm seeing slow speeds when connected over VPN.
Model: SRX300
Junos: 18.4R3-S2
Configurations: HERE
JUNOS Software Release [18.4R3-S2]
SRX WAN: 1Gbps UP/DOWN
Remote Device: HP Laptop
OS: Windows 10 Home
WAN: 500Mbps UP/DOWN
Wireless Speed: 300Mbps UP/DOWN
Hello,
I confirm the same at SRX220H2 12.3X48-D101
Previously at 12.3X48-D85 - no such issue.
It seems that newline characters are now omitted ot not processed correctly as everything is merged into single line.
"show configuration" in the console produces output that looks fine.
Thank you for your reply.
If i do this can a share a BGP routing table in each routing instance ?
if your have a exemple of this type of configuration with a dialup VPN can you show me please .
Regards
Hello,
Please correct me if I'm wrong.
Unfortunately, I'm unable to view/download the configuration so, could you please lower the encryption level used in the Dynamic VPN and try once? If it's already lower, please ignore this suggestion.
I checked the Data Sheet of SRX300 and it looks like the IPSec throughput for IMIX traffic is 100 Mbps but it is tested with UDP traffic and not TCP.
Besides, could you check whether High RE CPU, High PFE CPU are observed while transferring the data? Also, let me know how many VPNs are currently configured on this SRX.
user@host> show chassis routing-engine
user@host> show security monitoring performance spu
Hi Erfan,
Could you please let me know whether you're using SNMPv2 or SNMPv3?
Are you seeing Traps on your monitoring server? If so, please provide more details regarding the same.(A snippet should suffice)
How did you verify the SNMP notification is coming from SRX device?
Hi Shaks,
It looks like there is a configuration mismatch between the current configuration and the configuration in the alternate root.
I think you are upgrading the Junos from 15.1X49 release to 18.X release or above and it is quite normal for this error to pop-up because certain configuration syntax has been deprecated in the latest Junos. So, we need to correct it prior to upgrading the Junos. One such instance is vlan interface has been deprecated and irb was introduced.
Please share us the complete error message so that we can change accordingly.