Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring an SRX Series Services Gateway for the High-End as a Chassis Cluster

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. No control port configuration is needed for SRX1400, SRX3400, or SRX3600 devices.

  • 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.
    • Enable the 3des-cbc encryption algorithm:
      user@host# set security ipsec internal security-association manual encryption algorithm 3des-cbc
    • Configure the encryption key:
      user@host# set security ipsec internal security-association manual encryption key ascii-text "$9$x.CNwgDi.Qz6HqORhy8LjHqm5FREyrK8QFSeKMN-24aUjqF39tu1mftOIhvMjHqf5FApBREy"
    • Activate internal IPsec:
      user@host> request security internal-security-association refresh
    • 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
      

  • 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 0user@host# set chassis cluster control-ports fpc 13 port 0user@host# commit
    • On node 1:
      user@host# set chassis cluster control-ports fpc 1 port 0user@host# set chassis cluster control-ports fpc 13 port 0user@host# commit
  • 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.

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 a high-end SRX Series device. The basic active/passive example is the most common type of chassis cluster. The following high-end SRX Series devices are supported:

• SRX1400
• SRX3400
• SRX3600
• SRX5400
• SRX5600
• SRX5800

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 should the active device become 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 NAT Overview, Security Policies Overview, and 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 (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 a High-End SRX Series Device Topology Example

Configuration

CLI Quick Configuration

To quickly configure a chassis cluster on an SRX5800 Services Gateway, copy the following commands and paste them into the CLI:

On {primary:node0}

To quickly configure an EX8208 Core Switch, copy the following commands and paste them into the CLI:

On {primary:node0}

To quickly configure an MX240 edge router, copy the following commands and paste them into the CLI:

On {primary:node0}

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.

To configure a chassis cluster on a high-end 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.
   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.

   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).

   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.
   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.
   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.
   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.
   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.
   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.
   user@host# set interfaces xe-1/0/0 encapsulation ethernet-bridge unit 0 family bridge
   user@host# set interfaces xe-2/0/0 encapsulation ethernet-bridge unit 0 family bridge
   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 bridge-domains SRX5800 vlan-id X (could be set to “none”)
   user@host# set bridge-domains SRX5800 domain-type bridge routing-interface irb.0
   user@host# set bridge-domains SRX5800 domain-type bridge interface xe-1/0/0
   user@host# set bridge-domains 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.

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 "$1$zTMjraKG$qU8rjxoHzC6Y/WDmYpR9r.";
    }
    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

To confirm that the configuration is working properly, perform these tasks:

• Verifying Chassis Cluster Status
• Verifying Chassis Cluster Interfaces
• Verifying Chassis Cluster Statistics
• Verifying Chassis Cluster Control Plane Statistics
• Verifying Chassis Cluster Data Plane Statistics
• Verifying Chassis Cluster Redundancy Group Status
• Troubleshooting with Logs

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.

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.

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.

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.

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.

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.

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 should run these logs on both nodes.

Action

From operational mode, enter these show log commands.