Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Provision a Virtual Chassis Using the Phone-Home Client

SUMMARY Phone-home provisioning on a Virtual Chassis is a form of zero-touch provisioning (ZTP). The phone-home client (PHC) on the Virtual Chassis gets bootstrap information over the network from a phone-home server (PHS) and provisions the Virtual Chassis. The only user intervention required on the client side is to physically wire the Virtual Chassis members together and connect any port on the Virtual Chassis to the network.

Overview of Phone-Home Provisioning for a Virtual Chassis

With phone-home provisioning, a phone-home client (PHC) on a device initially provisions the device with a software image and configuration from a central network management data source called the phone-home server (PHS), requiring little or no user intervention at the remote site.

A Virtual Chassis consists of a set of devices interconnected together using ports called Virtual Chassis ports (VCPs). You configure and manage the Virtual Chassis as a single device. Starting with Junos OS Release 20.3R1, we’ve made extensions to the phone-home provisioning process for a standalone device so it can also work on a Virtual Chassis. The PHC on a Virtual Chassis requires extra steps to coordinate and manage bootstrapping the member devices.

The PHS is usually part of a network management system (NMS) that supports phone-home provisioning. Your network administrator enters the intended provisioning data that directs how devices and Virtual Chassis at remote sites should be set up. Your organization might have more than one PHS for redundancy.

You can check Feature Explorer and search for phone-home to see the Virtual Chassis platforms that support phone-home provisioning.

Benefits of Phone-Home Provisioning on a Virtual Chassis

  • Simplifies provisioning by launching the process automatically from the remote site, while securely obtaining bootstrap information from a central management system (the PHS) on your network or in the cloud.

  • Doesn’t require in-depth experience with the Junos OS CLI to coordinate the provisioning of multiple devices that make up a Virtual Chassis.

Overview of the Phone-Home Provisioning Process on a Virtual Chassis

On a Virtual Chassis that supports phone-home provisioning, for the process to work, you must set up the Virtual Chassis according to the requirements outlined in How to Enable Phone-Home Provisioning on a Virtual Chassis.

When the Virtual Chassis initially forms, the PHC process starts up automatically on the Virtual Chassis primary member and takes it from there:

  1. The PHC connects to a PHS.

    The PHC sends a provisioning request to a default redirect server URL, https://redirect.juniper.net, which redirects the request to an available PHS controlled by your network administrator or NMS. This step is the same as phone-home provisioning on a single device.

  2. The PHS responds to the PHC provisioning request with the bootstrapping information, which includes the intended Virtual Chassis topology, software image, and configuration.

  3. The PHC provisions the Virtual Chassis as specified by the PHS.

    Provisioning includes steps such as:

    • Validate the Virtual Chassis topology.

    • Upgrade the software image sequentially on all of the member devices if needed.

    • Run any pre-configuration or post-configuration staging scripts.

    • Commit a new configuration on the Virtual Chassis.

The PHC sends status notifications to the PHS during the bootstrapping process, so the network administrator can verify the process completes successfully.

The PHC also logs status locally in the system log files on the Virtual Chassis. If needed, you can view log files in the Junos OS CLI, and use Junos OS CLI commands to see Virtual Chassis and VCP connection status.

See Also

How To Enable Phone-Home Provisioning on a Virtual Chassis

On a Virtual Chassis that supports phone-home provisioning, if you set up the Virtual Chassis according to the steps listed here, a phone-home client (PHC) process starts up automatically on the Virtual Chassis primary member.

To enable phone-home provisioning on a Virtual Chassis:

  1. Ensure that all Virtual Chassis members have the factory-default configuration and are powered off.

    You can run the request system zeroize Junos OS CLI command to return a device to its factory-default state.

    Note:

    The Virtual Chassis can’t be a mixed-mode Virtual Chassis because mixed mode is never set in the factory-default configuration.

  2. Interconnect the Virtual Chassis members in a ring topology using only dedicated or default-configured Virtual Chassis ports (VCPs) on each member device.

    Keep in mind that the PHC process works only if the Virtual Chassis is initially formed with VCPs that do not need to be explicitly configured (dedicated VCPs or ports that are VCPs in the factory-default configuration). See VCP Options by Switch Type for details on which ports are dedicated and default-configured VCPs on different devices that support Virtual Chassis. See the hardware guide for the device to locate those ports on the device.

  3. Connect the Virtual Chassis management interface (me0) or any network-facing port on any Virtual Chassis member to the network.

    After the PHC starts up on the Virtual Chassis, it uses this connection to access a PHS over the network and retrieve the bootstrapping information for this Virtual Chassis.

    For details about how the management interfaces work on a Virtual Chassis, see Understanding Global Management of a Virtual Chassis.

  4. Power on the members of the Virtual Chassis.

Figure 1 shows an example of a Virtual Chassis topology that can support phone-home provisioning—a four-member EX4300 Virtual Chassis cabled in a ring topology using default-configured VCPs (in this case, two of the 40-Gigabit Ethernet QSFP+ ports on each device).

Figure 1: Sample Virtual Chassis That Can Support Phone-Home ProvisioningSample Virtual Chassis That Can Support Phone-Home Provisioning

Usually you don’t need to do anything else for the phone-home provisioning process to proceed and complete successfully. If you don’t see successful completion status or the Virtual Chassis isn’t up and operating as expected at the end of the process, read on to learn details about how the PHC works to help troubleshoot the issues.

See Also

Phone-Home Process on a Virtual Chassis

Phone-home provisioning on a Virtual Chassis is an extension of the standalone device phone-home support described in Obtaining Configurations and Software Image Without User Intervention Using Phone-Home Client. The PHC performs additional steps to manage bootstrapping the member devices that make up the Virtual Chassis.

The PHC process on a Virtual Chassis also requires the same software tools and utilities that standalone devices require for PHC to work. For example, the phone-home process needs DHCP client support to facilitate the network connection to the PHS in the same way as for a single device, and verifies a downloaded software image using the same checksum utilities. See Prerequisites for a list of these general PHC requirements.

Phone-home provisioning starts up automatically on a Virtual Chassis on the client side after you’ve performed the tasks in How To Enable Phone-Home Provisioning on a Virtual Chassis and if the Virtual Chassis meets the conditions described in Requirements for Phone-Home Provisioning to Work for a Virtual Chassis.

The provisioning process steps are grouped into the stages described in this section.

Startup and Request Provisioning Information from PHS

In the startup and request stage:

  1. The Virtual Chassis boots up in factory-default or zeroized state as a nonprovisioned Virtual Chassis, and elects the initial primary and backup members. (See Understanding How the Primary in a Virtual Chassis Is Elected.)
  2. The PHC starts up on the Virtual Chassis primary member, connects to the default redirect server (https://redirect.juniper.net) and sends a bootstrap request for the device. The redirect server redirects the PHC to an available PHS.
  3. The PHC receives the response from PHS, starts to discover what Virtual Chassis members are connected, and prepares to provision the Virtual Chassis. The PHS response includes:

    • Virtual Chassis topology information—At a minimum, this part of the response indicates the device is expected to be part of a Virtual Chassis; otherwise, the PHC provisions only the primary member as a standalone device.

      The response might additionally have full topology information, which includes the serial IDs of all the members the network administrator expects to be in the Virtual Chassis.

    • Software image upgrade information—Includes a path to the intended software image and image verification details.

    • Pre-configuration and post-configuration script information—Includes any staging scripts the network administrator needs the PHC to run before or after applying the new configuration.

    • Configuration information—Includes the intended Virtual Chassis configuration and the method to apply that configuration.

    The PHC must receive minimum required topology information to recognize it should provision a Virtual Chassis. Otherwise, the PHC defaults to provisioning only the primary member as a standalone device.

    The PHC extensions for Virtual Chassis support two provisioning modes—the default mode and a more strict mode the PHS can specify in the response:

    • By default, the PHC provisions any members it detects in the VC at the time it receives the PHS response. If the PHC encounters an error when bootstrapping a particular member, it moves on to bootstrap the next member or continues to the next provisioning step.

    • If the PHS specifies the strict mode option in the response, the response must also include the full Virtual Chassis topology information. Provisioning succeeds only if the PHC finds and successfully bootstraps all of the same members listed in the PHS response. If the PHC doesn’t detect all of the intended members or provisioning fails for any of them, the PHC restarts the process from the beginning to resend the provisioning request to another available PHS.

    Note:

    The PHS can include the Virtual Chassis member serial IDs in the response in either mode. However, in the default mode, bootstrapping the Virtual Chassis can succeed even if the PHC doesn’t detect all the members in the PHS response or if the PHS response doesn’t include member details at all.

    In this step, if the response includes full Virtual Chassis topology information and indicates to use strict provisioning mode, the PHC validates what it finds in the Virtual Chassis locally against the Virtual Chassis member information from the PHS response.

    Table 1 summarizes the actions the PHC takes starting in this step based on the type of topology information it receives in the PHS response, the provisioning mode, and the Virtual Chassis members that the PHS discovers locally.

    Table 1: PHC Actions Based on Topology Information in PHS Response

    Virtual Chassis Topology Information from PHS

    Default Mode Actions

    Strict Mode Actions If PHS Requests This Option

    No topology information provided

    Try to provision as standalone device.

    N/A

    (This mode can be specified only with full topology information)

    Minimum required topology information for a Virtual Chassis

    Discover members and proceed to provision Virtual Chassis with found members.

    N/A

    (This mode can be specified only with full topology information)

    Full topology information for a Virtual Chassis, including serial IDs for all intended Virtual Chassis members

    Discover members. If member list doesn’t match PHS response, proceed anyway to provision Virtual Chassis with found members.

    Bootstrap intended Virtual Chassis members from PHS response. Detect members; if all expected members are present and up, provisioning succeeds.

    Otherwise retry to bootstrap and detect members that failed the process.

    After member detection timeout with failure to detect all expected members, report error and restart process contacting another PHS to re-request provisioning.
  4. If the PHC proceeds to provision the devices in the Virtual Chassis, at this point the PHC commits some temporary changes to the Virtual Chassis configuration to enable smooth bootstrapping of all VC members.

    For example, the PHC makes sure the Virtual Chassis primary and backup member roles don’t change while the PHC is upgrading the software image on all the members.

Bootstrap Virtual Chassis Members

In this stage, the PHC bootstraps the Virtual Chassis, which includes installing the software image on and rebooting all of the members.

  1. The PHC on the primary member compares the bootstrap information in the PHS response with what’s on the Virtual Chassis to see if it needs to upgrade the software image. If the versions match, the PHC skips the remaing steps in this stage.
  2. If the PHC needs to upgrade the software image, the PHC uses the bootstrap information in the PHS response (image filename and checksum information) to download and validate the image.

    If the download operation fails, the PHC retries until it succeeds. (This behavior is the same for standalone device or Virtual Chassis phone-home provisioning.)

  3. The PHC proceeds to install and reboot the Virtual Chassis members based on the member roles as follows in this order:

    1. Linecard members—Installs the image on the linecard role members sequentially (in member ID order), and then reboots them all at the same time.

    2. Backup member—Installs the image on the backup member and reboots it.

    3. Primary member—Installs the image on the primary member, synchronizes the current PHC Virtual Chassis bootstrap state to the backup member, and triggers the primary member to reboot.

    As the upgraded members boot up, the PHC checks that they are up and running again. This action is called member detection in log messages and status notifications. If the PHC fails to detect a member within a default member detection timeout, the PHC notifies the PHS of the error. See Startup and Request Provisioning Information from PHS for the actions the PHC takes by default or if the PHS specified strict provisioning.

  4. While the old primary member is rebooting, the original primary isn’t available, so the Virtual Chassis switches primary role to the backup member. The Virtual Chassis also elects a new backup member at this time.
  5. The PHC starts up on the new primary member (the original backup member) and resumes the Virtual Chassis bootstrap procedure from the PHC state inherited from the old primary.

    When the old primary finishes booting and rejoins the Virtual Chassis, it is initially in linecard role but then assumes the backup role to the new primary member.

  6. When the PHC detects this last member is up and running, the provisioning process continues to the next stage to apply pre-configuration or post-configuration scripts and the new configuration to the Virtual Chassis.
    Note:

    Avoid having pre-configuration scripts, post-configuration scripts, or the new configuration make any changes that might cause the Virtual Chassis to assign new member roles or elect new primary and backup members during the provisioning process. Otherwise, provisioning might fail with unpredictable results.

Apply Scripts and New Configuration on the Virtual Chassis

The PHS response might include pre-configuration and post-configuration scripts the network administrator needs the PHC to run on the virtual Chassis before or after applying the new configuration. Phone-home provisioning supports Python or shell scripts and only XML format for the configuration.

The PHS response also provides the Junos OS configuration for PHC to commit on the member devices in the Virtual Chassis.

A Virtual Chassis operates as if it’s a single device, so the PHC performs these steps on the Virtual Chassis as a whole:

  1. Runs any specified pre-configuration scripts from PHS.
  2. Applies and commits the new configuration from PHS.
  3. Runs any specified post-configuration scripts from PHS.

Provisioning Process Completion

To complete the phone-home provisioning process, the PHC logs that the process completed successfully and sends a bootstrap completion notification to the PHS.

The PHC doesn’t run again unless you return the device or Virtual Chassis back to the factory-default state and have all other required conditions to trigger phone-home provisioning.

See Requirements for Phone-Home Provisioning to Work for a Virtual Chassis for details.

Phone-Home Provisioning Status Notifications

The PHC logs status information locally in the system log (/var/log/messages) on the Virtual Chassis and sends status notifications to the PHS to report the progress of the provisioning process. These messages signal when the PHC completes the different provisioning stages and help you troubleshoot issues if the process doesn’t complete successfully. See Phone-Home Process on a Virtual Chassis for the steps the PHC performs in each stage of Virtual Chassis provisioning.

Some PHC status messages are general and apply either for single device or Virtual Chassis provisioning.

Notification messages that are specific to a particular Virtual Chassis member include:

  • The member ID

  • The member’s serial ID

  • The member’s current role in the Virtual Chassis—Master, Backup, or Linecard

Virtual Chassis member-specific notifications have the following format:

For example:

Phone-home process notifications consist of a notification type and message. Table 2 lists notifications that are specific to the phone-home provisioning stages on a Virtual Chassis. Notification types with the vc-member keyword include Virtual Chassis member-specific information.

Table 2: PHC Notifications for Virtual Chassis Provisioning Steps

Notification Type

Notification Message

vc-member-image-installed

  • Successfully installed downloaded image. Initiating image installation on next member.

  • Successfully installed downloaded image. Initiating member reboot.

vc-member-image-installation-failed

  • Image failed to install on the member. Giving up and trying a different phone-home-server.

vc-member-reboot-initiated

  • Reboot initiated for Line Card members. Waiting for the members to come back up.

vc-member-upgrade-success

  • No upgrade required.

  • Successfully upgraded.

  • Member detected and successfully upgraded.

vc-member-upgrade-failed

  • Upgrade failed !!!

  • Member detected but upgrade failed !!!

vc-member-detection-failed

  • Did not come up post image upgrade

    Note:

    This message means the PHC installed the new image and initiated a reboot of the Virtual Chassis member, but the PHC didn’t detect that the member came up again within a prescribed member detection timeout.

vc-bootstrap-failed

  • VC member bootstrap failure detected with Strict provisioning set.

    Note:

    This message mean the PHC upgraded the expected linecard role members successfully, but after rebooting them, PHC didn’t detect that all members came up again within a prescribed member detection timeout.

  • VC with detection failed members and Strict provisioning set.

    Note:

    This message means the PHC failed to detect one or more members after upgrading and rebooting all of them, and upon checking again, finds that one or more of them still failed to come up.

    With strict provisioning mode, PHC must successfully bootstrap all intended members for the provisioning process to signal successful completion.

Verify Virtual Chassis Status After Phone-Home Provisioning

Purpose

Check the running status of the Virtual Chassis after PHC provisioning.

Action

Enter the show virtual-chassis command using the Junos OS CLI.

For example:

Troubleshoot Phone-Home Provisioning Issues

To troubleshoot PHC problems during the provisioning process:

  • Use utilities on the PHS side specific to your network management system to check device, Virtual Chassis, and connection status, or display phone-home process notifications (see Phone-Home Provisioning Status Notifications).

  • Make sure the Virtual Chassis management or network interface is connected to the network and can connect to a PHS.

  • If the PHS specified the strict mode option, verify the Virtual Chassis member serial IDs on the phone-home server side match the member devices you’re interconnecting on the client side at the remote site.

  • Look for error and status messages in the syslog file on the Virtual Chassis.

    For example, syslog status messages can show that the ZTP client is trying to provision the device instead of or in addition to the PHC. Upon startup with the factory-default configuration on either a standalone device or a Virtual Chassis primary member, both the PHC and the DHCP-based ZTP process (see Zero Touch Provisioning) start running automatically. ZTP proceeds if DHCP ZTP options are configured, which can cause unexpected provisioning behavior because ZTP isn’t supported for a Virtual Chassis. To trigger only phone-home provisioning, your DHCP system administrator can make sure the ZTP-specific options are not set on the DHCP server for devices intended to be in a Virtual Chassis under PHS management.

  • Check the configuration on the Virtual Chassis after provisioning using the show configuration CLI command.

Related Documentation