Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Troubleshooting Chassis Cluster Management Issues

Unable to Manage an SRX Series Chassis Cluster Using the Management Port or Revenue Ports

Problem

Description

Cannot manage the SRX Series chassis cluster using the management port or revenue ports.

Environment

SRX Series chassis cluster

Diagnosis

  1. Which node in the chassis cluster are you using to manage the cluster?

    • Primary node—Proceed to:

      • Manage the Chassis Cluster Using J-Web.

        Note:

        You can use J-Web to manage only the primary node.

      • Manage the Chassis Cluster Using the Revenue Port or fxp0 Management Port.

        Note:

        You can use the revenue port or fxp0 management port to manage the primary node.

    • Secondary node—Proceed to Manage the Chassis Cluster Using the fxp0 Management Port

      Note:

      You can manage the secondary node only by using the fxp0 management port.

Resolution

Manage the Chassis Cluster Using J-Web

Note:

You can use J-Web to manage only the primary node.

  1. Connect a console to the primary node.

  2. Using the CLI, run the show system services web-management command.

  3. Check whether the loopback interface (lo0) is configured under the Web management HTTP/HTTPS configuration. See web-management (System Services) .

  4. If the loopback interface (lo0) is configured under the Web management HTTP/HTTPS configuration, remove the loopback interface by running the delete system services web-management http interface lo.0 command.

  5. Commit the change, and check whether you can now manage the chassis cluster.

  6. If you still cannot manage the chassis cluster, proceed to Manage Chassis Cluster Using the Revenue Port or fxp0 Management Port.

Manage Chassis Cluster Using the Revenue Port or fxp0 Management Port

Note:

You can use both the revenue port or fxp0 management port to manage the primary node.

  1. Connect to a console using the revenue port of the primary node which you want to use as a management interface.

  2. Verify the configuration of the management interface:

    1. Verify that the required system services (SSH, Telnet, HTTP) are enabled at the host-inbound-traffic hierarchy level in the relevant zone:

    2. Verify that the required system services (SSH, Telnet, HTTP) are enabled at the system services hierarchy level:

  3. Does ping to the management interface work?

  4. Using the CLI, run the show interfaces terse command:

    In the output, is the status of FXP0 interface Up, and does it provide an IP address?

    • Yes: Proceed to step 5.

    • No: Verify the following:

      1. Using the CLI, verify that the fxp0 interface is configured correctly: show groups.

        Sample output:

      2. Check the condition of the cable that is connected to the fxp0 interface. Is the cable in good condition?

        • Yes: Proceed to the next step.

        • No: Replace the cable and try to manage the chassis cluster. If you still cannot manage the chassis cluster, proceed to the next step.

      3. Using the CLI, check for incrementing error counters: show interfaces fxp0.0 extensive.

        • Yes: If you find any errors in the output, proceed to What’s Next to open a case with Juniper Networks technical support.

        • No: If there are no errors in the output and if you still cannot manage the chassis cluster, proceed to step 5.

  5. Check whether the IP address of the fxp0 interface and the IP address of the management device are in the same subnet.

    • Yes: Proceed to the step 6.

    • No: Using the CLI, check if there is a route for the management device IP address: show route <management device IP>:

      1. If a route does not exist for the management device IP address, add a route for the management subnet in the inet.0 table with the next-hop as the backup router IP address.

  6. Using the CLI, check whether there is an ARP entry for the management device on the services gateway: show arp no-resolve | match <ip>.

    1. Yes: Check whether the chassis cluster has multiple routes to the management device: show route <device-ip>.

    2. No: Proceed to What’s Next to open a case with Juniper Networks technical support.

Manage the Chassis Cluster Using the fxp0 Management Port

Note:

You can use only the fxp0 management port to manage the secondary node.

  1. Verify the configuration of management interface on the secondary node:

    • Verify that the required system services (SSH, Telnet, HTTP) are enabled at the host-inbound-traffic hierarchy level:

    • Verify that the required system services (SSH, Telnet, HTTP) are enabled at the system services hierarchy level:

    See Unable to Manage an SRX Series Chassis Cluster Using fxp0 When the Destination in the Backup Router is 0/0 and Configuring backup-router Command on Chassis Cluster for more information about the configuration guidelines.

    If the configuration is correct and you still cannot manage the chassis cluster, proceed to step 2.

  2. Are the IP addresses of the fxp0 interfaces of the primary node and the secondary node in the same subnet?

    • Yes: Proceed to What’s Next.

    • No: Configure the fxp0 interfaces of the primary node and the secondary node in the same subnet. Go to step 1 and verify the configuration.

What’s Next

  • If the issue persists, see KB Article KB20795.

  • If you wish to debug further, see KB Article KB21164 to check the debug logs.

  • To open a JTAC case with the Juniper Networks support team, see Data Collection for Customer Support for the data you should collect to assist in troubleshooting prior to opening a JTAC case.

Manage the Chassis Cluster Using J-Web

Note:

You can use J-Web to manage only the primary node.

  1. Connect a console to the primary node.

  2. Using the CLI, run the show system services web-management command.

  3. Check whether the loopback interface (lo0) is configured under the Web management HTTP/HTTPS configuration. See web-management (System Services) .

  4. If the loopback interface (lo0) is configured under the Web management HTTP/HTTPS configuration, remove the loopback interface by running the delete system services web-management http interface lo.0 command.

  5. Commit the change, and check whether you can now manage the chassis cluster.

  6. If you still cannot manage the chassis cluster, proceed to Manage Chassis Cluster Using the Revenue Port or fxp0 Management Port.

Manage Chassis Cluster Using the Revenue Port or fxp0 Management Port

Note:

You can use both the revenue port or fxp0 management port to manage the primary node.

  1. Connect to a console using the revenue port of the primary node which you want to use as a management interface.

  2. Verify the configuration of the management interface:

    1. Verify that the required system services (SSH, Telnet, HTTP) are enabled at the host-inbound-traffic hierarchy level in the relevant zone:

    2. Verify that the required system services (SSH, Telnet, HTTP) are enabled at the system services hierarchy level:

  3. Does ping to the management interface work?

  4. Using the CLI, run the show interfaces terse command:

    In the output, is the status of FXP0 interface Up, and does it provide an IP address?

    • Yes: Proceed to step 5.

    • No: Verify the following:

      1. Using the CLI, verify that the fxp0 interface is configured correctly: show groups.

        Sample output:

      2. Check the condition of the cable that is connected to the fxp0 interface. Is the cable in good condition?

        • Yes: Proceed to the next step.

        • No: Replace the cable and try to manage the chassis cluster. If you still cannot manage the chassis cluster, proceed to the next step.

      3. Using the CLI, check for incrementing error counters: show interfaces fxp0.0 extensive.

        • Yes: If you find any errors in the output, proceed to What’s Next to open a case with Juniper Networks technical support.

        • No: If there are no errors in the output and if you still cannot manage the chassis cluster, proceed to step 5.

  5. Check whether the IP address of the fxp0 interface and the IP address of the management device are in the same subnet.

    • Yes: Proceed to the step 6.

    • No: Using the CLI, check if there is a route for the management device IP address: show route <management device IP>:

      1. If a route does not exist for the management device IP address, add a route for the management subnet in the inet.0 table with the next-hop as the backup router IP address.

  6. Using the CLI, check whether there is an ARP entry for the management device on the services gateway: show arp no-resolve | match <ip>.

    1. Yes: Check whether the chassis cluster has multiple routes to the management device: show route <device-ip>.

    2. No: Proceed to What’s Next to open a case with Juniper Networks technical support.

Manage the Chassis Cluster Using the fxp0 Management Port

Note:

You can use only the fxp0 management port to manage the secondary node.

  1. Verify the configuration of management interface on the secondary node:

    • Verify that the required system services (SSH, Telnet, HTTP) are enabled at the host-inbound-traffic hierarchy level:

    • Verify that the required system services (SSH, Telnet, HTTP) are enabled at the system services hierarchy level:

    See Unable to Manage an SRX Series Chassis Cluster Using fxp0 When the Destination in the Backup Router is 0/0 and Configuring backup-router Command on Chassis Cluster for more information about the configuration guidelines.

    If the configuration is correct and you still cannot manage the chassis cluster, proceed to step 2.

  2. Are the IP addresses of the fxp0 interfaces of the primary node and the secondary node in the same subnet?

    • Yes: Proceed to What’s Next.

    • No: Configure the fxp0 interfaces of the primary node and the secondary node in the same subnet. Go to step 1 and verify the configuration.

What’s Next

  • If the issue persists, see KB Article KB20795.

  • If you wish to debug further, see KB Article KB21164 to check the debug logs.

  • To open a JTAC case with the Juniper Networks support team, see Data Collection for Customer Support for the data you should collect to assist in troubleshooting prior to opening a JTAC case.

Unable to Manage the Secondary Node of a Chassis Cluster Using J-Web

Problem

Description

Cannot manage the secondary node of a chassis cluster using the J-Web interface.

Environment

SRX Series chassis cluster

Symptoms

When in the Junos Services Redundancy Protocol (JSRP) chassis cluster mode, you cannot manage redundancy group 0 (RG0) on the secondary node using the J-Web interface.

Cause

  • You can use the J-Web interface to manage redundancy group 0 only on the primary node.

  • The processes that J-Web references are not running on the secondary node.

Example

The following example shows the output of syslog and system process on both node0 and node1 after RG0 was failed over from node1 to node0.

  • On node1, web-management process (httpd-gk) was terminated (exited).

  • On node0, web-management process (httpd-gk) was started.

  • Two http-related processes (httpd-gk and httpd), run only on node0, which is the new primary node of RG0.

Note:

This limits remote procedure calls (RPCs) from the J-Web logic, and subsequently, pages that can be issued from the secondary node.

Solution

You can manage the secondary node of a chassis cluster using the CLI (SSH, telnet, and console). See Manage the Chassis Cluster Using the fxp0 Management Port

Unable to Manage an SRX Series Chassis Cluster Using fxp0 When the Destination in the Backup Router is 0/0

SUMMARY This topic explains, with an example, how to manage an SRX Series chassis cluster configured using the backup-router configuration through the fxp0 interface.

Problem

Description

The management device cannot manage the chassis cluster through an fxp0 interface, but it can ping both fxp0 interfaces.

Sample Topology

The topology, IP addresses, and configuration are as follows:

  • Primary fxp0: 192.168.1.1/24

  • Secondary fxp0: 192.168.1.2/24

  • Gateway for fxp0: 192.168.1.254

  • Management device: 172.16.1.1/24

Environment

SRX Series chassis cluster

Cause

There is a route for 172.16.1.1 through the interfaces other than the fxp0 interface on the cluster devices. We do not recommend using 0.0.0.0/0 as the backup-router destination. Ping works because the echo reply for an incoming echo request to the fxp0 interface is sent out following the route for 172.16.1.1 through interfaces other than fxp0, but Telnet fails.

Solution

Remove the route for 172.16.1.1 in the routing table, and set a more specific backup-router destination in group node0/node1.

For example:

No changes are displayed in the routing table after the configuration is applied because the backup-router configuration is intended to facilitate management access on the backup node only. Access to the primary node is enabled through routing on the primary node.

Thus, when the backup router configuration is complete, you can see that a route is injected into the forwarding table on the secondary node. You cannot see the routing table on the secondary node because the routing subsystem does not run on the secondary node.

Sample Output when the Backup router is Configured with Destination 0/0

  • Routing table on primary node:

  • Forwarding table on secondary node with destination 0/0:

Sample Output when the Backup router is Configured with Destination 172.16.1.1/32

  • Routing table on primary node:

  • Forwarding table on primary node:

    Note:

    On the primary node, route 172.16.1.1/32 of the backup router is not shown in the sample output.

  • Forwarding table on the secondary node:

    Note:

    On the secondary node, route 172.16.1.1/32 of the backup router is shown in the sample output. This facilitates access to the secondary node through the fxp0 interface.

If a particular subnet has a route configured through the backup router and a static route under routing-options, there could be problems accessing the fxp0 interface. In the example above, the issue with accessing the fxp0 interface from the management device occurs when :

  • The same route exists as a static route and through the backup router.

  • There is a static route that is more specific than the route through the backup router.

In the examples, when the routes from the primary node are synchronized to the secondary node's forwarding table, the route configured under static route takes precedence over the route under backup router. If 0/0 is configured under backup-router, the chances of a better matching route under static route is higher. Hence, we recommend avoiding 0/0 under backup router.

If you want to configure routes to the same destination using backup router as well as the static route, split the routes when configuring under backup-router. This makes the routes configured under backup router as the preferred routes and ensures that the fxp0 interface is accessible.

Unable to Access the Management IP Address of the Secondary Node in a Chassis Cluster

Problem

Description

Unable to access the management IP address on the fxp0 interface of the secondary node in a chassis cluster.

Environment

SRX Series chassis cluster

Symptoms

  • Cannot access the management IP address on the fxp0 interface of the secondary node in a chassis cluster.

  • The fxp0 interface is reachable only by hosts that are on the same subnet as the management IP address. If the host is on a different subnet than the management IP address, it fails to connect.

Cause

  • The secondary node's routing sub-system is not running.

  • This is an expected behavior and works as designed. The secondary node’s routing engine is not operational until a failover. The RPD does not work in the secondary node when the primary node is active.

Solution

Use the backup router's configuration statement to get management access. With the backup router's configuration, the secondary node can be accessed from an external subnet for management purposes.

Sample backup router configuration:

Note:

The destination of the system backup-router should not be 0.0.0.0/0. It must be a proper subnet range /8 or higher. Multiple destinations can be included, if the management IP address range is not contiguous. See Configuring a Backup Router for more information on the backup-router configuration.

Configuring backup-router Command on Chassis Cluster

SUMMARY How to back up a router in an SRX Series chassis cluster using the backup-router configuration command.

Problem

Description

Intermittent connectivity issues to NSM and other management hosts from the secondary node.

Environment

SRX Series chassis cluster

Cause

Setting a destination of 0.0.0.0/0 on the backup router (without configuration) is not supported.

Example of an incorrect configuration:

Solution

See Configuring a Backup Router for the recommended way to set up a backup router by using a non-zero prefix.

Example of a non-zero subnet backup-router configuration:

As an alternative to the 0/0 backup-router destination, here is another example where 0/0 gets split into two prefixes:

Note:

If multiple networks need to be reachable through the backup router, you can add multiple destination entries to the configuration. The backup-router configuration is used only by the RG0 secondary node. The primary node continues to use the inet.0 route table.