Support Support Downloads Knowledge Base Juniper Support Portal 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

What happens when secondary path is enabled on a Juniper NetScreen, ISG or SSG firewall?



Article ID: KB9473 KB Last Updated: 28 Jul 2013Version: 4.0
When secondary-path is enabled, NSRP floods the network segment with a 'vendor' broadcast.

Below is an example of a NetScreen Redundancy Protocol Version 2 (NSRP) configuration:

ns500(M)-> get nsrp
nsrp version: 2.0

cluster info:
cluster id: 7, no name
local unit id: 9876543
active units discovered:
index: 0, unit id:   9876543, total number of units: 1

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     none
total number of vsd groups: 1
Total iteration=1887,time=29626327,max=30646,min=2359,average=15700

RTO mirror info:
run time object sync:   disabled
ping session sync: enabled
nsrp data packet forwarding is enabled

When the primary NSRP links fail (possibly the dedicated HA interfaces), the following message is inserted into the debugs:

## 16:18:04 : no ha control channel, forcely use secondary path to send vsd hb
## 16:18:04 : send vsd hb,gid=0,src=9876543,state=master,prio=100,fail=0,flag=0,rtopeer=0
00476.0: 7(o):0010db862307->0110dbf0f0f0/8133

At this point, the secondary path sends a heartbeat over the local segment (sample below).  Note the destination MAC address. It is "01:10:db:f0:f0:f0". This isn't a MAC used by any of the firewall products.

No.     Time        Source                Destination           Protocol Info
     14 13.000056   Netscree_86:23:07     01:10:db:f0:f0:f0     0x8133   Ethernet II

Frame 14 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: 00:10:db:86:23:07, Dst: 01:10:db:f0:f0:f0
    Destination: 01:10:db:f0:f0:f0 (01:10:db:f0:f0:f0)
    Source: 00:10:db:86:23:07 (Netscree_86:23:07)
    Type: Unknown (0x8133)
Data (56 bytes)

0000  00 02 07 81 00 24 07 00 00 00 00 00 00 00 00 00   .....$..........
0010  00 86 23 00 17 00 00 00 00 18 64 00 00 00 00 00   ..#.......d.....
0020  00 02 64 00 00 96 B4 3F 00 00 00 00 00 09 d0 80   ..d...#.........
0030  00 00 02 4a 00 00 00 00                           ...J....

To understand what this destination MAC is, why it is used, and the implication of its use on NSRP cluster ID selection, the NSRP configuration needs to be analyzed in more detail.  One way is to review the hex data of the frame captured with a packet analyer tool (see above).  The cluster ID used in this example is 7. The cluster member is 9876543; in hex, this is 96 B4 3F.

The 07 changes to an 02 for cluster id 2, and 03 for cluster id 3, etc.

Looking at the destination address for the secondary path heartbeat again: 01:10:db:f0:f0:f0  This address will broadcast to all firewall Virtual Security Interface (VSI) MAC addresses in the network segment.

Therefore secondary-path cannot be used with VSD-less clusters, or if VSD 0 is removed.

When a switching device receives this 'vendor' broadcast, it floods the frame to all the NetScreen, ISG or SSG devices that it knows about.

All VSI addresses use the range: 0110dbfXfXfX. The 'f' will tell the switch to broadcast this MAC to all interfaces that match this bit. The 'X' on a netscreen is a unique number for that interface.

For example, on an NS-5400 cluster 1, one of the interfaces has this address: 0010.dbff.4070. The switch receives a frame destined to 0110dbf0f0f0. It matches the destination address in the switch table (which is recording source MAC and interface number).

On another NS-5400 cluster (cluster 2), one of the interfaces has this address: 0010.dbff.2030. The switch also matches this address and will send the frame to both cluster 1 and cluster 2.

For more information on how the Virtual MAC address is calculated in a NSRP cluster, refer to the following two KB articles:

The solution to a secondary-path flood on a switched LAN segment is to use different cluster IDs, and / or adding encryption passwords.

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