Jul.11

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

{master:0}[edit]

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

{master:0}[edit]

lab@exA-2# commit

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

{backup:1}

lab@exA-2> show system switchover

fpc1:————————————————

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

{master:0}[edit]

lab@exA-2#set system commit synchronize

{master:0}[edit]

lab@exA-2# set routing-options nonstop-routing
{master:0}[edit]

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.

 

{master:0}[edit]

lab@exA-2#set system commit synchronize

{master:0}[edit]

lab@exA-2# set protocols layer2-control nonstop-bridging
{master:0}[edit]

 

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

labFig 4. Lab structure

Networks
Share this Story:
  • facebook
  • twitter
  • gplus

About Paul Jakacki

Leave a comment

Comment