Juniper OS recovery

Juniper switch or router can get a filesystem corrupted and won't boot.  You have to reinstall the OS using two options:

  • Load the OS via TFTP server
  • Load the OS from the USB stick

First, when the OS is booting and you see "Loading /boot/defaults/loader.conf" message, hit space bar key to get into the loader cli:

Then from here you can either install the OS from TFTP server. Lets assume, that the switch management port (172.16.50.100/24) is directly connected to ftp server (172.16.50.10/24). You need to configure the IP address on the switch and start the installation:

loader> set ipaddr=172.16.50.100 loader> set netmask=255.255.255.0 loader> set serverip=172.16.50.10 loader> install --format tftp://172.16.50.100/jinstall-xxx-signed.tgz

 

If you want to install the OS from the usb stick, you need to first format it using FAT32, copy the software, turn off the switch or router, insert the stick, turn the switch or router back on, get into the loader command line and run the following command:

loader> install --format file:///jinstall-xxx-signed.tgz

Good luck!

Installing the Junos EZ Library

This post follows on from my last post about the Junos EZ Library, Jeremy Schulman’s work to make Junos devices easily manageable via Python, even for those of us who are not hard core programmers by trade.

In order to run the Junos EZ library I had to prepare my Ubuntu system with a few pre-requisites. Jeremy’s first post talks about what’s required on his CentOS Developer Workstation; this post does the same for Ubuntu server.

Pre-Requisites

# Install the NETCONF 'ncclient' library:
pip-2.7 install git+https://github.com/Juniper/ncclient.git

# Install the Junos "EZ" library:
pip-2.7 install git+https://github.com/jeremyschulman/py-junos-eznc.git

But hold on, because those commands need other things to be in place in order to succeed. At the very least, along with the above, you will need Python 2.7 and the “pip–2.7” tool. On my Ubuntu server, I had Python 2.7 installed, but the rest took a few more steps.

Read more

How to upgrade a SRX cluster with minimal downtime

Problem or Goal:

At no time can a cluster have mismatched code versions. This can result in network instability and unpredictable behavior. This means that to properly upgrade a cluster without ISSU (not supported on SRX Branch devices), you would need to ensure that both nodes are rebooted and do not attempt to connect to each other with different Junos code versions.

Zero downtime is not currently possible on SRX clusters. The goal of this article is to provide a means to upgrade an SRX cluster with the minimum amount of downtime possible. The following events can be expected during this process:

  • All sessions, which have network address translation, will be lost.

  • All sessions utilizing ALG (Like FTP, SIP, and so on) will be lost.

  • Dynamic routing protocol adjacencies will need to be re-established upon failover between the devices.

  • All other existing sessions will be able to fail between devices.

  • Depending on the network configuration, traffic will failover between devices with mimimal packet loss.
Read more

SRX240 cluster management interface

You've discovered one of the more aggravating "features" of the SRX products.  The fxp0 interfaces become "out of band" management, and I use the quotes because Juniper has a very different opinion of what "out of band" means than many other manufacturers and customers.  Personally I think it's an incredibly impractical way to do management, and I don't even use fxp0 interfaces on my clusters because I can't stand the way Juniper thinks they should work.

Read more

Rib groups - export-rib VS import-rib

There is alot of confusion regarding the subject. In order to better understand the difference I will perform several tests with both RIB types.

First, we will test export-rib. Juniper’s KB16133 defines the export-rib as such:

“The export-rib command tells the router, from which tables to take information. For any individual RIB group, only one table can be specified in the export-rib statement.”

This means that export-rib should only work with exchanging routes between two tables.

To test export-rib groups we will attempt the following configurations:

  1. Apply an export-rib group to a table to verify export-rib is working as intended
  2. Apply an export-rib group to the same table which it’s configured for
  3. Apply an export-rib group to multiple tables

Secondly, we will test import-rib. Juniper’s KB16133 defines the import-rib as such:

“Conversely, the import-rib command tells the router, into which tables to place information. Unlike its counterpart, the import-rib statement can specify multiple route tables.”

In the same KB article explains that the first routing table in an import-rib group is the source routing table and each subsequent routing table(s) are destination routing tables. This implies that the first routing table defined will be copied to the destination tables listed after. Jack Parks also concluded the same reasoning on the j-net forums.

To test import-rib groups we will attempt the following configurations.

  1. Apply an import-rib group to a table to verify it’s working as intended (include source and destination tables).
  2. Apply the import-rib group to the source table
  3. Only provide a source table but no destinations table
  4. Apply the import-rib to a different table than the source (a table not listed in the group)
  5. Define multiple destination tables in the group and assign the group to a single table
  6. Define multiple destination tables in the group and assign the group to a multiple table.
  7. Do routes that are present in the routing table because of a RIB group qualify to then be copied to another routing table?

If you're looking for the results, they're at the bottom of this post. Otherwise, continue on for a long winded post 

Initial configuration:

[edit]
root@srx-core# show interfaces
ge-0/0/0 {
    unit 0 {
        family inet {
            address 192.168.1.200/24;
        }
    }
}
ge-0/0/1 {
    vlan-tagging;
    unit 0 {
        vlan-id 200;
        family inet {
            address 10.100.0.1/24;
        }
    }
    unit 1 {
        vlan-id 201;
        family inet {
            address 10.101.1.254/24;
        }
    }
    unit 2 {
        vlan-id 202;
        family inet {
            address 10.101.2.254/24;
        }
    }
    unit 3 {
        vlan-id 203;
        family inet {
            address 10.101.3.254/24;
        }
    }
    unit 4 {
        vlan-id 204;
        family inet {
            address 10.101.4.254/24;
        }
    }
    unit 11 {
        vlan-id 11;
        family inet {
            address 172.16.1.1/24;
        }
    }
    unit 12 {
        vlan-id 12;
        family inet {
            address 172.16.2.1/24;
        }
    }
}
 
[edit]
root@srx-core# show routing-instances
test1 {
    instance-type virtual-router;
    interface ge-0/0/1.11;
}
test2 {
    instance-type virtual-router;
    interface ge-0/0/1.12;
}

Export-rib Test 1

Apply an export-rib group to a table to verify export-rib is working as intended

[edit]
root@srx-core# set routing-options rib-groups export-test export-rib test1.inet.0
 
[edit]
root@srx-core# set routing-instances test2 routing-options interface-routes rib-group inet export-test
 
[edit]
root@srx-core# commit
[edit routing-instances test2 routing-options interface-routes]
  'rib-group'
    export-test: primary rib for instance test2 was not found in ribgroup configuration.
error: configuration check-out failed

Well that’s strange. Let’s see if we can use the same group in the test1.inet.0 table

[edit]
root@srx-core# delete routing-instances test2 routing-options interface-routes rib-group inet export-test
 
[edit]
root@srx-core# set routing-instances test1 routing-options interface-routes rib-group inet export-test
 
[edit]
root@srx-core# commit
[edit routing-instances test1 routing-options interface-routes]
  'rib-group'
    export-test: primary rib for instance test1 was not found in ribgroup configuration.
error: configuration check-out failed
[edit]
root@srx-core# delete routing-instances test1 routing-options interface-routes rib-group inet export-test
 
[edit]
root@srx-core# set routing-options interface-routes rib-group inet export-test
 
[edit]
root@srx-core# commit
commit complete
 
Well it committed without errors. Let’s look at the routing tables and see what happened:
[edit]
root@srx-core# run show route table test1.inet.0
 
test1.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
172.16.1.0/24      *[Direct/0] 17:38:42
                    > via ge-0/0/1.11
172.16.1.1/32      *[Local/0] 17:38:42
                      Local via ge-0/0/1.11
 
[edit]
root@srx-core# run show route table inet.0
 
inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
 
10.0.0.0/24        *[OSPF/10] 21:43:04, metric 12
                    > to 192.168.1.1 via ge-0/0/0.0
10.0.1.16/28       *[OSPF/10] 21:43:04, metric 11
                    > to 192.168.1.1 via ge-0/0/0.0
10.100.0.0/24      *[Direct/0] 21:43:11
                    > via ge-0/0/1.0
10.100.0.1/32      *[Local/0] 21:43:13
                      Local via ge-0/0/1.0
10.101.1.0/24      *[Direct/0] 21:43:11
                    > via ge-0/0/1.1
10.101.1.254/32    *[Local/0] 21:43:13
                      Local via ge-0/0/1.1
10.101.2.0/24      *[Direct/0] 21:43:11
                    > via ge-0/0/1.2
10.101.2.254/32    *[Local/0] 21:43:13
                      Local via ge-0/0/1.2
10.101.3.0/24      *[Direct/0] 21:43:11
                    > via ge-0/0/1.3
10.101.3.254/32    *[Local/0] 21:43:13
                      Local via ge-0/0/1.3
10.101.4.0/24      *[Direct/0] 21:43:11
                    > via ge-0/0/1.4
10.101.4.254/32    *[Local/0] 21:43:13
                      Local via ge-0/0/1.4
192.168.1.0/24     *[Direct/0] 21:43:11
                    > via ge-0/0/0.0
192.168.1.200/32   *[Local/0] 21:43:13
                      Local via ge-0/0/0.0
224.0.0.5/32       *[OSPF/10] 21:43:22, metric 1
                      MultiRecv
 
[edit]
root@srx-core#

It appears there has been no change in either the routing table used in the rib group or the table to which it was applied.

[edit]
root@srx-core# delete routing-options interface-routes
 
[edit]
root@srx-core# set routing-options rib-groups export-test export-rib inet.0
 
[edit]
root@srx-core# set routing-instances test1 routing-options interface-routes rib-group inet export-test
 
[edit]
root@srx-core# commit
[edit routing-instances test1 routing-options interface-routes]
  'rib-group'
    export-test: primary rib for instance test1 was not found in ribgroup configuration.
error: configuration check-out failed

Well that was a waste of time.

Export-rib rule #1 : They don’t work
Export-rib rule #2 : The Junos Enterprise Routing book doesn’t even mention the existence of export-rib groups
Export-rib rule #3 : Searching Google for export-rib examples is futile

Let’s move on to something at least productive.