Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
Why does it take between 5 minutes and 7 minutes for the SRX210 to boot ?
I've never seen a firewall appliance take this long to boot ( Cisco PIX, ASA, FortiGate UTM, etc... )
I did see a note in the new 10.x release notes about PR#298635 - SRX210 takes 2 to 5 minutes to initialize
Any clue if this is going to be fixed, or is it a problem with the hardware on this model ( CPU / NAND speed ) ?
I have tested straight from the box, 9.5R1.8 release, and the initial bootup took almost 10 minutes before I was past the login prompt at at a CLI > screen before I could issue commands.
Then I upgraded to the recommended 9.6R1.13 release and the boot time from power up is down to about 6 minutes.
However, if I issue a > request system reboot, it takes 7min and 30 seconds to get back to a useable prompt.
What gives with this platform ?
I guess I'll try 10.0 and see if any difference there.
I have 4 srx-210 devices deployed so far and I have noticed the same issue.
Has this caused any other issues other than fustration over the fact that Juniper put out hardware that has sub-optimal boot times for this market niche ?
It looks more and more like an issue with the CPU hardware that was chosen being too slow.
The FortiGate equivalent, the 110C has a boot time of 1 minute 5 seconds on the latest firmware 4.0MR1Patch1 to a useable CLI prompt. The Firewall process is actually started and working by 42 second mark.
I just don't see how Juniper is going to compete with this product if they don't get some issues addressed and fixed very quickly.
I'm open to anyone giving me any tips or help to get the most out of the SRX210 platform, or some recommendations for trying the SRX240 or SRX100 for better experiences.
Whoa. I just experienced the LONGEST firewall upgrade in history (and I'm not talking about translating rules or anything else )
A simple factory default from 9.6R1.13 to 10.0R1.8 took ... drumroll ... 25 minutes and 30 seconds. WTF?!?
We are talking a local upgrade from flash memory ...
1) I scp copied the image to /var/tmp
2) I issued the command > request system software add unlink no-copy /var/tmp/junos-srxsme-10.0R1.8-domestic.tgz
11:38 - see the commit / validate succeeded
12:47 - installing package ( I guess if I would have don the no-validate command, I could have cut 12:47 off )
18:39 - verified package (wait, didn't it already do that on the first 12 minutes ... * scratches head * )
19:18 - available space
19:29 - saving boot
19:35 - ready for reboot
20:07 - requested reboot
20:30 - sync discs
20:46 - loader.conf
21:20 - auto reboot
22:19 - loading config
23:53 - commit complete
24:07 - initialize interfaces
24:50 - login ( enter username / pass )
25:30 - CLI available
Juniper, you have to do something about this. This is RIDICULOUS. I had no config on here. This was factory default config, straight from 9.6.R1.13.
I'm already disappointed about the boot time of 5-7 minutes.
I sure hope this is something that can be optimized very quickly and get down to normal boot times for solid state firewalls of a minute or less ...
i have the same problem with the bootimes on my srx210.
it`s annoing and frustrating booting the device..
if you reboot an isg2000 with idp blades, it takes only 3minutes, and a srx210 about 6 ?
if this are the new generation of firewalls, i have to think it over to switch from the screenos based firewalls
to the srx plattforms...
there are a lot features / bugfixes to implement , i hope juniper will do somethig... let`s hope
I am also facing the same problem. Please find out what is the bug
Hi, I have the same problem. I installed the 9.6 R2 but the problem persist. It's really slow equipment
It is a common thing on all the SRX branch products. There does not seem to be any plan to improve this.
Well, the SRX210 that I had was upgraded 10.0R1.8 turned into a BRICK, so I'm waiting for Juniper to replace it.
Even though it has the nifty U-Boot interface that appears to be for some type of recovery, they don't have a working method for an end user to recover from the following (so if you see the following from your console, RMA is going to happen ) :
So ... I wait for the RMA to get the new gear ... I'm sure glad it was not in production.
U-Boot 1.1.6 (Build time: Apr 9 2009 - 22:31:05)SRX_210_POE board revision major:0, minor:32, serial #: AAAJ6812OCTEON CN5020-SCP pass 1.1, Core clock: 400 MHz, DDR clock: 200 MHz (400 Mhz data rate)DRAM: 1024 MBFlash: 4 MBUSB: scanning bus for devices... 4 USB Device(s) found scanning bus for storage devices... 2 Storage Device(s) foundPOST PassedClearing DRAM........ doneBIST check passed.Starting PCIPCI Status: PCI 32-bitPCI BAR 0: 0xf8000000, PCI BAR 1: Memory 0x00000000 PCI 0x00000000Net: octeth0Press SPACE to abort autoboot in 1 seconds## No elf image at address 0x00100000=>? - alias for 'help'askenv - get environment variables from stdinautoscr - run script from memorybase - print or set address offsetbdinfo - print Board Info structureboot - boot default, i.e., run 'bootcmd'bootd - boot default, i.e., run 'bootcmd'bootelf - Boot from an ELF image in memorybootloader - upgrade u-bootbootloader - upgrade loaderbootloader - upgrade ushellbootloader - upgrade flashbootloader - check u-bootbootloader - check loaderbootm - boot application image from memorybootoct - Boot from an Octeon Executive ELF image in memorybootoctelf - Boot a generic ELF image in memory. NOTE: This command does not sup simple executive applications, use bootoct for those.bootoctlinux - Boot from a linux ELF image in memorybootp - boot image via network using BootP/TFTP protocolbootvx - Boot vxWorks from an ELF imagecmp - memory compareconinfo - print console devices and informationcp - memory copycpld - peek/poke CPLDcrc32 - checksum calculationdhcp - invoke DHCP client to obtain IP/boot paramsdumpoct - dump octeon regsdumpstats - dump cavium statsecho - echo args to consoleeeprom - EEPROM sub-systemerase - erase FLASH memoryfatinfo - print information about filesystemfatload - load binary file from a dos filesystemfatls - list files in a directory (default /)flinfo - print FLASH memory informationgo - start application at address 'addr'gpio - read/write on gpio pinshelp - print online helpi2c - read/write on i2c busid_eeprom - peek/poke EEPROMide - IDE sub-systemiminfo - print header information for application imageimls - list all images found in flashitest - return true/false on integer compareloadb - load binary file over serial line (kermit mode)loads - load S-Record file over serial lineloady - load binary file over serial line (ymodem mode)loop - infinite loop on address rangels609x_read_reg - Read 88E6097 registermd - memory displaymdkinit - start MDKmm - memory modify (auto-incrementing)mtest - simple RAM testmw - memory write (fill)nfs - boot image via network using NFS protocolnm - memory modify (constant address)pci - list and access PCI Configuration Spacepciemd - pcie memory displaypciemw - pcie memory writepciereset - do PCIE resetping - send ICMP ECHO_REQUEST to network hostprintenv- print environment variablesprotect - enable or disable FLASH write protectionrarpboot- boot image via network using RARP/TFTP protocolread64 - read 64 bit word from 64 bit addressread64b - read 8 bit word from 64 bit addressread64l - read 32 bit word from 64 bit addressread_cmp - read and compare memory to valreset - Perform RESET of the CPUrun - run commands in an environment variablesaveenv - save environment variables to persistent storagesetenv - set environment variablessleep - delay execution for some timesmi - peek/poke SMI devicestftpboot- boot image via network using TFTP protocolusb - USB sub-systemusbboot - boot from USB deviceversion - print monitor versionwatchdog <start | stop | show | pat>write64 - write 64 bit word to 64 bit addresswrite64b - write 8 bit word to 64 bit addresswrite64l - write 32 bit word to 64 bit address
finally able to recover this device using the info in KB14175
The trick is getting the files : "u-boot-crc.bin" and "loader_crc.bin" from support.
After getting these files and using TFTP to re-install the loader, able to get the unit running and on 10.0R2.10
Still slow boot times by comparison to other vendors, but getting better ....
where did you get these files from?
JTAC provided them to me
'loader' and 'uboot' are also in the /boot directory of the junos-boot archive located within the junos archive.
Re: boot and upgrade times, it was internally acknowledged at Juniper that the boot and upgrade times were getting out of hand (particularly for the 210, which has the slowest processor in the branch family). Starting in 10.0 there was an effort to improve performance; I just heard that an update from 10.4R1 to 10.4R2 on an SRX100 was less than 5 minutes - haven't tested that myself, but even if it's just in the ballpark of that then it's still much better than the 9.x and early 10.x upgrades. Boot times are also supposed to be faster with the newer code.
I believe that going from 9.6 to 10.x gives you dual root partitions. Thus time is needed to format and install junos on the secondary image when taking this path. Of course dual root has plenty of advantages that other manufactors cannot claim, it certainly can save your butt in certain situations, it has here! Long boot times for a nice stable firewall is a good tradeoff right?
@gxc11 wrote:I believe that going from 9.6 to 10.x gives you dual root partitions. Thus time is needed to format and install junos on the secondary image when taking this path. Of course dual root has plenty of advantages that other manufactors cannot claim, it certainly can save your butt in certain situations, it has here! Long boot times for a nice stable firewall is a good tradeoff right?
I wholeheartedly agree, we're talking enterprise gear, not Linksys routers! Since 10.1R3 the only times my Juniper has gone down are because of power outages or firmware upgrades. With that sort of uptime taking five minutes to boot doesn't really bother me.
I had the same issue and I was able to "tar zxvf" the SRX Junos image and copy "loader" and "uboot" from /boot. I had to rename "uboot" to "u-boot-crc.bin" and "loader" to "loader_crc"
I then simply followed the instructions on KB14175 and it worked like a charm. No need to RMA it.
I have the same problem now.
U-Boot 1.1.6-JNPR-1.7 (Build time: May 4 2010 - 06:59:58)
SRX_210_HIGHMEM board revision major:0, minor:28, serial #: *******
OCTEON CN5020-SCP pass 1.1, Core clock: 400 MHz, DDR clock: 200 MHz (400 Mhz data rate)DRAM: 1024 MBStarting Memory POST...Checking datalines... OKChecking address lines... OKChecking 512K memory for U-Boot... OK.Running U-Boot CRC Test... OK.Flash: 4 MBUSB: scanning bus for devices... 4 USB Device(s) found scanning bus for storage devices... 2 Storage Device(s) foundClearing DRAM........ doneBIST check passed.Starting PCIPCI Status: PCI 32-bitPCI BAR 0: 0xf8000000, PCI BAR 1: Memory 0x00000000 PCI 0x00000000Boot Media: nand-flash usbNet: octeth0POST PassedPress SPACE to abort autoboot in 1 seconds=>
How can I fix this ?