Graceful Restart & Nonstop Routing

With this post we will have a closer look at the topic „Graceful Restart“ and “Nonstop Routing” as part of „Device Infrastructure“.

JunOS supports different kinds of high availability concepts. The following table shows you a summary:

Concept Fashion
Dual Routing-Engine / Switching Control Board Hard switching  between redundant modules,daemons and protocols have to restart.
Graceful Routing Engine Switchover (GRES) Preserve interface and kernel states during an routing-engine failure,Routing protocols have to restart.
Nonstop Bridging (NSB) Layer 2 control protocol states replicated to backup routing-engine, protocols are STP, RSTP and MSTP.
Nonstop Routing (NSR) Routing protocol states replicated to backup routing-engineRouting protocols up during failure.
Graceful Restart (GR) Signaling protocol neighbors the outages of the routing protocol adjacencies. Other routers hold routing informations and adjacency state for a specified time frame. This capability is used by protocols like BGP, ISIS, OSPF, RIP, LDP and RSVP.

These concept could be used in several combinations:

  • GRES + NSR
  • GRES + NSB
  • GRES + GR

It is not possible in JunOS to activate NSR and GR together.

Graceful Restart

Graceful restart is a protocol capability, which is signaled in many protocol to neighbors. The following image show you the general procedure of a graceful restart:

Picture about Graceful Restart Operation
Graceful Restart Procedure

The following protocols support graceful restart in JunOS 10.4:

  • BGP
  • ISIS/ESIS
  • OSPF/OSPFv3
  • PIM Sparse Mode
  • RIP/RIPng
  • LDP
  • RSVP

In order to activate graceful restart feature generally, you have to configure the following option:

routing-options {
    graceful-restart;
}

To activate graceful restart for a protocol, you also have to configure it in the right instance:

For e.g. in BGP:

protocols {
    bgp {
        graceful-restart;
    }
}

Especially in BGP you can choose to enable graceful restart on a per neighbor, per group or complete bgp level.

In every protocols stanza you have the option to specify the duration of a graceful restart. This could be done in the following way:

protocols {
    bgp {
        graceful-restart {
            restart-time <seconds>;
        }
    }
}

The default values are:

  • BGP – 60 seconds
  • ISIS/ESIS – 90 seconds
  • OSPFv2/OSPFv3 – 180 seconds
  • PIM Sparse Mode – 60 seconds
  • RIP/RIPng – 30 seconds
  • LDP – 120 seconds
  • RSVP – 60 seconds

Nonstop Routing

Otherwise than graceful restart, nonstop routing doesn’t need to be signaled by every protocol, it is a feature of JunOS. The following protocols and features are supported for nonstop routing in JunOS 10.4:

  • LACP
  • BFD
  • BGP (not for all protocol families)
  • ISIS
  • OSPF/OSPFv3
  • PIM
  • RIP/RIPng
  • LDP
  • RSVP
  • VPLS

To configure nonstop routing you always have to activate GRES and “commit synchronize” to get both routing-engines synchronized. Otherwise you get a commit error like this:

admin@R4# set routing-options nonstop-routing

{master}[edit]
admin@R4# commit
re1:
[edit routing-options]
  'nonstop-routing'
    Synchronized commits must be configured with nonstop routing
[edit routing-options]
  'nonstop-routing'
    Graceful switchover needs to be configured
error: commit failed: (statements constraint check failed)

{master}[edit]
admin@R4#

The minimum configuration looks like this:

system {
    commit synchronize;
}
chassis {
    redundancy {
        graceful-switchover;
    }
}
routing-options {
    nonstop-routing;
}

Configuring archival

At this time we will take a short look at the topic „Archival“ as part of „Device Infrastructure“.

JunOS can automatically copy the current configuration to a storage location. This could be triggered by a time interval or commit change.

In JunOS 10.4 are only FTP and SCP protocols are available. Starting with JunOS 12.4 there a more options available like local copy, HTTP and passive FTP. Beside IPv4 you could also use IPv6 host addresses as destinations.

You start configuring archival under system hierarchy. You must specify the protocol, username, directory and password which should be used.

Syntax looks like this:

systems {
    archival {
        configuration {
            archive-sites {
                "ftp://<username>:<password>@<host>:<port>/<url-path>";
                "scp://<username>:<password>@<host>:<port>/<url-path>";
            }
            transfer-interval <interval>;
            transfer-on-commit;
        }
    }
}

The notation is <Protocol>://<Username>[:Password]@<Host IPv4/IPv6>:<TCP Port>/URL-Path” for example “scp://backup@10.0.0.1:22/home/router-configs/”.

You can specify a time interval in minutes with the option “transfer-interval” in which the configuration gets automatically copied. The range could be 15 till 2880 minutes.

Also you could add the option “transfer-on-commit” to get copy after every commit change.

If the transfer fails, you will see the message “Apr  17 12:41:42  router logger: transfer-file failed to transfer /var/transfer/config/router_juniper.conf.gz_20130417_124059” in your messages.

If this happen, check the connectivity to your scp/ftp server in inet.0 and also username and password settings. You can manually verify the operation also from shell, for e.g. scp :

admin@router> start shell
% scp /config/juniper.conf.gz admin@10.1.1.1:/home/backup/
ssh: connect to host 10.1.1.1 port 22: Connection refused
lost connection
%

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close