SRX210 Boot Times

[#1]

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.

[#2]

I have 4 srx-210 devices deployed so far and I have noticed the same issue.

[#3]

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.

[#4]

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

Times:

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 ...

[#5]

Hi,

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

[#6]

Hi,

I am also facing the same problem. Please find out what is the bug

Regards,

Santhi

[#7]

Hi, I have the same problem. I installed the 9.6 R2 but the problem persist. It's really slow equipment

[#8]

It is a common thing on all the SRX branch products. There does not seem to be any plan to improve this.

[#9]

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 #: AAAJ6812
OCTEON CN5020-SCP pass 1.1, Core clock: 400 MHz, DDR clock: 200 MHz (400 Mhz data rate)
DRAM:  1024 MB
Flash:  4 MB
USB:   scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 2 Storage Device(s) found
POST Passed
Clearing DRAM........ done
BIST check passed.
Starting PCI
PCI Status: PCI 32-bit
PCI BAR 0: 0xf8000000, PCI BAR 1: Memory 0x00000000  PCI 0x00000000
Net:   octeth0
Press SPACE to abort autoboot in 1 seconds
## No elf image at address 0x00100000
=>
?       - alias for 'help'
askenv  - get environment variables from stdin
autoscr - run script from memory
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootloader - upgrade u-boot
bootloader - upgrade loader
bootloader - upgrade ushell
bootloader - upgrade flash
bootloader - check u-boot
bootloader - check loader
bootm   - boot application image from memory
bootoct - Boot from an Octeon Executive ELF image in memory
bootoctelf - 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 memory
bootp   - boot image via network using BootP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
cpld     - peek/poke CPLD
crc32   - checksum calculation
dhcp    - invoke DHCP client to obtain IP/boot params
dumpoct      - dump octeon regs
dumpstats    - dump cavium stats
echo    - echo args to console
eeprom  - EEPROM sub-system
erase   - erase FLASH memory
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
flinfo  - print FLASH memory information
go      - start application at address 'addr'
gpio - read/write on gpio pins
help    - print online help
i2c - read/write on i2c bus
id_eeprom     - peek/poke EEPROM
ide     - IDE sub-system
iminfo  - print header information for application image
imls    - list all images found in flash
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls609x_read_reg - Read 88E6097 register
md      - memory display
mdkinit      - start MDK
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
pci     - list and access PCI Configuration Space
pciemd      - pcie memory display
pciemw      - pcie memory write
pciereset      - do PCIE reset
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
read64    - read 64 bit word from 64 bit address
read64b    - read 8 bit word from 64 bit address
read64l    - read 32 bit word from 64 bit address
read_cmp    - read and compare memory to val
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sleep   - delay execution for some time
smi     - peek/poke SMI devices
tftpboot- boot image via network using TFTP protocol
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version
watchdog <start | stop | show | pat>
write64    - write 64 bit word to 64 bit address
write64b    - write 8 bit word to 64 bit address
write64l    - write 32 bit word to 64 bit address