Juniper Networks Virtual Chassis HA features – GRES, NSR and NSB

Juniper Virtual Chassis is a network virtualization technology which supports up to 10 switches within one stack. All switches are managed via single, virtual management interface (vme) and console. There are several benefits using VC in the network, one of the most important is a fact, that between devices participating in VC there is no Spanning Tree. Devices communicate each other using Juniper’s proprietary protocol called VCCP (Virtual Chassis Control Protocol), which is based on IS-IS routing protocol. HERE you can read more about VC components.

To create Juniper VC we have to connect devices using Virtual Chassis Ports (VCP), which are enabled by default in the factory configuration. In the factory configuration there are no high availability features enabled across VC. That means backup routing engine (RE) detecs failure of primary RE after 5 minutes! This time could be shorten up to 2 seconds by enabling Graceful Routing Engine Switchover. This feature also has impact on local switching within VC during RE switchover. Without GRES new master RE restarts all PFEs across every switch participating in VC. GRES enables chassid (daemon responsible for detecting hardware components) and ksyncd on backup routing engine, which synchronizes its state with master RE getting information about all hardware components present in VC.


gres Fig 1. GRES source Juniper.net

You can simply turn on and verify GRES using the following commands


lab@exA-2# set chassis redundancy graceful-switchover


lab@exA-2# commit

Please note, that these command must be executed on backup RE


lab@exA-2> show system switchover


Graceful switchover: On

Configuration database: Ready

Kernel database: Ready

Peer state: Steady State


Another features, which should be enabled in VC are Nonstop Routing (NSR) and Nonstop Bridging (NSB). Both of them require GRES. NSR enables rpd (routing protocol daemon which is responsible for routing in JunOS) on backup RE. Such process on backup RE synchronizes its state with rpd on master RE. After RE failover all routing information is preserved on backup RE (including link state databases, routing tables, forwarding table, neighbours adjacencies). NSR works for such protocols like RIP, OSPF, BGP, ISIS, RSVP, LDP,  PIM, IGMP, BFD.

nsrFig 2. NSR source Juniper.net

Follow these commands to enable and verify NSR


lab@exA-2#set system commit synchronize


lab@exA-2# set routing-options nonstop-routing

lab@exA-2# run show task replication

       Stateful Replication: Enabled

       RE mode: Master

   Protocol               Synchronization Status

   OSPF                   Complete



NSB is very simiar to NSR, but works for Layer 2 protocols such xSTP, LLDP, LLDP-MED, LACP. On backup RE starts l2cpd, which controls layer 2 protocols in JunOS.

nsbFig 3. NSB source Juniper.net

Configuration of NSB is as simple as GRES or NSR, but there is no CLI command, which shows NSB state.



lab@exA-2#set system commit synchronize


lab@exA-2# set protocols layer2-control nonstop-bridging


You can also watch the video, which shows how to enable and verify GRES and NSR on Juniper EX4200.

labFig 4. Lab structure



Internetworking: Networks & Security – what is this all about?

Hello, world. Working in IT requires You to assimilate a lot of knowledge every day. It is troublesome to remember all of it so my brother Paul and I decided to create this site as an aid for this. You can expect entries about network and security technologies caveats as well as vendor specific information like Juniper, Cisco, F5, Riverbed etc. Also I’m also Linux enthusiast and a gamer so You probably hear a word or two about those. Most recently I was playing with Riverbed load balancers so You could expect an entry about what ADC-as-a-service is and how to deploy it. Cheers!