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

Chassis Cluster Configuration Scenarios

This section describes the following deployment scenarios for J-series chassis clusters:

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 62: Active/Passive Chassis Cluster Scenario

Image g030647.gif

An active/passive chassis cluster can be achieved by using redundant Ethernet interfaces reth0 and reth1. If any of the interfaces in a reth fails, the group is declared inactive and all its interfaces fail over to the other group. 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. Basic chassis cluster
    user@host> set chassis cluster node 0 cluster-id 1
    warning: A reboot is required for chassis cluster to be enabled
    user@host> set chassis cluster node 1 cluster-id 1 reboot
    Successfully enabled chassis cluster. Going to reboot now.
  2. Management interface
    {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 preempt
    {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

    (Optional) Redundancy group 0 (to monitor physical interfaces if data processing and control plane functions are in same node)

    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 interface-monitor fe-1/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 interface-monitor fe-5/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 interface-monitor ge-0/0/0 weight 255
    {primary:node1}
    user@host# set chassis cluster redundancy-group 0 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 zone
    {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. Access
    {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. Basic chassis cluster

    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 zone
  7. Access

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 that node processes the session or forwards it to the other node over the fabric link. Sessions are anchored on the node in which the first packet created the session, and the session is synced to the other node. If traffic is received on the node in which the session is not anchored, those packets are forwarded over the fabric link.

Figure 63: Asymmetric Routing Chassis Cluster Scenario

Image g030648.gif

Figure 63 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 reth 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 to interface fe-1/0/0 belonging to reth0.0 on node 0. Because the primary Internet connection is in node 0, sessions are created in both node 0 and node 1, but active in only 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—traffic arrives at node 0, is processed at node 0 because the session is anchored to this node, and is sent to node 1 through the fabric interface, where node 1 forwards it through 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-4/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-4/0/0.

In this chassis cluster configuration, redundancy group 1 is used to control the reth interface connected to the Trust zone. This redundancy group (and, therefore, reth0) fails over only if interface fe-1/0/0 or fe- 5/0/0 fails, but not if any of the interfaces connected to the Internet fail.

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-4/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 fe-1/0/1 disable
    {primary:node1}
    user@host# set interfaces ge-4/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 zone
    {primary:node1}
    user@host# set security zones security-zone Untrust interfaces ge-0/0/0.0 host-inboundtraffic system-services dhcp
    {primary:node1}
    user@host# set security zones security-zone Untrust interfaces ge-4/0/0.0 host-inboundtraffic system-services dhcp
  6. Access
    {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, do basic chassis cluster and 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 zone
  6. Access
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]