Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] How to verify the status of the NSRP 'Active-Active' cluster

0

0

Article ID: KB7840 KB Last Updated: 30 May 2019Version: 6.0
Summary:

This article provides information on how to verify the status of the NSRP Active-Active cluster.

Symptoms:

When a failover occurs, some packet drops are experienced, even though the cluster is configured as an active-active NSRP cluster.

Solution:

To check the status of an NSRP active-active cluster, issue the get nsrp command. A successful NSRP configuration will have the following output:

C2-09(M)-> get nsrp
nsrp version: 2.0

cluster info:
cluster id: 1, no name
local unit id: 3513520
active units discovered:
index: 0, unit id:   3513520, ctrl mac: 0010db359cba, data mac: 0010db359cbb
index: 1, unit id:   3515616, ctrl mac: 0010db35a4ea, data mac: 0010db35a4eb
total number of units: 2

VSD group info:
init hold time: 5
heartbeat lost threshold: 3
heartbeat interval: 1000(ms)
master always exist: disabled
group priority preempt holddown inelig   master       PB other members
    0        1 yes            1 no       myself  3515616
    1      100 no             2 no      3515616   myself
total number of vsd groups: 2
Total iteration=23469,time=540006250,max=55388,min=8950,average=23009

RTO mirror info:
--- more ---
run time object sync:   enabled
ping session sync: enabled
coldstart sync done
nsrp data packet forwarding is enabled

nsrp link info:
control   channel: ethernet7 (ifnum: 10)  mac: 0010db359cba state: up
data      channel: ethernet8 (ifnum: 11)  mac: 0010db359cbb state: up
ha secondary path link not available

NSRP encryption: disabled
NSRP authentication: disabled
device based nsrp monitoring threshold: 255, weighted sum: 0, not failed
device based nsrp monitor interface:
device based nsrp monitor zone:
device based nsrp track ip: (weight: 255, disabled)
number of gratuitous arps: 4 (default)
config sync: enabled

track ip: disabled

For more detailed vsd level information:
C2-09(M) -> get nsrp vsd-group
VSD group info:
init hold time: 5
heartbeat lost threshold: 3
heartbeat interval: 1000(ms)
master always exist: disabled
group priority preempt holddown inelig master PB other members
0 100 no 3 no myself 3515616
1 50 yes 30 no 3515616 myself
total number of vsd groups: 2
Total iteration=101865,time=152753708,max=11948,min=169,average=1499

vsd group id: 0, member count: 2, master: 3513520
member information:
---------------------------------------------------------------------
group unit_id state prio flag rto_peer hb miss holddown
---------------------------------------------------------------------
0 3513520 master 50 2 0 0 0 30
0 3515616 primary backup 100 0 0 0 0 3
vsd group id: 1, member count: 2, master: 3513520
member information:
---------------------------------------------------------------------
group unit_id state prio flag rto_peer hb miss holddown
---------------------------------------------------------------------
1 3515616 master 100 0 0 0 0 3
1 3513520 primary backup 50 2 0 0 0 30

Notice that two active units were discovered and each of them is referenced with a unit ID. There are two VSD Groups for this particular NSRP Cluster. For VSD group 0, the output states the master as myself and for VSD group 1, the master is unit id 3515616 . Also, on this unit, VSD 0 is configured with priority 1 and VSD 1 is configured for priority 100. This means that VSD 0 is the preferred VSD for this device.

So, you need to first confirm if all the units are correctly discovered or not. If not, then you need to verify the NSRP configuration, along with HA link status and connectivity. For more information, refer to KB11292 - How to configure NSRP options: secondary path, hb-interval, auth password, encrypt password, master-always-exist, link-up-on-backup.

Also under NSRP link info, you should see an active control and data channel. If you do not have an active data channel, either the link on that interface is bad or the two interfaces for HA zone were not configured. To correctly select the interfaces for HA connectivity, refer to KB11296 - Assigning ports or interfaces for the HA link (NSRP).

For more information on how the control and data channels are decided, refer to KB11468 - Which HA interfaces will become the control and data channel for NSRP?

If the HA link between the two devices goes through a switch, you need to ensure that HA probing is enabled:

set nsrp ha-link probe

Any of the above reasons may be the cause for the split-brain scenario. For more information about split-brain and HA probing, refer to KB11450 - [NSRP] What is NSRP split brain? Why are both of my firewalls in the Master state?

When troubleshooting packet drops during failover, verify the NSRP RTO Synchronization settings to confirm that the cluster devices remain in proper sync.

The get nsrp counter rto command will display the counters for all of the rto messages:

C2-09(M)-> get nsrp counter rto 
RTO message counters:
msg name send rcv drop 
----------------------------------------------------------------
SESS_CR 43 28 0
SESS_CL 26 25 0
SESS_CH 0 9 0
CMD 64 52 4
SYS_CFG 0 0 0
FILE 26 0 0
CMD_WEB 0 0 0
SAVE 0 0 0
SPI 24 0 0
ARP 349 1 0
HEALTH 6 10 0
EMW 0 0 0
2SYNC 0 0 0
DL_CFG 0 0 0
L2TP_NA 0 0 0
L2TP_TD 0 0 0
L2TP_CC 0 0 0
L2TP_CD 0 0 0
PKI_SYN 0 0 0
VPN_SEQ 0 0 0
DNS 0 0 0
--more—-

To obtain detailed information about the NSRP heartbeat and state changes for each VSD group, use the get nsrp counter protocol command:

C2-09(M)-> get nsrp counter protocol 
Nsrp arp counts: 4, interval: 1
Nsrp VSD group counts:
group st_chg to ms pb bk inop ineli init dup_ms dup_pb hb_tx hb_rx
---------------------------------------------------------------------------
0 8 3 3 0 2 0 0 0 0 14403 14121
1 6 2 2 2 0 0 0 0 0 2504 2478

RTO mirror group has not been defined

Session sync times=0, completed=0
 

The get nsrp counter packet-fwd command can be used to check the usage of the data link, when troubleshooting dropped packets in an active/active cluster with data forwarding:

C2-09(M)-> get nsrp counter packet-fwd 
packet forward send count: 409814
packet forward received count: 0
packet forward dropped count: 1
Modification History:
2019-05-30: Minor, non-technical update.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search