Knowledge Search


×
 

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

  [KB7840] Show Article Properties


Summary:

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

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

Solution:

To check the status of an NSRP active-active cluster, you can 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:

JNASC-NSRP:mulholland(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 13164928 myself
1 50 yes 30 no myself 13164928
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: 13164928
member information:
---------------------------------------------------------------------
group unit_id state prio flag rto_peer hb miss holddown
---------------------------------------------------------------------
0 13164928 master 50 2 0 0 0 30
0 13100416 primary backup 100 0 0 0 0 3

vsd group id: 1, member count: 2, master: 13100416
member information:
---------------------------------------------------------------------
group unit_id state prio flag rto_peer hb miss holddown
---------------------------------------------------------------------
1 13164928 primary backup 100 0 0 0 0 3
1 13100416 master 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:
JNASC-NSRP:martinez(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:
JNASC-NSRP:martinez(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:
JNASC-NSRP:martinez(M)-> get nsrp counter packet-fwd 
packet forward send count: 409814
packet forward received count: 0
packet forward dropped count: 1
Related Links: