Identifying Nodes in a Chassis Cluster
To determine if the SRX Series device is configured in a cluster, use the following methods. We recommend using the primary-only IP address from the management station to perform the operations suggested.
Identifying the Chassis Cluster Primary and Secondary Nodes
- Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
- Using the get-chassis-inventory RPC Tag
- Using SNMP
Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
Use the <get-chassis-cluster-status> remote procedure call (RPC) to determine if the chassis is configured in a cluster.
RPC for Chassis Inventory
RPC :<rpc> <get-chassis-cluster-status> </get-chassis-cluster-status> </rpc> Response: See Managing SRX Series Chassis Clusters Using RPCs.
Using the get-chassis-inventory RPC Tag
Use the get-chassis-inventory remote procedure call (RPC) to get the inventory of the chassis for both the primary and secondary nodes. This identifies two nodes as part of a multi-routing-engine-item. See Managing SRX Series Chassis Clusters Using RPCs for sample output of the RPC. The following output shows only the relevant tags.
Sample Chassis Inventory Tags
RPC:<rpc><get-chassis-inventory/></rpc> RELEVANT RESPONSE TAGS: </multi-routing-engine-item> <multi-routing-engine-item> <re-name>node0</re-name> #Node 0 Items </multi-routing-engine-item> <multi-routing-engine-item> <re-name>node1></re-name> #Node 0 Items </multi-routing-engine-item> </multi-routing-engine-item>
Using SNMP
jnx-chassis-jnxRedundancyTable/jnxContentsTable – Use to show if two Routing Engines are in service.
jnxContentsChassisId – Use to show which Routing Engine belongs to which node.
We recommend that you use the primary-only IP address to do SNMP polling. After a switchover, the management system continues to use the primary-only IP address to manage the cluster. If a primary-only IP address is not used, only the primary node responds to the jnx-chassis MIB queries. The primary node includes components from the secondary node as well. The secondary node does not respond to the jnx-chassis MIB queries.
There are no MIBS to identify the primary and secondary nodes. The only method to identify the primary and secondary nodes using SNMP is to send queries to retrieve the jnx-chassis MIB objects on both IP addresses. Only the primary responds. If you use a primary-only IP address, the active primary responds. Another option is to SNMP MIB walk the jnxLedTable MIB. This only returns data for the primary node.
The following sample shows two Routing Engines and two nodes, node 0 and node 1, present on the device.
Sample SNMP Output
JUNIPER-MIB::jnxContentsDescr.9.1.0.0 = STRING: node0 Routing Engine 0 JUNIPER-MIB::jnxContentsDescr.9.3.0.0 = STRING: node1 Routing Engine 0 JUNIPER-MIB::jnxRedundancyDescr.9.1.0.0 = STRING: node0 Routing Engine 0 JUNIPER-MIB::jnxRedundancyDescr.9.3.0.0 = STRING: node1 Routing Engine 0 JUNIPER-MIB::jnxContentsChassisId.9.1.0.0 = INTEGER: node0(12) JUNIPER-MIB::jnxContentsChassisId.9.3.0.0 = INTEGER: node1(13)
The jnx-chassis MIB is not supported on SRX Series branch devices in cluster mode. It is supported on standalone SRX Series branch devices.
Determining the IP Address of Nodes
We recommend that the management systems have options to provide additional IP addresses to communicate with the device, such as the secondary IP address and the primary IP address. The following are additional options for gathering IP addresses used on the cluster.
Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
get-config– Use to show the node0 and node1 fxp0 interface and the reth interface configuration to identify the IP addresses used by the primary and secondary nodes.get-interface-information– Use to show the interfaces and basic details. Use theinterface-addresstag to identify the IP addresses for the fxp0 and reth interfaces. Using this remote procedure call (RPC), all interfaces are reported, including the addresses on the secondary node, except for the fxp0 interface on the secondary node. The following sample shows the fxp0 interface on the primary node:
<physical-interface> <name> fxp0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> fxp0.0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <filter-information> </filter-information> <address-family> <address-family-name> inet </address-family-name> <interface-address> <ifa-local junos:emit="emit"> 10.204.131.37/18 </ifa-local> </interface-address> </address-family> </logical-interface> </physical-interface> </interface-information>
Using SNMP MIBs
Use the ifTable MIB table to get the ifIndex MIB object of the fxp0 interface and the reth interface on the primary node. Use the ipAddrTable MIB table to determine the IP address of the interfaces. The following is a sample showing the fxp0 interface on the active primary node. Note that the ifTable MIB table reports all interfaces on the secondary node, except for the fxp0 interface on the secondary node.
Sample SNMP MIB Walk of the ifTable MIB Table
{primary:node0}
user@host> show snmp mib walk ifTable | grep fxp0
ifDescr.1 = fxp0
ifDescr.13 = fxp0.0
user@host> show snmp mib walk ipAddrTable | grep 13
ipAdEntAddr.10.204.131.37 = 10.204.131.37
ipAdEntIfIndex.10.204.131.37 = 13
ipAdEntNetMask.10.255.131.37 = 255.255.255.255For SNMP communication directly with the secondary node, the IP address of the secondary node should be predetermined and preconfigured on the management system. Querying the ifTable MIB table directly on the secondary node returns only the fxp0 interface and a few private interface details on the secondary node, and no other interfaces are reported. All other interfaces are reported by the primary node itself. Use the ifTable MIB table and the ipAddrTable MIB table as previously shown to directly query the secondary node to find the fxp0 interface details such as the ifAdminStatus and ifOperStatus MIB objects on the secondary node.