Monitoring Nodes in a Chassis Cluster
To monitor the cluster, you need to discover the redundancy groups. When you initialize a device in chassis cluster mode, the system creates a redundancy group referred to in this topic as redundancy group 0. Redundancy group 0 manages the primacy and failover between the Routing Engines on each node of the cluster. As is the case for all redundancy groups, redundancy group 0 can be primary on only one node at a time. The node on which redundancy group 0 is primary determines which Routing Engine is active in the cluster. A node is considered the primary node of the cluster if its Routing Engine is the active one. You can configure one or more redundancy groups numbered 1 through 128, referred to in this section as redundancy group x. The maximum number of redundancy groups is equal to the number of redundant Ethernet interfaces +1 that you configure. Each redundancy group x acts as an independent unit of failover and is primary on only one node at a time. There are no MIBS available to retrieve this information.
Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
Use the get-configuration remote
procedure call (RPC) to get the redundancy configuration and the redundancy
groups present on the device. This provides the redundancy groups
configured.
XML RPC for Configuration Retrieval
<rpc> <get-configuration inherit="inherit" database="committed"> <configuration> <chassis> <cluster> </cluster> </chassis> </configuration> </get-configuration> </rpc>
Response:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm" junos:commit-seconds="1277806450" junos:commit-localtime="2010-06-29 03:14:10 PDT" junos:commit-user="regress"> <chassis> <cluster> <reth-count>10</reth-count> <control-ports> <fpc>4</fpc> <port>0</port> </control-ports> <control-ports> <fpc>10</fpc> <port>0</port> </control-ports> <redundancy-group> <name>0</name> <node> <name>0</name> <priority>254</priority> </node> <node> <name>1</name> <priority>1</priority> </node> </redundancy-group> <redundancy-group> <name>1</name> <node> <name>0</name> <priority>100</priority> </node> <node> <name>1</name> <priority>1</priority> </node> </redundancy-group> </cluster> </chassis> </configuration> </rpc-reply> ]]>]]>
Chassis Cluster Redundant Ethernet Interfaces
A redundant Ethernet interface is a pseudointerface that includes at minimum one physical interface from each node of the cluster. A redundant Ethernet interface is referred to as a reth in configuration commands. The following sample output shows two redundancy groups present and configured.
Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
Use the
get-chassis-cluster-interfacesremote procedure call (RPC) to obtain the reth interface details. The following sample output shows four reth interfaces configured:XML RPC for Chassis Cluster Interfaces
user@host>
show chassis cluster interfaces |display xml<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4R5/junos"> <chassis-cluster-interface-statistics> <control-interface-status>Up</control-interface-status> <control-link-interfaces> <control-information> <control-link-interface-index>0</control-link-interface-index> <control-link-interface-name>em0</control-link-interface-name> <control-link-interface-status>Up</control-link-interface-status> </control-information> <control-information> <control-link-interface-index>1</control-link-interface-index> <control-link-interface-name>em1</control-link-interface-name> <control-link-interface-status>Down</control-link-interface-status> </control-information> </control-link-interfaces> <dataplane-interface-status>Up</dataplane-interface-status> <dataplane-interfaces> <fabric-information> <fabric-interface-index>0</fabric-interface-index> <fabric-child-interface-name>ge-6/0/15</fabric-child-interface-name> <fabric-child-interface-status>Up</fabric-child-interface-status> <fabric-interface-index>0</fabric-interface-index> </fabric-information> <fabric-information> <fabric-interface-index>1</fabric-interface-index> <fabric-child-interface-name>ge-19/0/15</fabric-child-interface-name> <fabric-child-interface-status>Up</fabric-child-interface-status> <fabric-interface-index>1</fabric-interface-index> </fabric-information> </dataplane-interfaces> <reth> <reth-name>reth0</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth1</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth2</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth3</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth4</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth5</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth6</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth7</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth8</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth9</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth10</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth11</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth12</reth-name> <reth-status>Down</reth-status> <redundancy-group-id-for-reth>Not configured</redundancy-group-id-for-reth> <reth-name>reth13</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth14</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth15</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> <reth-name>reth16</reth-name> <reth-status>Up</reth-status> <redundancy-group-id-for-reth>1</redundancy-group-id-for-reth> </reth> <interface-monitoring> </interface-monitoring> </chassis-cluster-interface-statistics> <cli> <banner>{secondary:node0}</banner> </cli> </rpc-reply> user@host>show chassis cluster interfacesControl link status: Up Control interfaces: Index Interface Status 0 em0 Up 1 em1 Down Fabric link status: Up Fabric interfaces: Name Child-interface Status fab0 ge-6/0/15 Up fab0 fab1 ge-19/0/15 Up fab1 Redundant-ethernet Information: Name Status Redundancy-group reth0 Down 1 reth1 Down Not configured reth2 Down 1 reth3 Down Not configured reth4 Down 1 reth5 Down 1 reth6 Down 1 reth7 Down 1 reth8 Down 1 reth9 Down 1 reth10 Up 1 reth11 Down 1 reth12 Down Not configured reth13 Up 1 reth14 Up 1 reth15 Up 1 reth16 Up 1 {secondary:node0}Use the
get-interface-informationremote procedure call (RPC) to show reth interface details and to identify the reth interfaces on the device. This RPC also shows which Gigabit Ethernet or Fast Ethernet interfaces belong to which reth interface as shown in the following sample output:XML RPC for Interface Information
<rpc> <get-interface-information> <terse/> <interface-name>reth0</interface-name> </get-interface-information> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <interface-information xmlns="http://xml.juniper.net/junos/10.4I0/junos-interface" junos:style="terse"> <physical-interface> <name> reth0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> reth0.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"> 192.168.29.2/24 </ifa-local> </interface-address> </address-family> <address-family> <address-family-name> multiservice </address-family-name> </address-family> </logical-interface> </physical-interface> </interface-information> Now, the interface that belongs to this. Extracting only the relevant information <rpc> <get-interface-information> <terse/> </get-interface-information> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <interface-information xmlns="http://xml.juniper.net/junos/10.4I0/junos-interface" junos:style="terse"> <physical-interface> <name> ge-5/1/1 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <logical-interface> <name> ge-5/1/1.0 </name> <admin-status> up </admin-status> <oper-status> up </oper-status> <filter-information> </filter-information> <address-family> <address-family-name> aenet </address-family-name> <ae-bundle-name> reth0.0 </ae-bundle-name> </address-family> </logical-interface> </physical-interface> </interface-information>
In the sample output, the
ae-bundle-nametag identifies the reth interface it belongs to.
Using SNMP
The ifTable MIB table reports all the reth interfaces.
Use the ifStackStatus MIB table to map the reth interface to the underlying interfaces on the primary and secondary nodes. The reth interface is the high layer, and the individual interfaces from both nodes show up as lower layer indexes.
Sample SNMP Data for the Reth Interface Details
In the following sample, ge-5/1/1 and ge-11/1/1 belong to reth0:
{primary:node0} user@host>show interfaces terse | grep reth0ge-5/1/1.0 up up aenet --> reth0.0 ge-11/1/1.0 up up aenet --> reth0.0 reth0 up up reth0.0 up up inet 192.168.29.2/24Find the index of all interfaces from the ifTable. The following information shows indexes of interfaces required in this example:
{primary:node0} user@host>show snmp mib walk ifDescr | grep reth0ifDescr.503 = reth0.0 ifDescr.528 = reth0Now, search for the index for reth0 in the ifStackStatus table. In the following sample output, reth0 index 503 is the higher layer index, and index 522 and 552 are the lower layer indexes. Index 522 and 552 represent interfaces ge-5/1/1.0 and ge-11/1/1.0, respectively.
{primary:node0} user@host>show snmp mib walk ifStackStatus | grep 503ifStackStatus.0.503 = 1 ifStackStatus.503.522 = 1 ifStackStatus.503.552 = 1 {primary:node0} user@host>show snmp mib walk ifDescr | grep 522ifDescr.522 = ge-5/1/1.0 {primary:node0} user@host>show snmp mib walk ifDescr | grep 552ifDescr.552 = ge-11/1/1.0
Using the Control Plane
The control plane software, which operates in active/backup mode, is an integral part of Junos OS that is active on the primary node of a cluster. It achieves redundancy by communicating state, configuration, and other information to the inactive Routing Engine on the secondary node. If the primary Routing Engine fails, the secondary one is ready to assume control. The following methods can be used to discover control port information.
Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
Use the get-configuration remote
procedure call (RPC) to get the control port configuration as shown
in the following sample output.
XML RPC for Redundant Group Configuration
<rpc> <get-configuration inherit="inherit" database="committed"> <configuration> <chassis> <cluster> </cluster> </chassis> </configuration> </get-configuration> </rpc>
Using the Data Plane
The data plane software, which operates in active/active mode, manages flow processing and session state redundancy and processes transit traffic. All packets belonging to a particular session are processed on the same node to ensure that the same security treatment is applied to them. The system identifies the node on which a session is active and forwards its packets to that node for processing. The data link is referred to as the fabric interface. It is used by the cluster's Packet Forwarding Engines to transmit transit traffic and to synchronize the data plane software’s dynamic runtime state. When the system creates the fabric interface, the software assigns it an internally derived IP address to be used for packet transmission. The fabric is a physical connection between two nodes of a cluster and is formed by connecting a pair of Ethernet interfaces back-to-back (one from each node). The following methods can be used to determine the data plane interfaces.
Using the Junos OS XML Management Protocol or NETCONF XML Management Protocol
Use the get-chassis-cluster-data-plane-interfaces remote procedure call (RPC) to get the data plane interfaces as
shown in the following sample output.
XML RPC for Cluster Dataplane Interface Details
<rpc> <get-chassis-cluster-data-plane-interfaces> </get-chassis-cluster-data-plane-interfaces> </rpc><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4I0/junos"> <chassis-cluster-dataplane-interfaces> <fabric-interface-index>0</fabric-interface-index> <fabric-information> <child-interface-name>xe-5/0/0</child-interface-name> <child-interface-status>up</child-interface-status> </fabric-information> <fabric-interface-index>1</fabric-interface-index> <fabric-information> <child-interface-name>xe-11/0/0</child-interface-name> <child-interface-status>up</child-interface-status> </fabric-information> </chassis-cluster-dataplane-interfaces>
Using SNMP
The ifTable MIB table reports fabric (fab) interfaces and the link interfaces. However, the relationship between the underlying interfaces and fabric interfaces cannot be determined using SNMP.
Provisioning Chassis Cluster Nodes
Use the NETCONF XML management protocol for configuration and provisioning of SRX Series devices and Junos OS devices in general. We recommend using groups to configure SRX Series chassis clusters. Use global groups for all configurations that are common between the nodes.
Junos OS commit scripts can be used to customize the configuration as desired.
Junos OS commit scripts are:
Run at commit time
Inspect the incoming configuration
Perform actions including:
Failing the commit (self-defense)
Modifying the configuration (self-correcting)
Commit scripts can:
Generate custom error/warning/syslog messages
Make changes or corrections to the configuration
Commit scripts give you better control over how your devices are configured to enforce:
Your design rules
Your implementation details
100 percent of your design standards