[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Chassis Cluster Configuration Scenarios

This section describes the following deployment scenarios:

Before You Begin

For background information, read:

Active/Passive Chassis Cluster Scenario

In this case, a single device in the cluster is used to route all traffic while the other device is used only in the event of a failure. When a failure occurs, the backup device becomes master and controls all forwarding.

Figure 186: Active/Passive Chassis Cluster Scenario (J Series Devices)

Image g030647.gif

An active/passive chassis cluster can be achieved by using redundant Ethernet interfaces (reths) that are all assigned to the same redundancy group. If any of the interfaces in an active group in a node fails, the group is declared inactive and all the interfaces in the group will fail over to the other node.

This configuration minimizes the traffic over the fabric link because only one node in the cluster will forward traffic at any given time.

CLI Configuration

  1. Enabling clustering

    In node 0:

    user@host> set chassis cluster node 0 cluster-id 1
    warning: A reboot is required for chassis cluster to be enabled

    In node 1:

    user@host> set chassis cluster node 1 cluster-id 1 reboot
    Successfully enabled chassis cluster. Going to reboot now.
  2. Management interface

    In a cluster, the configuration is shared among the cluster members. Member-specific configurations (such as the IP address of the management port of each member) are entered using configuration groups.

    {primary:node1}
    user@host# set groups node0 system host-name J2320-A
    {primary:node1}
    user@host# set groups node0 interfaces fxp0 unit 0 family inet address 192.168.3.110/24
    {primary:node1}
    user@host#set groups node1 system host-name J2320-B
    {primary:node1}
    user@host# set groups node1 interfaces fxp0 unit 0 family inet address 192.168.3.111/24
    {primary:node1}
    user@host# set apply-groups “${node}”
  3. Fabric interface
    {primary:node1}
    user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1
    {primary:node1}
    user@host# set interfaces fab1 fabric-options member-interfaces ge-4/0/1
  4. Redundancy groups
    {primary:node1}
    user@host# set chassis cluster reth-count 2
    {primary:node1}
    user@host# set chassis cluster heartbeat-interval 1000
    {primary:node1}
    user@host# set chassis cluster heartbeat-threshold 3
    {primary:node1}
    user@host# set chassis cluster node 0
    {primary:node1}
    user@host# set chassis cluster node 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 node 0 priority 100
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 node 1 priority 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 node 0 priority 100
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 node 1 priority 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor fe-1/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor fe-5/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor ge-4/0/0 weight 255
  5. Redundant Ethernet interfaces
    {primary:node1}
    user@host# set interfaces ge-0/0/0 gigether-options redundant-parent reth1
    {primary:node1}
    user@host# set interfaces ge-4/0/0 gigether-options redundant-parent reth1
    {primary:node1}
    user@host# set interfaces fe-1/0/0 fastether-options redundant-parent reth0
    {primary:node1}
    user@host# set interfaces fe-5/0/0 fastether-options redundant-parent reth0
    {primary:node1}
    user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
    {primary:node1}
    user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24
    {primary:node1}
    user@host# set interfaces reth1 redundant-ether-options redundancy-group 1
    {primary:node1}
    user@host# set interfaces reth1 unit 0 family inet address 1.2.0.233/24
  6. Security zones
    {primary:node1}
    user@host# set security zones security-zone Untrust interfaces reth1.0
    {primary:node1}
    user@host# set security zones security-zone Trust interfaces reth0.0
  7. Security policies
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match source-address any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match destination-address any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match application any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY then permit

J-Web Configuration

  1. Enabling clustering

    See Step 1 in CLI Configuration.

  2. Management interface

    See Step 2 in CLI Configuration.

  3. Fabric interface

    See Step 3 in CLI Configuration.

  4. Redundancy groups
  5. Redundant Ethernet interfaces
  6. Security zones
  7. Security policies

Active/Passive Chassis Cluster with IPsec Tunnel Scenario

In this case, a single device in the cluster terminates in an IPsec tunnel and is used to process all traffic while the other device is used only in the event of a failure. When a failure occurs, the backup device becomes master and controls all forwarding.

Figure 187: Active/Passive Chassis Cluster with IPsec Tunnel Scenario (SRX Series Devices)

Image g030650.gif

An active/passive chassis cluster can be achieved by using redundant Ethernet interfaces (reths) that are all assigned to the same redundancy group. If any of the interfaces in an active group in a node fails, the group is declared inactive and all the interfaces in the group will fail over to the other node.

This configuration provides a way to terminate a site-to-site IPsec tunnel in an active/passive cluster where a redundant Ethernet interface is used as the tunnel endpoint. In the event of a failure, the redundant Ethernet interface in the backup SRX Series device will become active, forcing the tunnel to be terminated in the backup SRX Series device. Because tunnel keys and session information are synchronized between the members of the chassis cluster, a failover will not require the tunnel to be renegotiated and the established sessions will be maintained.

CLI Configuration

  1. Enabling clustering

    In node 0:

    user@host> set chassis cluster node 0 cluster-id 1
    warning: A reboot is required for chassis cluster to be enabled

    In node 1:

    user@host> set chassis cluster node 1 cluster-id 1 reboot
    Successfully enabled chassis cluster. Going to reboot now.
    {primary:node1}
    user@host# set chassis cluster control-ports fpc 2 port 0
    {primary:node1}
    user@host# set chassis cluster control-ports fpc 14 port 0
  2. Management interface

    In a cluster, the configuration is shared among the cluster members. Member-specific configurations (such as the IP address of the management port of each member) are entered using configuration groups.

    {primary:node1}
    user@host# set groups node0 system host-name SRX5800-1
    {primary:node1}
    user@host# set groups node0 interfaces fxp0 unit 0 family inet address 172.19.100.50/24
    {primary:node1}
    user@host#set groups node1 system host-name SRX5800-2
    {primary:node1}
    user@host# set groups node1 interfaces fxp0 unit 0 family inet address 172.19.100.51/24
    {primary:node1}
    user@host# set apply-groups “${node}”
  3. Fabric interface
    {primary:node1}
    user@host# set interfaces fab0 fabric-options member-interfaces xe-5/3/0
    {primary:node1}
    user@host# set interfaces fab1 fabric-options member-interfaces xe-17/3/0
  4. Redundancy groups
    {primary:node1}
    user@host# set chassis cluster reth-count 2
    {primary:node1}
    user@host# set chassis cluster heartbeat-interval 1000
    {primary:node1}
    user@host# set chassis cluster heartbeat-threshold 3
    {primary:node1}
    user@host# set chassis cluster node 0
    {primary:node1}
    user@host# set chassis cluster node 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 node 0 priority 254
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 node 1 priority 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 node 0 priority 254
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 node 1 priority 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 preempt
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor xe-5/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor xe-5/1/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor xe-17/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor xe-17/1/0 weight 255
  5. Redundant Ethernet interfaces
    {primary:node1}
    user@host# set interfaces xe-5/1/0 gigether-options redundant-parent reth1
    {primary:node1}
    user@host# set interfaces xe-17/1/0 gigether-options redundant-parent reth1
    {primary:node1}
    user@host# set interfaces xe-5/0/0 gigether-options redundant-parent reth0
    {primary:node1}
    user@host# set interfaces xe-17/0/0 gigether-options redundant-parent reth0
    {primary:node1}
    user@host# set interfaces reth0 redundant-ether-options redundancy-group 1
    {primary:node1}
    user@host# set interfaces reth0 unit 0 family inet address 10.1.1.60/16
    {primary:node1}
    user@host# set interfaces reth1 redundant-ether-options redundancy-group 1
    {primary:node1}
    user@host# set interfaces reth1 unit 0 family inet address 10.2.1.60/16
  6. IPsec configuration
    {primary:node1}
    user@host# set interfaces st0 unit 0 multipoint family inet address 10.10.1.1/30
    {primary:node1}
    user@host# set interfaces st0 family inet address 10.10.1.1/30
    {primary:node1}
    user@host# set security ike policy preShared mode main
    {primary:node1}
    user@host# set security ike policy preShared proposal-set standard
    {primary:node1}
    user@host# set security ike policy preShared pre-shared-key ascii-text "juniper"## Encrypted password
    {primary:node1}
    user@host# set security ike gateway SRX210-1 ike-policy preShared
    {primary:node1}
    user@host# set security ike gateway SRX210-1 address 10.1.1.90
    {primary:node1}
    user@host# set security ike gateway SRX210-1 external-interface reth0.0
    {primary:node1}
    user@host# set security ipsec policy std proposal-set standard
    {primary:node1}
    user@host# set security ipsec vpn SRX210-1 bind-interface st0.0
    {primary:node1}
    user@host# set security ipsec vpn SRX210-1 vpn-monitor optimized
    {primary:node1}
    user@host# set security ipsec vpn SRX210-1 ike gateway SRX210-1
    {primary:node1}
    user@host# set security ipsec vpn SRX210-1 ike ipsec-policy std
    {primary:node1}
    user@host# set security ipsec vpn SRX210-1 establish-tunnels immediately
  7. Static routes
    {primary:node1}
    user@host# set routing-options static route 0.0.0.0/0 next-hop 10.2.1.1
    {primary:node1}
    user@host# set routing-options static route 10.3.0.0/16 next-hop 10.10.1.2
  8. Security zones
    {primary:node1}
    user@host# set security zones security-zone Untrust host-inbound-traffic system-services all
    {primary:node1}
    user@host# set security zones security-zone Untrust host-inbound-traffic protocols all
    {primary:node1}
    user@host# set security zones security-zone Untrust interfaces reth1.0
    {primary:node1}
    user@host# set security zones security-zone Trust host-inbound-traffic system-services all
    {primary:node1}
    user@host# set security zones security-zone Trust host-inbound-traffic protocols all
    {primary:node1}
    user@host# set security zones security-zone Trust interfaces reth0.0
    {primary:node1}
    user@host# set security zones security-zone vpn host-inbound-traffic system-services all
    {primary:node1}
    user@host# set security zones security-zone vpn host-inbound-traffic protocols all
    {primary:node1}
    user@host# set security zones security-zone vpn interfaces st0.0
  9. Security policies
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match source-address any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match destination-address any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match application any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone vpn policy ANY then permit

J-Web Configuration

  1. Enabling clusters

    See Step 1 in CLI Configuration.

  2. Management interface

    See Step 2 in CLI Configuration.

  3. Fabric interface

    See Step 3 in CLI Configuration.

  4. Redundancy groups
  5. Redundant Ethernet interfaces
  6. IPsec configuration
  7. Static routes
  8. Security zones
  9. Security policies

Asymmetric Routing Chassis Cluster Scenario

In this case, chassis cluster makes use of its asymmetric routing capability. Traffic received by a node is matched against that node’s session table. The result of this lookup determines whether or not that node should process the packet or forward it to the other node over the fabric link. Sessions are anchored on the egress node for the first packet that created the session. If traffic is received on the node in which the session is not anchored, those packets are forwarded over the fabric link to the node where the session is anchored.

Note: The anchor node for the session can change if there are changes in routing during the session.

Figure 188: Asymmetric Routing Chassis Cluster Scenario (J Series Devices)

Image g030648.gif

Figure 188 illustrates how asymmetric routing is supported in a chassis cluster. In this scenario, two Internet connections are used, with one being preferred. The connection to the Trust zone is done by using a redundant Ethernet interface to provide LAN redundancy for the devices in the Trust zone. This scenario describes two failover cases in which sessions originate in the Trust zone with a destination of the Internet (Untrust zone).

Case 1: Failures in the Trust Zone reth

Under normal operating conditions, traffic flows from the Trust zone interface fe-1/0/0, belonging to reth0.0, to the Internet. Because the primary Internet connection is on node 0, sessions are both created in node 0 and synced to node 1. However, session are only active on node 0.

A failure in interface fe-1/0/0 triggers a failover of the redundancy group, causing interface fe-5/0/0 in node 1 to become active. After the failover, traffic arrives at node 1. After session lookup, the traffic is sent to node 0 because the session is active on this node. Node 0 then processes the traffic and forwards it to the Internet. The return traffic follows a similar process. The traffic arrives at node 0 and gets processed for security purposes—for example., antispam scanning, antivirus scanning, and application of security policies—on node 0 because the session is anchored to node 0. The packet is then sent to node 1 via the fabric interface for egress processing and eventual transmission out of node 1 via interface fe-5/0/0.

Case 2: Failures in the Untrust Zone Interfaces

In this case, sessions are migrated from node to node. Under normal operating conditions, traffic is processed by only node 0. A failure of interface ge-0/0/0 on node 0 causes a change in the routing table, so that it now points to interface ge-7/0/0 in node 1. After the failure, sessions in node 0 become inactive, and the passive sessions in node 1 become active. Traffic arriving from the Trust zone is still received on interface fe-1/0/0, but is forwarded to node 1 for processing. After traffic is processed in node 1, it is forwarded to the Internet through interface ge-7/0/0.

In this chassis cluster configuration, redundancy group 1 is used to control the redundant Ethernet interface connected to the Trust zone. As configured in this scenario, redundancy group 1 fails over only if interface fe-1/0/0 or fe-5/0/0 fails, but not if the interfaces connected to the Internet fail. Optionally, the configuration could be modified to permit redundancy group 1 to monitor all interfaces connected to the Internet and fail over if an Internet link were to fail. So, for example, the configuration can allow redundancy group 1 to monitor ge-0/0/0 and make fe-5/0/0 active for reth0 if the ge-0/0/0 Internet link fails. (This option is not described in the configuration examples below.)

CLI Configuration

Note: First, do basic chassis cluster and management interfaces setup.

  1. Fabric interface
    {primary:node1}
    user@host# set interfaces fab0 fabric-options member-interfaces ge-0/0/1
    {primary:node1}
    user@host# set interfaces fab1 fabric-options member-interfaces ge-7/0/1
  2. Redundancy groups
    {primary:node1}
    user@host# set chassis cluster reth-count 1
    user@host# set chassis cluster heartbeat-interval 1000
    {primary:node1}
    user@host# set chassis cluster heartbeat-threshold 3
    {primary:node1}
    user@host# set chassis cluster node 0
    {primary:node1}
    user@host# set chassis cluster node 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 node 0 priority 100
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 node 1 priority 1
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor fe-1/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 1 interface-monitor fe-5/0/0 weight 255
  3. Redundant Ethernet interfaces
    {primary:node1}
    user@host# set interfaces ge-0/0/0 unit 0 family inet address 1.4.0.202/24
    {primary:node1}
    user@host# set interfaces fe-1/0/0 fastether-options redundant-parent reth0
    {primary:node1}
    user@host# set interfaces ge-7/0/0 unit 0 family inet address 1.2.1.233/24
    {primary:node1}
    user@host# set interfaces fe-5/0/0 fastether-options redundant-parent reth0
    {primary:node1}
    user@host# set interfaces reth0 unit 0 family inet address 10.16.8.1/24
  4. Static routes (one to each ISP, with preferred route through ge-0/0/0)
    {primary:node1}
    user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 1.4.0.1 metric 10
    {primary:node1}
    user@host# set routing-options static route 0.0.0.0/0 qualified-next-hop 1.2.1.1 metric 100
  5. Security zones
    {primary:node1}
    user@host# set security zones security-zone Untrust interfaces ge-0/0/0.0
    {primary:node1}
    user@host# set security zones security-zone Untrust interfaces ge-7/0/0.0
  6. Security policies
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match source-address any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match destination-address any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY match application any
    {primary:node1}
    user@host# set security policies from-zone Trust to-zone Untrust policy ANY then permit

J-Web Configuration

Note: First, enable clustering and do management interfaces setup.

  1. Fabric interface

    See Step 1 in CLI Configuration.

  2. Redundancy groups
  3. Redundant Ethernet interfaces
  4. Static routes (one to each ISP, with preferred route through ge-0/0/0)
  5. Security zones
  6. Security policies
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]