SRX

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

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

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

Hi,

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

Regards,

Santhi

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 #: 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

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

hi Steve,

where did you get these files from?

loader_crc
u-boot-crc.bin

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.

mawr

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.

Hi

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 MB
Starting Memory POST...
Checking datalines... OK
Checking address lines... OK
Checking 512K memory for U-Boot... OK.
Running U-Boot CRC Test... OK.
Flash:  4 MB
USB:   scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 2 Storage Device(s) found
Clearing DRAM........ done
BIST check passed.
Starting PCI
PCI Status: PCI 32-bit
PCI BAR 0: 0xf8000000, PCI BAR 1: Memory 0x00000000  PCI 0x00000000
Boot Media: nand-flash usb
Net:   octeth0
POST Passed
Press SPACE to abort autoboot in 1 seconds
=>

How can I fix this ?

Thank You