Showing posts with label Juniper. Show all posts
Showing posts with label Juniper. Show all posts

Monday, February 12, 2018

Configure a RMA-ed SRX340 with a JunOS Upgrade and Joining it into a Existing Cluster

My previous post (Juniper SRX DB mode (Debug mode)) described a situation which is one of firewall cluster members got stuck into DB mode. Although it was fixed eventually by re-installed image, it was still failed again after a couple of months.

RMA ticket created with vendor Juniper and a new device was issued by Juniper. This post recorded all steps how to configure this new device and re-joined it back into existing cluster.

The all steps are quite straightforward. You may meet some file transferring issues or connectivity issues, but as long as you know your environment enough, those will be easily resolved if you followed all steps listed below.

Similar posts are in this  blog:

Notes: before let new cluster member join into existing cluster, please make sure one thing:
Disable IDP feature on existing Chassis cluster. Else your new cluster member will fail to join into existing cluster  and get into disabled mode. Fabric interface will show down status because new cluster member could not take your IDP configuration since it does not have IDP license and Signature Database.

Sunday, January 21, 2018

Enable IDP on Juniper SRX Devices Managed by Juniper Space

An Intrusion Detection and Prevention (IDP) policy lets you selectively enforce various attack detection and prevention techniques on the network traffic passing through your SRX Series. The SRX Series offer the same set of IDP signatures that are available on Juniper Networks IDP Series Intrusion Detection and Prevention Appliances to secure networks against attacks. The basic IDP configuration involves the following tasks:

  • Download and install the IDP license.
  • Download and install the signature database—You must download and install the IDP signature database. The signature databases are available as a security package on the Juniper Networks website. This database includes attack object and attack object groups that you can use in IDP policies to match traffic against known attacks.
  • Configure recommended policy as the IDP policy—Juniper Networks provides predefined policy templates to use as a starting point for creating your own policies. Each template is a set of rules of a specific rulebase type that you can copy and then update according to your requirements.
  • To get started, we recommend you use the predefined policy named “Recommended”.
  • Enable a security policy for IDP inspection—For transit traffic to pass through IDP inspection, you configure a security policy and enable IDP application services on all traffic that you want to inspect.
1. License

Juniper Support has some License Management Online Tools available on their website:


Click https://lms.juniper.net/lcrs/license.do should get you the classic Generate Licenses, but for newer hardware, it has been moved to new site: https://license.juniper.net/licensemanage


Wednesday, November 15, 2017

Juniper SRX Commnit Error "No rulebase configured for active policy"

I have been dealing with Juniper SRX IDP error many times when NSM was been used. Mostly those errors are caused by corrupted signature DB or not enough storage space on SRX itself. Here is the latest one I encountered.

Symptoms
From Space, if I make a new change on firewall policy and push it to gateway, I will get following errors.


Thursday, October 19, 2017

Juniper SRX DB mode (Debug mode)

During our regular maintenance, after rebooted one SRX345, and found it stuck at db mode, which is debug mode.

After a short and quick analysis, I found Juniper JunOS devices may get stuck in the boot process or fail to boot the OS, in rare cases, after a sudden power loss or ungraceful power shut down. Juniper  routers, switches and firewalls  can experience file system corruption, which prevents the device from recovering to a functional state. It is recommended that customers minimize their log configurations to prevent excessive read/writes to the file system, which reduces the stress on storage media and reduces the potential occurrence of this issue. Moreover, if abrupt power failures are transient for a very short period of time, the availability of an UPS can also prevent the device from experiencing a sudden power loss.

You do not have to worry about damaging hardware in these situations, as the hardware cannot tell the difference between a graceful shutdown and pulling the power cord. The potential for damage is with the file system structure. It is possible for data to be corrupted, when the computer's power is interrupted with the operating system running. The data could be in the nodes, which could result in files being lost or file contents being corrupted.

Although rare, this issue more likely occurs on platforms that use a UNIX/BSD-based operating system, such as Junos, to access the flash-based storage media.

“Although rare, file system damage can occur with an abrupt power off, which may cause problems on the next boot. Use the request system halt or request system reboot command to gracefully shut down or reboot the OS. Once the OS is halted, it is safe to remove power.”  - from O'Reilly Media’s JUNOS Enterprise Switching book.

There are a couple of KB discussing the fix. KB29811 is using a USB to copy a snapshot from healthy device to faulty device. KB20046  suggest to press space to go to u-boot prompt and enter some commands to fix issue.



db> help
    DDB Quick Help  
  -------------------  
Type 'c' to continue, 'reset' or 'panic' to restart. 

print       p           examine     x           search      set         write       
w           delete      d           break       dwatch      watch       dhwatch     
hwatch      step        s           continue    c           until       next        
match       trace       alltrace    where       bt          call        show        
ps          gdb         reset       kill        watchdog    thread      panic       
ddbdumpsys  dumpsys     
db> reset


Friday, September 8, 2017

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
[email protected]> 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.

Thursday, March 30, 2017

Juniper Space License Issue on Citrix Xen Environment

Based on Juniper "Junos Space Virtual Appliance Installation and Configuration Guide" , JunOS Space " must deploy the virtual appliance on a VMware ESX, VMWare ESXi or KVM server, which provides a CPU, hard disk, RAM, and a network controller, but requires installation of an operating system and applications to become fully functional."

In my test environment, one JunOS Space has been installed on Citrix Xen environment and it is working fine until we tried to import a license.

The license was generated from Juniper License site and emailed to us in a txt file. It used to work on another machine hosted in Vmware ESX environment. Unfortunately, this time, JunOS Space said no.

The License Information windows says:
License upload failed. Please check the following:
1) License data format
2) License Keys
Juniper Space VE at Citrix Xen Server - License Error



Thursday, March 23, 2017

Add Juniper SRX Cluster into JunOS Space 16.1 Security Director

My old post "Import Existing Juniper SRX Cluster into JunOS Space Security Director" was created based on Space 14.1 and SRX11.x version. Now both have been upgraded. Space NMP and Security Director have been upgrade to 16.1 (Post is here). SRX240H has been upgrade to 12.1D46.55.

Basically, all steps are similar except the web interface is different. What you need to do is to configure your SRX cluster with a master-only ip on both nodes. The configuration should looks like this:

Wednesday, March 22, 2017

Juniper JUNOS Commands (Tips and Tricks)

Juniper Networks has a Day one book for 'JunOS Tips, Techniques, and Templates 2011' in Junos Fundamentals Series. To record some my own tips, I put them together in this post. Let me know if you have some more to share.

1.  Find big size files 

find . -type f -size +10000 -exec ls -lh {} \; 


[email protected]% find . -type f -size +10000 -exec ls -lh {} \;
-rw-r--r--  1 930  929   134M Jan  5 17:34 ./cf/packages/junos-11.4R6.6-domestic
-rw-r--r--  1 root  wheel   139M Sep  8  2011 ./cf/var/log/junos-srxsme-11.2R2.4-domestic.tgz
-rw-r-----  1 root  wheel   4.9M Feb 11 17:12 ./cf/var/db/idpd/db/secdb_02.db
-rw-r-----  1 root  wheel   6.7M Feb 11 17:13 ./cf/var/db/idpd/db/secdb_03.db
-rw-r-----  1 root  wheel    64M Feb 11 17:13 ./cf/var/db/idpd/db/secdb_06.db
-rwxr-xr-x  1 admin  20    24M May 23 08:38 ./cf/var/db/idpd/nsm-download/SignatureUpdate.xml
-r-xr-xr-x  1 root  wheel   5.2M Jan  5 17:33 ./jail/html/dynamic-vpn/client/jam/InstallerComponentSRX.exe
-rw-r--r--  1 root  wheel   139M Sep  8  2011 ./jail/var/log/junos-srxsme-11.2R2.4-domestic.tgz
-rw-r-----  1 root  config    14M Feb  8 22:16 ./mfs/var/run/db/schema.db
-rw-r-----  1 root  wheel    10M Feb  8 22:19 ./mfs/var/sdb/log.0000000001
-r--r--r--  1 root  wheel   6.5M Jan  5 13:59 ./usr/lib/dd/libjkernel-dd.so
-r-xr-xr-x  1 root  wheel    13M Jan  5 15:39 ./usr/sbin/authd
-r-xr-xr-x  1 root  wheel   6.0M Jan  5 16:51 ./usr/sbin/chassisd
-r-xr-xr-x  1 root  wheel    27M Jan  5 13:05 ./usr/sbin/flowd_octeon
-r-xr-xr-x  1 root  wheel    34M Jan  5 13:05 ./usr/sbin/flowd_octeon_hm
-r-xr-xr-x  1 root  wheel   5.5M Jan  5 16:51 ./usr/sbin/kmd
-r-xr-xr-x  1 root  wheel    13M Jan  5 16:24 ./usr/sbin/rpd

% find / -size +100000 | xargs ls -lhS
find: /mfs/var/spool/opielocks: Permission denied
-rw-r--r--  1 930   929     142M Aug 28  2014 /cf/packages/junos-12.1X44-D40.2-domestic
-rw-r-----  1 root  wheel    84M Feb 23 21:31 /cf/var/db/idpd/db/secdb_06.db


Tuesday, March 21, 2017

JunOS Space Network Management Platform Basic Configuration including Log Collector

JunOS Space is in my environment and starting to replace NSM. I have played with in testing lab which recorded in my previous posts:
In this post, I will focus on more regarding JunOS Space itself, some basic configuration to get JunOS space into your production environment.

Notes: Recently Space has been upgraded from 14.1 to 16.1 with my post: Juniper JunOS Space Upgrade Procedures from 14.1 to 16.1. The installation and configuration steps for 16.1 is similar as 14.1. This post is updated during configuring JunOS Space 16.1.

Juniper JunOS Space Upgrade Procedures from 14.1 to 16.1

Usually you can easily upgrade an application from the Junos Space user interface. You must download the image file for the new version of the application, navigate to the Applications page (Network Management Platform > Administration > Applications) and select the application that you want to upgrade. From the right-click menu, choose Upgrade Application to upload the image file into Junos Space via HTTP or SCP.

But upgrade JunOS Space to latest version 16.1 is different and it is not a easy task. There are many steps to follow especially the last step to upgrade to 16.1 from 15.2R2. Here is my recent upgrade procedures.

Steps to upgrade JunOS Space 14.1  to the latest version 16.1:

Monday, November 28, 2016

Procedures to Deploy RMA device into Juniper SRX Chassis Cluster

Juniper KB mentioned some RMA steps for failed Juniper device replacement. There are some steps not clear enough. I put some more configuration steps in this post for future reference:

There are many preparation works before you can add RMA device into your chassis group.


Saturday, November 26, 2016

Juniper Firewall SRX240H Crashed with Error 'nearing maxproc limit by uid 0,please see tuning(7) and login.conf(5)'

One of Juniper Firewall SRX240H had a serious crash. Manual reboot/shutdown did not work. To reset it, I would have to do a hard reset / power cycle device.

It would allow to log in from console, but you wont be able to see any configuration.

Here is outputs from this crashed Juniper SRX240H console:


Wednesday, October 26, 2016

Juniper SRX340 HA Cluster Configuraiton

The SRX340 Services Gateway has a capacity of 3 gigabits per second (Gbps) and is 1 rack unit (U) tall. This services gateway has eight 1 G Ethernet ports, eight 1 G SFP ports, one management port, 4 GB of DRAM memory, 8 GB of flash memory, and four Mini-Physical Interface Module (Mini-PIM) slots.

SRX 340 Front Panel

SRX 340 Back Panel














The connection is a little different from SRX 240 and 1400. Here are some related posts:

Wednesday, August 10, 2016

JunOS SRX Cluster Upgrade Failed


For SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, command introduced in Junos OS Release 9.6 and support for reboot as a required parameter added in Junos OS Release 11.2R2. For SRX100, SRX210, SRX220, SRX240, and SRX650 devices, command introduced in Junos OS Release 11.2R2. For SRX5400 devices, the command is introduced in Junos OS Release 12.1X46-D20.

Symptoms: 

Symptom 1: "tar: Archive contains obsolescent base-64 headers"

[email protected]> request system software add no-copy /var/tmp/junos-srxsme-12.1X44-D40.2-domestic.tgz no-validate 
Formatting alternate root (/dev/da0s2a)...
/dev/da0s2a: 627.4MB (1284940 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 156.86MB, 10039 blks, 20096 inodes.
super-block backups (for fsck -b #) at:
 32, 321280, 642528, 963776
Extracting /var/tmp/junos-srxsme-12.1X44-D40.2-domestic.tgz ...
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
ERROR: Failed to extract /var/tmp/junos-srxsme-12.1X44-D40.2-domestic.tgz to /altroot/cf/packages/install-tmp/junos-12.1X44-D40.2-domestic

Sunday, January 17, 2016

Juniper SRX Minor Alarm Messages - Autorecovery and Rescue Information

During working on Juniper products, such as SRX, NSM and Space, sometimes, there are minor alarms in the system and it requires some actions to clear those alarms based on different situation.

Symptoms:

Here are some minor alarms I met during working on Juniper products.

1.  Autorecovery has recovered corrupted information

Tuesday, January 12, 2016

JunOS Space - Warning Message for Consolidated Configuration

Junos Space is a comprehensive network management solution that simplifies and automates management of Juniper’s switching, routing, and security devices. To those security administrator who like command line, they will still prefer to use command line to change certain things such as host name, routes, system configuration etc. Juniper call it out-of-band commit since it happens at device itself, not from JunOS Space. Usually the JunOS space will auto-synchronize the JunOS Space configuration database with device configuration.

Tuesday, December 15, 2015

Understanding Juniper SRX TCP Security Check

Juniper SRX is a stateful firewall and allows traffic which matches an existing session. Sessions are created when a TCP SYN packet is received and it is permitted by the security policy. This of course means that the firewall needs to see both directions of a flow (client-server and server-client), otherwise these checks will block legitimate packets.

Following flow chart illustrates packet flow sequences both when SYN flag checking is enabled and when it is disabled.
SYN Flag Checking

By default, security TCP check is enabled on all TCP flow sessions. The Junos operating system (Junos OS) performs the following operations during TCP sessions:

  • Checks for SYN flags in the first packet of a session and rejects any TCP segments with non- SYN flags that attempt to initiate a session.
  • Validates the TCP sequence numbers during stateful inspection.

Reset packet is turned off for non-SYN session TCP packets:
{primary:node0}
[email protected]> show security zones
node0:
--------------------------------------------------------------------------

Security zone: MGMT1
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Interfaces bound: 1
  Interfaces:
    reth4.201

Security zone: TSMGMT
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Interfaces bound: 1
  Interfaces:
    reth4.198

Security zone: MGMT2
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Interfaces bound: 1
  Interfaces:
    reth3.0
We can enable reset packets when received non-syn tcp session packets.
{primary:node0}[edit]
[email protected]# set security zones security-zone MGMT1 tcp-rst

{primary:node0}[edit]
[email protected]# set security zones security-zone TSMGMT tcp-rst

{primary:node0}[edit]
[email protected]# set security zones security-zone MGMT tcp-rst        

Check the settings again:
[email protected]> show security zones 
node0:
--------------------------------------------------------------------------

Security zone: MGMT1
  Send reset for non-SYN session TCP packets: On
  Policy configurable: Yes  
  Interfaces bound: 1
  Interfaces:
    reth4.201

Security zone: TSMGMT
  Send reset for non-SYN session TCP packets: On
  Policy configurable: Yes  
  Interfaces bound: 1
  Interfaces:
    reth4.198

Security zone: MGMT2
  Send reset for non-SYN session TCP packets: On
  Policy configurable: Yes  
  Interfaces bound: 1
  Interfaces:reth3.0


Junos OS provides a mechanism for disabling security checks on TCP packets to ensure interoperability with hosts and devices with faulty TCP implementations. During no-SYN-check the Junos OS does not look for the TCP SYN packet for session creation. No-sequence check disables TCP sequence checking validation. Also, increases throughput. SYN check and sequence check are enabled by default. The set security flow command disables TCP SYN checks and TCP sequence checks on all TCP sessions thus reduces security. This may be required in scenarios with customers like big transfer files, or with applications that do not correctly work with standards.

Another reason to disable syn-check and sequence-check is the asymmetric flows in your environment. It is best, whenever possible, to ensure that asymmetric flows do not occur; but this is not always possible. So, you can disable these checks globally on the SRX device.

To disable TCP packet security checks:
set security flow tcp-session no-syn-check
set security flow tcp-session no-sequence-check

After you disabled the tcp options, tcp-syn-check, and tcp-sequence-check that are configured at global level, you might want to configure TCP packet security checks at the policy level.

Note: Disabling the global SYN check and enforcing the SYN check after policy search will greatly impact the number of packets that the router can process. This in turn will result in intense CPU operations.

Configure the checking for the TCP SYN bit before creating a session:
[edit]
[email protected]# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options syn-check-required

Configure the checking for sequence numbers in TCP segments during stateful inspection:
[edit]
[email protected]# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options sequence-check-required

It is also possible to disable TCP SYN or sequence checking on one policy and enable them on all other policies, an apply-group can be used to complete this configuration based on KB24566.


Reference:



Thursday, December 10, 2015

Juniper SRX Logging Methods and Configuration: Stream Mode vs Event Mode

JunOS has strong flexibility on many features. One of them is logging. It support flexible logging options. This post summarizes some concepts I learned from my work and studying.

1.Understand Juniper SRX logging Type:

1.1 System Logging

Junos OS supports configuring and monitoring of system log messages (also called syslog messages). You can configure files to log system messages and also assign attributes, such as severity levels, to messages. Reboot requests are recorded to the system log files, which you can view with the show log command. SRX Series devices can send system log messages from the control plane (Routing Engine) to one or more destinations. Destinations can include local files on the SRX Series device (because the SRX Series device is a syslog server), remote syslog servers, user terminals, and the system console.


[email protected]> show configuration system syslog
archive size 750k files 2;
user * {
    any emergency;
}
host 10.9.0.33 {
    any any;
    change-log none;
    interactive-commands none;
    explicit-priority;
}
host 10.9.8.52 {
    any any;
    source-address 10.9.8.20;
}
file messages {
    any critical;
    authorization info;
    explicit-priority;
}
file interactive-commands {
    interactive-commands error;
}
}


Sunday, September 20, 2015

SRX Load Rescue Configuration After Reboot

It did not happen often, but when it happened, you will need to know how to fix it.


The rescue configuration is a previously committed, valid configuration. You must have previously set the rescue configuration through the J-Web interface or the CLI.

[email protected]> request system configuration rescue save 

[email protected]> show system configuration rescue 



During today's work, one of SRX firewalls got a problem to load regular configuration file, and it loaded rescue configuration. Here is what the console output told me:



*** FINAL System shutdown message from [email protected] ***           

System going down IMMEDIATELY                                                  

                                                                          


{secondary:node1}

[email protected]> Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done

syncing disks... All buffers synced.

Uptime: 32m35s
Rebooting...
cpu_reset: Stopping other CPUs


U-Boot 1.1.6-JNPR-1.7 (Build time: May  4 2010 - 06:59:58)


SRX_240_HIGHMEM board revision major:1, minor:50, serial #: AAEK3334

OCTEON CN5230R-SCP pass 2.0, Core clock: 600 MHz, DDR clock: 333 MHz (666 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... 
Root Hub 0: 3 USB Device(s) found
Root Hub 1: 1 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Clearing DRAM........ done
BIST check passed.
1:00:00.0 Vendor/Device ID = 0x811210b5
1:01:07.0 Vendor/Device ID = 0xc72414e4
Boot Media: nand-flash usb 
Net:   octeth0
POST Passed
Press SPACE to abort autoboot in 1 seconds
ELF file is 32 bit
Loading .text @ 0x8f000078 (246092 bytes)
Loading .rodata @ 0x8f03c1c4 (13940 bytes)
Loading .rodata.str1.4 @ 0x8f03f838 (16580 bytes)
Loading set_Xcommand_set @ 0x8f0438fc (104 bytes)
Loading .rodata.cst4 @ 0x8f043964 (20 bytes)
Loading .data @ 0x8f044000 (5620 bytes)
Loading .data.rel.ro @ 0x8f0455f4 (120 bytes)
Loading .data.rel @ 0x8f04566c (136 bytes)
Clearing .bss @ 0x8f0456f8 (11912 bytes)
## Starting application at 0x8f000078 ...
Consoles: U-Boot console  
Found compatible API, ver. 1.7

FreeBSD/MIPS U-Boot bootstrap loader, Revision 1.7

([email protected], Tue May  4 07:15:51 UTC 2010)
Memory: 1024MB
[0]Booting from nand-flash slice 1
Un-Protected 1 sectors
writing to flash...
Protected 1 sectors
Loading /boot/defaults/loader.conf 
/kernel data=0xb0567c+0x134494 syms=[0x4+0x8aa50+0x4+0xc8fc6]


Hit [Enter] to boot immediately, or space bar for command prompt.

Booting [/kernel]...               
Kernel entry at 0x801000e0 ...
init regular console
Primary ICache: Sets 64 Size 128 Asso 4
Primary DCache: Sets 1 Size 128 Asso 64
Secondary DCache: Sets 512 Size 128 Asso 8
GDB: debug ports: uart
GDB: current port: uart
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
kld_map_v: 0x8ff80000, kld_map_p: 0x0
Copyright (c) 1996-2014, Juniper Networks, Inc.
All rights reserved.
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
JUNOS 12.1X44-D40.2 #0: 2014-08-28 12:20:14 UTC
    [email protected]:/volume/build/junos/12.1/service/12.1X44-D40.2/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel
JUNOS 12.1X44-D40.2 #0: 2014-08-28 12:20:14 UTC
    [email protected]:/volume/build/junos/12.1/service/12.1X44-D40.2/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel
real memory  = 1073741824 (1024MB)
avail memory = 526438400 (502MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
Security policy loaded: JUNOS MAC/pcap (mac_pcap)
Security policy loaded: JUNOS MAC/runasnonroot (mac_runasnonroot)
netisr_init: !debug_mpsafenet, forcing maxthreads from 4 to 1
cpu0 on motherboard
: CAVIUM's OCTEON 52XX CPU Rev. 0.8 with no FPU implemented
        L1 Cache: I size 32kb(128 line), D size 8kb(128 line), sixty four way.
        L2 Cache: Size 512kb, 8 way
obio0 on motherboard
uart0: <Octeon-16550 channel 0> on obio0
uart0: console (9600,n,8,1)
twsi0 on obio0
dwc0: <Synopsis DWC OTG Controller Driver> on obio0
usb0: <USB Bus for DWC OTG Controller> on dwc0
usb0: USB revision 2.0
uhub0: vendor 0x0000 DWC OTG root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
uhub1: vendor 0x0409 product 0x005a, class 9/0, rev 2.00/1.00, addr 2
uhub1: single transaction translator
uhub1: 3 ports with 2 removable, self powered
umass0: STMicroelectronics ST72682  High Speed Mode, rev 2.00/2.10, addr 3
dwc1: <Synopsis DWC OTG Controller Driver> on obio0
usb1: <USB Bus for DWC OTG Controller> on dwc1
usb1: USB revision 2.0
uhub2: vendor 0x0000 DWC OTG root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 1 port with 1 removable, self powered
cpld0 on obio0
pcib1: <Cavium on-chip PCIe HOST bridge> on obio0
Disabling Octeon big bar support
PCIe: Waiting for port 0 to finish reset
PCIe: Port 0 link active, 2 lanes
PCIe: Waiting for port 1 to finish reset
PCIe: Port 1 link active, 1 lanes
pcib1: Initialized controller
pci0: <PCI bus> on pcib1
pcib2: <PCI-PCI bridge> irq 0 at device 0.0 on pci0
pci1: <PCI bus> on pcib2
pci1: <serial bus, USB> at device 2.0 (no driver attached)
pci1: <network> at device 7.0 (no driver attached)
pcib0: <Cavium on-chip PCIe HOST bridge> on obio0
pci2: <PCI bus> on pcib0
pci2: <processor> at device 0.0 (no driver attached)
gblmem0 on obio0
octpkt0: <Octeon RGMII> on obio0
cfi0: <AMD/Fujitsu - 4MB> on obio0
Timecounter "mips" frequency 600000000 Hz quality 0
###PCB Group initialized for udppcbgroup
###PCB Group initialized for tcppcbgroup
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <ST ST72682 2.10> Removable Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 1000MB (2048000 512 byte sectors: 64H 32S/T 1000C)
Trying to mount root from ufs:/dev/da0s1a
Attaching /cf/packages/junos via /dev/mdctl...
Mounted junos package on /dev/md0...

Media check on da0

Zone 04 Block 0499 Addr 11f300 : Bad read
Recovering Block
Automatic reboot in progress...
** /dev/da0s1a
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
250 files, 75946 used, 73580 free (28 frags, 9194 blocks, 0.0% fragmentation)
Verified junos signed by PackageProduction_12_1_0
Verified jboot signed by PackageProduction_12_1_0
Verified junos-12.1X44-D40.2-domestic signed by PackageProduction_12_1_0
Checking integrity of BSD labels:
  s1: Passed
  s2: Passed
  s3: Passed
  s4: Passed
** /dev/bo0s3e
** Last Mounted on /config
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
28 files, 52 used, 12386 free (10 frags, 1547 blocks, 0.1% fragmentation)
** /dev/bo0s3f
** Last Mounted on /cf/var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
616 files, 98342 used, 76976 free (544 frags, 9554 blocks, 0.3% fragmentation)
Checking integrity of licenses:
  JUNOS137657.lic: Passed
  JUNOS187398.lic: Passed
  JUNOS187665.lic: Passed
  JUNOS628672.lic: Passed
Checking integrity of configuration:
  rescue.conf.gz: Passed
Loading configuration ...
mgd: error: Cannot open configuration file: /config/juniper.conf
mgd: warning: loading configuration from /config/rescue.conf.gz
Time and ticks drifted too much,             resetting synchronization...
mgd: commit complete
Setting initial options: .
Starting optional daemons:  usbd.
Doing initial network setup:.
Initial interface configuration:
additional daemons: eventd.
Additional routing options:kern.module_path: /boot//kernel;/boot/modules -> /boot/modules;/modules/ifpfe_drv;/modules;
kld netpfe drv: ifpfed_dialer.
Doing additional network setup:.
Starting final network daemons:.
setting ldconfig path: /usr/lib /opt/lib
starting standard daemons: cron.
Initial rc.mips initialization:.
Local package initialization:.
starting local daemons:set cores for group access
.
kern.securelevel: -1 -> 1
Creating JAIL MFS partition...
JAIL MFS partition created
boot.upgrade.uboot="0xBFC00000"
boot.upgrade.loader="0xBFE00000"
Boot media /dev/da0 has dual root support
WARNING: JUNOS versions running on dual partitions are not same
** /dev/da0s2a
** Last Mounted on /mfs/tmp/snap-tmp.1334/mnt.1334
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
250 files, 75914 used, 74124 free (28 frags, 9262 blocks, 0.0% fragmentation)
Sun Sep 20 17:48:34 UTC 2015

fw-srx-2 (ttyu0)


login: 

For somehow, the regular configuration could not be loaded, and system used rescue configuration instead.

Fix is quite simple. Made a little change to configuration and commit it to generate a new configuration. Reboot and this time console showed the regular configuration loaded successfully:



Checking integrity of licenses:

  JUNOS137657.lic: Passed
  JUNOS187398.lic: Passed
  JUNOS187665.lic: Passed
  JUNOS628672.lic: Passed
Checking integrity of configuration:
  rescue.conf.gz: Passed
Loading configuration ...
mgd: commit complete
Setting initial options: .


Thursday, September 17, 2015

Import Existing Juniper SRX Cluster into JunOS Space Security Director

This instruction is made to those new to JunOS Space and Security Director. The whole procedures are easy to understand with those screenshots and real example.

This is also the last one for my whole series of posts regarding JunOS Space

1. Add both cluster member's fxp0.0 (mgmt interface) IP addresses into JunOS Space

Go to Network Management Platform -> Devices -> Discover Targets, click + icon to add IP address int Device Target