Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Example: Configuring an Active/Passive Chassis Cluster on SRX5800 Devices

    This example shows how to set up basic active/passive chassis clustering on an SRX5800 devices. In this example, you also enable secure login and to prevent attackers from gaining privileged access through this control port by configuring the internal IP security (IPsec) security association (SA).

    Requirements

    Before you begin:

    • You need two SRX5800 Services Gateways with identical hardware configurations, one MX240 edge router, and one EX8208 Ethernet Switch.

    • Physically connect the two devices (back-to-back for the fabric and control ports) and ensure that they are the same models.

    • Before the cluster is formed, you must configure control ports for each device, as well as assign a cluster ID and node ID to each device, and then reboot. When the system boots, both the nodes come up as a cluster.

      Note: Control port configuration is required for SRX5400, SRX5600, and SRX5800 devices.

    Now the devices are a pair. From this point forward, configuration of the cluster is synchronized between the node members, and the two separate devices function as one device.

    Overview

    This example shows how to set up basic active/passive chassis clustering on an SRX Series device. The basic active/passive example is the most common type of chassis cluster.

    The basic active/passive chassis cluster consists of two devices:

    • One device actively provides routing, firewall, NAT, VPN, and security services, along with maintaining control of the chassis cluster.

    • The other device passively maintains its state for cluster failover capabilities in case the active device becomes inactive.

    Note: This active/passive mode example for the SRX5800 Services Gateway does not describe in detail miscellaneous configurations such as how to configure NAT, security policies, or VPNs. They are essentially the same as they would be for standalone configurations. See Introduction to NAT, Security Policies Overview, and IPsec VPN Overview. However, if you are performing proxy ARP in chassis cluster configurations, you must apply the proxy ARP configurations to the reth interfaces rather than the member interfaces because the RETH interfaces hold the logical configurations. See Configuring Proxy ARP for NAT (CLI Procedure). You can also configure separate logical interface configurations using VLANs and trunked interfaces in the SRX5800 Services Gateway. These configurations are similar to the standalone implementations using VLANs and trunked interfaces.

    Figure 1 shows the topology used in this example.

    Figure 1: Basic Active/Passive Chassis Clustering on an SRX Series Device Topology Example

    Basic Active/Passive Chassis
Clustering on an SRX Series Device Topology Example

    Configuration

    Configuring Internal IPsec Security Association (SA)

    Step-by-Step Procedure

    On SRX5400, SRX5600, and SRX5800 devices have a chassis cluster control port that is used to connect two SRX Series devices to form a chassis cluster. To ensure secure login and to prevent attackers from gaining privileged access through this control port, an internal IPsec SA is installed. Besides using internal IPsec to secure RSH and RCP between the primary and backup Routing Engines, the internal IPsec SA is installed on all the Services Processing Units (SPUs). An attacker cannot access any of the RSH services without knowing the internal IPsec key.

    The internal IPsec SA requires authorization for RSH on SPU and the Routing Engine. For telnet, authorization is only required for SPU since telnet for Routing Engine requires a password.

    You set up the IPsec internal SA using the security internal-security-association CLI command. You can configure the security internal-security-association on a node and then enable it to activate secure login. The security internal-security-association CLI command does not need to be set up on each node. When you commit the configuration, both nodes are synchronized.

    Note: The SA in this scenario is not the point-to-point security association, because it is used to communicate with any Routing Engine or SPU on the internal network. Only 3des-cbc encryption algorithm is supported.

    When secure login is configured, the IPsec-based rlogin (for starting a terminal session on a remote host) and rcmd (remote command) commands are enforced so an attacker cannot gain privileged access or observe traffic that contains administrator commands and outputs.

    To ensure secure login, configure the internal IPsec SA. When the internal IPsec is configured, IPsec-based rlogin and remote command (rcmd) are enforced, so an attacker cannot gain privileged access or observe traffic containing administrator commands and outputs. You do not need to configure the internal IPsec on both the nodes. When you commit the configuration, both nodes are synchronized. Only 3des-cbc encryption algorithm is supported. You must ensure that the manual encryption key is ascii text and 24 characters long; otherwise, the configuration will result in a commit failure.

    You have the option to enable the iked-encryption. The device must be rebooted after this option is configured.

    1. Enable the iked-encryption:
      user@host# set security ipsec internal security-association manual encryption ike-ha-link-encryption enable
    2. Enable the 3des-cbc encryption algorithm:
      user@host# set security ipsec internal security-association manual encryption algorithm 3des-cbc
    3. Configure the encryption key:
      user@host# prompt security ipsec internal security-association manual encryption key ascii-text

      Note: The password must be of 24 characters long.

    4. Activate internal IPsec:
      user@host> request security internal-security-association refresh
    5. Use the show chassis cluster interfaces CLI command to verify that internal SA is enabled:
      user@host> show chassis cluster interfaces
        Control link status: Up
      
        Control interfaces:
            Index   Interface        Status        Internal SA <- new column
            0       em0              Up              enabled 
            1       em1              Down            enabled
      
    6. Configure the control port for each device, and commit the configuration.

      Select FPC 1/13, because the central point is always on the lowest SPC/SPU in the cluster (for this example, it is slot 0). For maximum reliability, place the control ports on a separate SPC from the central point (for this example, use the SPC in slot 1). You must enter the operational mode commands on both devices. For example:

      • On node 0:

        user@host# set chassis cluster control-ports fpc 1 port 0
        user@host# set chassis cluster control-ports fpc 13 port 0
        user@host# commit
      • On node 1:

        user@host# set chassis cluster control-ports fpc 1 port 0
        user@host# set chassis cluster control-ports fpc 13 port 0
        user@host# commit
    7. Set the two devices to cluster mode. A reboot is required to enter into cluster mode after the cluster ID and node ID are set. You can cause the system to boot automatically by including the reboot parameter in the CLI command line. You must enter the operational mode commands on both devices. For example:
      • On node 0:

        user@host> set chassis cluster cluster-id 1 node 0 reboot
      • On node 1:

        user@host> set chassis cluster cluster-id 1 node 1 reboot

      The cluster ID is the same on both devices, but the node ID must be different because one device is node 0 and the other device is node 1. The range for the cluster ID is 1 through 255. Setting a cluster ID to 0 is equivalent to disabling a cluster. Cluster ID greater than 15 can only be set when the fabric and control link interfaces are connected back-to-back.

    Configuring a Chassis Cluster in Active/Passive Mode

    CLI Quick Configuration

    To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    On {primary:node0}

    [edit]
    set interfaces fab0 fabric-options member-interfaces ge-11/3/0
    set interfaces fab1 fabric-options member-interfaces ge-23/3/0
    set groups node0 system host-name SRX5800-1
    set groups node0 interfaces fxp0 unit 0 family inet address 10.3.5.1/24
    set groups node0 system backup-router 10.3.5.254 destination 10.0.0.0/16
    set groups node1 system host-name SRX5800-2
    set groups node1 interfaces fxp0 unit 0 family inet address 10.3.5.2/24
    set groups node1 system backup-router 10.3.5.254 destination 10.0.0.0/16
    set apply-groups “${node}”
    set chassis cluster reth-count 2
    set chassis cluster redundancy-group 0 node 0 priority 129
    set chassis cluster redundancy-group 0 node 1 priority 128
    set chassis cluster redundancy-group 1 node 0 priority 129
    set chassis cluster redundancy-group 1 node 1 priority 128
    set interfaces xe-6/0/0 gigether-options redundant-parent reth0
    set interfaces xe-6/1/0 gigether-options redundant-parent reth1
    set interfaces xe-18/0/0 gigether-options redundant-parent reth0
    set interfaces xe-18/1/0 gigether-options redundant-parent reth1
    set interfaces reth0 redundant-ether-options redundancy-group 1
    set interfaces reth0 unit 0 family inet address 1.1.1.1/24
    set interfaces reth1 redundant-ether-options redundancy-group 1
    set interfaces reth1 unit 0 family inet address 2.2.2.1/24
    set chassis cluster redundancy-group 1 interface-monitor xe-6/0/0 weight 255
    set chassis cluster redundancy-group 1 interface-monitor xe-6/1/0 weight 255
    set chassis cluster redundancy-group 1 interface-monitor xe-18/0/0 weight 255
    set chassis cluster redundancy-group 1 interface-monitor xe-18/1/0 weight 255
    set chassis cluster control-link-recovery
    set security zones security-zone untrust interfaces reth0.0
    set security zones security-zone trust interfaces reth1.0
    set routing-options static route 0.0.0.0/0 next-hop 1.1.1.254
    set routing-options static route 2.0.0.0/8 next-hop 2.2.2.254

    To quickly configure an EX8208 Core Switch, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    On {primary:node0}

    [edit]
    set interfaces xe-1/0/0 unit 0 family ethernet-switching port-mode access vlan members SRX5800
    set interfaces xe-2/0/0 unit 0 family ethernet-switching port-mode access vlan members SRX5800
    set interfaces vlan unit 50 family inet address 2.2.2.254/24
    set vlans SRX5800 vlan-id 50
    set vlans SRX5800 l3-interface vlan.50
    set routing-options static route 0.0.0.0/0 next-hop 2.2.2.1/24

    To quickly configure an MX240 edge router, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

    On {primary:node0}

    [edit]
    set interfaces xe-1/0/0 encapsulation ethernet-bridge unit 0 family ethernet-switching
    set interfaces xe-2/0/0 encapsulation ethernet-bridge unit 0 family ethernet-switching
    set interfaces irb unit 0 family inet address 1.1.1.254/24
    set routing-options static route 2.0.0.0/8 next-hop 1.1.1.1
    set routing-options static route 0.0.0.0/0 next-hop (upstream router)
    set vlans SRX5800 vlan-id X (could be set to “none”)
    set vlans SRX5800 domain-type bridge routing-interface irb.0
    set vlans SRX5800 domain-type bridge interface xe-1/0/0
    set vlans SRX5800 domain-type bridge interface xe-2/0/0

    Step-by-Step Procedure

    The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

    To configure a chassis cluster on an SRX Series device:

    Note: In cluster mode, the cluster is synchronized between the nodes when you execute a commit command. All commands are applied to both nodes regardless of from which device the command is configured.

    1. Configure the fabric (data) ports of the cluster that are used to pass RTOs in active/passive mode. For this example, use one of the 1-Gigabit Ethernet ports because running out of bandwidth using active/passive mode is not an issue. Define two fabric interfaces, one on each chassis, to connect together.
      {primary:node0}[edit]
      user@host# set interfaces fab0 fabric-options member-interfaces ge-11/3/0
      user@host# set interfaces fab1 fabric-options member-interfaces ge-23/3/0
    2. Because the SRX5800 Services Gateway chassis cluster configuration is contained within a single common configuration, to assign some elements of the configuration to a specific member only, you must use the Junos OS node-specific configuration method called groups. The set apply-groups ${node} command uses the node variable to define how the groups are applied to the nodes; each node recognizes its number and accepts the configuration accordingly. You must also configure out-of-band management on the fxp0 interface of the SRX5800 Services Gateway using separate IP addresses for the individual control planes of the cluster.

      Note: Configuring the backup router destination address as x.x.x.0/0 is not allowed.

      {primary:node0}[edit]
      user@host# set groups node0 system host-name SRX5800-1
      user@host# set groups node0 interfaces fxp0 unit 0 family inet address 10.3.5.1/24
      user@host# set groups node0 system backup-router 10.3.5.254 destination 0.0.0.0/16
      user@host# set groups node1 system host-name SRX5800-2
      user@host# set groups node1 interfaces fxp0 unit 0 family inet address 10.3.5.2/24
      user@host# set groups node1 system backup-router 10.3.5.254 destination 0.0.0.0/16
      user@host# set apply-groups “${node}”
    3. Configure redundancy groups for chassis clustering. Each node has interfaces in a redundancy group where interfaces are active in active redundancy groups (multiple active interfaces can exist in one redundancy group). Redundancy group 0 controls the control plane and redundancy group 1+ controls the data plane and includes the data plane ports. For this active/passive mode example, only one chassis cluster member is active at a time so you need to define redundancy groups 0 and 1 only. Besides redundancy groups, you must also define:
      • Redundant Ethernet groups—Configure how many redundant Ethernet interfaces (member links) will be active on the device so that the system can allocate the appropriate resources for it.

      • Priority for control plane and data plane—Define which device has priority (for chassis cluster, high priority is preferred) for the control plane, and which device is preferred to be active for the data plane.

        Note:

        • In active/passive or active/active mode, the control plane (redundancy group 0) can be active on a chassis different from the data plane (redundancy group 1+ and groups) chassis. However, for this example we recommend having both the control and data plane active on the same chassis member. When traffic passes through the fabric link to go to another member node, latency is introduced (z line mode traffic).

        • On SRX Series devices (SRX5000 line), the IPsec VPN is not supported in active/active chassis cluster configuration (that is, when there are multiple RG1+ redundancy groups).

      {primary:node0}[edit]
      user@host# set chassis cluster reth-count 2
      user@host# set chassis cluster redundancy-group 0 node 0 priority 129
      user@host# set chassis cluster redundancy-group 0 node 1 priority 128
      user@host# set chassis cluster redundancy-group 1 node 0 priority 129
      user@host# set chassis cluster redundancy-group 1 node 1 priority 128
    4. Configure the data interfaces on the platform so that in the event of a data plane failover, the other chassis cluster member can take over the connection seamlessly. Seamless transition to a new active node will occur with data plane failover. In case of control plane failover, all the daemons are restarted on the new node thus enabling a graceful restart to avoid losing neighborship with peers (ospf, bgp). This promotes a seamless transition to the new node without any packet loss.

      You must define the following items:

      • Define the membership information of the member interfaces to the reth interface.

      • Define which redundancy group the reth interface is a member of. For this active/passive example, it is always 1.

      • Define reth interface information such as the IP address of the interface.

      {primary:node0}[edit]
      user@host# set interfaces xe-6/0/0 gigether-options redundant-parent reth0
      user@host# set interfaces xe-6/1/0 gigether-options redundant-parent reth1
      user@host# set interfaces xe-18/0/0 gigether-options redundant-parent reth0
      user@host# set interfaces xe-18/1/0 gigether-options redundant-parent reth1
      user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
      user@host# set interfaces reth0 unit 0 family inet address 1.1.1.1/24
      user@host# set interfaces reth1 redundant-ether-options redundancy-group 1
      user@host# set interfaces reth1 unit 0 family inet address 2.2.2.1/24
    5. Configure the chassis cluster behavior in case of a failure. For the SRX5800 Services Gateway, the failover threshold is set at 255. You can alter the weights to determine the impact on the chassis failover. You must also configure control link recovery. The recovery automatically causes the secondary node to reboot should the control link fail, and then come back online. Enter these commands on node 0.
      {primary:node0}[edit]
      user@host# set chassis cluster redundancy-group 1 interface-monitor xe-6/0/0 weight 255
      user@host# set chassis cluster redundancy-group 1 interface-monitor xe-6/1/0 weight 255
      user@host# set chassis cluster redundancy-group 1 interface-monitor xe-18/0/0 weight 255
      user@host# set chassis cluster redundancy-group 1 interface-monitor xe-18/1/0 weight 255
      user@host# set chassis cluster control-link-recovery

      This step completes the chassis cluster configuration part of the active/passive mode example for the SRX5800 Services Gateway. The rest of this procedure describes how to configure the zone, virtual router, routing, EX8208 Core Switch, and MX240 Edge Router to complete the deployment scenario.

    6. Configure and connect the reth interfaces to the appropriate zones and virtual routers. For this example, leave the reth0 and reth1 interfaces in the default virtual router inet.0, which does not require any additional configuration.
      {primary:node0}[edit]
      user@host# set security zones security-zone untrust interfaces reth0.0
      user@host# set security zones security-zone trust interfaces reth1.0
    7. For this active/passive mode example, because of the simple network architecture, use static routes to define how to route to the other network devices.
      {primary:node0}[edit]
      user@host# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.254
      user@host# set routing-options static route 2.0.0.0/8 next-hop 2.2.2.254
    8. For the EX8208 Ethernet Switch, the following commands provide only an outline of the applicable configuration as it pertains to this active/passive mode example for the SRX5800 Services Gateway; most notably the VLANs, routing, and interface configuration.
      {primary:node0}[edit]
      user@host# set interfaces xe-1/0/0 unit 0 family ethernet-switching port-mode access vlan members SRX5800
      user@host# set interfaces xe-2/0/0 unit 0 family ethernet-switching port-mode access vlan members SRX5800
      user@host# set interfaces vlan unit 50 family inet address 2.2.2.254/24
      user@host# set vlans SRX5800 vlan-id 50
      user@host# set vlans SRX5800 l3-interface vlan.50
      user@host# set routing-options static route 0.0.0.0/0 next-hop 2.2.2.1/24
    9. For the MX240 edge router, the following commands provide only an outline of the applicable configuration as it pertains to this active/passive mode example for the SRX5800 Services Gateway; most notably you must use an IRB interface within a virtual switch instance on the switch.
      {primary:node0}[edit]
      user@host# set interfaces xe-1/0/0 encapsulation ethernet-bridge unit 0 family ethernet-switching
      user@host# set interfaces xe-2/0/0 encapsulation ethernet-bridge unit 0 family ethernet-switching
      user@host# set interfaces irb unit 0 family inet address 1.1.1.254/24
      user@host# set routing-options static route 2.0.0.0/8 next-hop 1.1.1.1
      user@host# set routing-options static route 0.0.0.0/0 next-hop (upstream router)
      user@host# set vlans SRX5800 vlan-id X (could be set to “none”)
      user@host# set vlans SRX5800 domain-type bridge routing-interface irb.0
      user@host# set vlans SRX5800 domain-type bridge interface xe-1/0/0
      user@host# set vlans SRX5800 domain-type bridge interface xe-2/0/0

    Results

    From operational mode, confirm your configuration by entering the show configuration command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

    > show configuration
    version x.xx.x;
    groups { 
        node0 { 
            system { 
                host-name SRX5800­1; 
                backup-router 10.3.5.254 destination 0.0.0.0/16; 
    
            } 
            interfaces { 
                fxp0 { 
                    unit 0 { 
                        family inet { 
                            address 10.3.5.1/24;
                        } 
                    } 
                }
            }
        }
        node1 { 
            system { 
                host-name SRX5800­2; 
                backup-router 10.3.5.254 destination 0.0.0.0/16; 
    
            } 
            interfaces { 
                fxp0 { 
                    unit 0 { 
                        family inet { 
                            address 10.3.5.2/24;
                        } 
                    } 
                }
            }
        }
    }
    apply-groups "${node}";
    system { 
            root-authentication { 
            encrypted-password "$ABC1234EFGH5678IJKL9101";
        }
        name-server { 
            4.2.2.2; 
        } 
        services { 
            ssh { 
                root-login allow;
            }
            netconf { 
                ssh;
            }
            web-management { 
                http {
                    interface fxp0.0;
                }
            } 
        }
    }
    chassis {
        cluster {
            control-link-recovery;
            reth-count 2;
            control-ports {
                fpc 1 port 0;
                fpc 13 port 0;
            }
            redundancy-group 0 {
                node 0 priority 129;
                node 1 priority 128;
            }
            redundancy-group 1 {
                node 0 priority 129;
                node 1 priority 128;
                interface-monitor {
                    xe–6/0/0 weight 255;
                    xe–6/1/0 weight 255;
                    xe–18/0/0 weight 255;
                    xe–18/1/0 weight 255;
                }
            } 
        }
    }
    interfaces { 
        xe–6/0/0 {
            gigether–options {
                redundant–parent reth0; 
            } 
        } 
        xe–6/1/0 { 
            gigether–options {
                redundant–parent reth1; 
            } 
        } 
        xe–18/0/0 { 
            gigether–options {
                redundant–parent reth0; 
            } 
        } 
        xe–18/1/0 { 
            gigether–options {
                redundant–parent reth1; 
            } 
        } 
        fab0 { 
            fabric–options {
                member–interfaces {
                    ge–11/3/0;
                } 
            } 
        } 
        fab1 { 
            fabric–options {
                member–interfaces {
                    ge–23/3/0;
                } 
            } 
        } 
        reth0 { 
            redundant–ether–options { 
                redundancy–group 1;
            }
            unit 0 { 
                family inet {
                    address 1.1.1.1/24;
                } 
            } 
        } 
        reth1 { 
            redundant–ether–options { 
                redundancy–group 1;
            }
            unit 0 { 
                family inet {
                    address 2.2.2.1/24;
                }
            } 
        }
    }
    routing–options {
        static {
            route 0.0.0.0/0 {
                next–hop 1.1.1.254;
        }
            route 2.0.0.0/8 {
                next–hop 2.2.2.254;
            }
        }
    }
    security {
        zones {
            security–zone trust {
                host–inbound–traffic {
                    system–services {
                        all;
                    }
                }
                interfaces {
                    reth0.0;
                }
            }
            security–zone untrust {
                interfaces {
                    reth1.0;
                }
            }
        }
        policies {
            from–zone trust to–zone untrust {
                policy 1 {
                    match {
                        source–address any;
                        destination–address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            } 
            default–policy {
                deny–all;
            }
        }
    }

    If you are done configuring the device, enter commit from configuration mode.

    Verification

    Confirm that the configuration is working properly.

    Verifying Chassis Cluster Status

    Purpose

    Verify the chassis cluster status, failover status, and redundancy group information.

    Action

    From operational mode, enter the show chassis cluster status command.

    {primary:node0}
    show chassis cluster status
    Cluster ID: 1
    Node                      Priority     Status    Preempt  Manual failover
    
    Redundancy group: 0 , Failover count: 1
        node0                   129         primary   no       no
        node1                   128         secondary no       no
    
    Redundancy group: 1 , Failover count: 1
        node0                   129           primary   no       no
        node1                   128           secondary no       no
    

    Verifying Chassis Cluster Interfaces

    Purpose

    Verify information about chassis cluster interfaces.

    Action

    From operational mode, enter the show chassis cluster interfaces command.

    {primary:node0}
    user@host> show chassis cluster interfaces
    Control link name: fxp1
    
    Redundant-ethernet Information:
        Name         Status      Redundancy-group
        reth0        Up          1
        reth1        Up          1
    
    Interface Monitoring:
        Interface         Weight    Status    Redundancy-group
        xe-6/0/0          255       Up        1
        xe-6/1/0          255       Up        1
        xe-18/0/0         255       Up        1
        xe-18/1/0         255       Up        1
    

    Verifying Chassis Cluster Statistics

    Purpose

    Verify information about chassis cluster services and control link statistics (heartbeats sent and received), fabric link statistics (probes sent and received), and the number of RTOs sent and received for services.

    Action

    From operational mode, enter the show chassis cluster statistics command.

    {primary:node0}
    user@host> show chassis cluster statistics
    Control link statistics:
        Control link 0:
            Heartbeat packets sent: 258689
            Heartbeat packets received: 258684
            Heartbeat packets errors: 0
    Fabric link statistics:
        Child link 0
            Probes sent: 258681
            Probes received: 258681
    Services Synchronized:
        Service name                              RTOs sent    RTOs received
        Translation context                       0            0
        Incoming NAT                              0            0
        Resource manager                          6            0
        Session create                            161          0
        Session close                             148          0
        Session change                            0            0
        Gate create                               0            0
        Session ageout refresh requests           0            0
        Session ageout refresh replies            0            0
        IPSec VPN                                 0            0
        Firewall user authentication              0            0
        MGCP ALG                                  0            0
        H323 ALG                                  0            0
        SIP ALG                                   0            0
        SCCP ALG                                  0            0
        PPTP ALG                                  0            0
        RPC ALG                                   0            0
        RTSP ALG                                  0            0
        RAS ALG                                   0            0
        MAC address learning                      0            0
        GPRS GTP                                  0            0
       

    Verifying Chassis Cluster Control Plane Statistics

    Purpose

    Verify information about chassis cluster control plane statistics (heartbeats sent and received) and the fabric link statistics (probes sent and received).

    Action

    From operational mode, enter the show chassis cluster control-plane statistics command.

    {primary:node0}
    user@host> show chassis cluster control-plane statistics
    Control link statistics:
        Control link 0:
            Heartbeat packets sent: 258689
            Heartbeat packets received: 258684
            Heartbeat packets errors: 0
    Fabric link statistics:
        Child link 0
            Probes sent: 258681
            Probes received: 258681
    

    Verifying Chassis Cluster Data Plane Statistics

    Purpose

    Verify information about the number of RTOs sent and received for services.

    Action

    From operational mode, enter the show chassis cluster data-plane statistics command.

    {primary:node0}
    user@host> show chassis cluster data-plane statistics
    Services Synchronized:
        Service name                              RTOs sent    RTOs received
        Translation context                       0            0
        Incoming NAT                              0            0
        Resource manager                          6            0
        Session create                            161          0
        Session close                             148          0
        Session change                            0            0
        Gate create                               0            0
        Session ageout refresh requests           0            0
        Session ageout refresh replies            0            0
        IPSec VPN                                 0            0
        Firewall user authentication              0            0
        MGCP ALG                                  0            0
        H323 ALG                                  0            0
        SIP ALG                                   0            0
        SCCP ALG                                  0            0
        PPTP ALG                                  0            0
        RPC ALG                                   0            0
        RTSP ALG                                  0            0
        RAS ALG                                   0            0
        MAC address learning                      0            0
        GPRS GTP                                  0            0

    Verifying Chassis Cluster Redundancy Group Status

    Purpose

    Verify the state and priority of both nodes in a cluster and information about whether the primary node has been preempted or whether there has been a manual failover.

    Action

    From operational mode, enter the chassis cluster status redundancy-group command.

    {primary:node0}
    user@host> show chassis cluster status redundancy-group 1
    Cluster ID: 1
        Node               Priority    Status    Preempt  Manual failover
    
    	Redundancy-Group: 1, Failover count: 1
        node0              100          primary   no       no
        node1              50           secondary no       no
    

    Troubleshooting with Logs

    Purpose

    Use these logs to identify any chassis cluster issues. You must run these logs on both nodes.

    Action

    From operational mode, enter these show log commands.

    user@host> show log jsrpd

    user@host> show log chassisd

    user@host> show log messages

    user@host> show log dcd

    user@host> show traceoptions

    Modified: 2018-04-04