Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding Autoinstallation of Configuration Files

 

To set up many devices in your network, autoinstallation helps to automate the configuration process.

Autoinstallation Overview

If you are setting up many devices, autoinstallation can help automate the configuration process by loading configuration files onto new or existing devices automatically over the network. You can use either the J-Web configuration editor or the CLI configuration editor to configure a device for autoinstallation.

Autoinstallation provides automatic configuration for a new device that you connect to the network and turn on, or for a device configured for autoinstallation. The autoinstallation process begins any time a device is powered on and cannot locate a valid configuration file in the CompactFlash (CF) card. Typically, a configuration file is unavailable when a device is powered on for the first time, or if the configuration file is deleted from the CF card. The autoinstallation feature enables you to deploy multiple devices from a central location in the network.

For the autoinstallation process to work, you must store one or more host-specific or default configuration files on a configuration server in the network and have a service available—typically Dynamic Host Configuration Protocol (DHCP)—to assign an IP address to the device.

Autoinstallation takes place automatically when you connect an Ethernet or serial port on a new Juniper Networks device to the network and power on the device. To simplify the process, you can explicitly enable autoinstallation on a device and specify a configuration server, an autoinstallation interface, and a protocol for IP address acquisition.

This section contains the following topics:

Automatic Installation of Configuration Files

On SRX Series devices, you can specify a remote server where configuration files are located. If a configuration file cannot be found on the device’s CompactFlash card, the device automatically retrieves the configuration file from this remote server. For security purposes, you can encrypt these remote files using the DES cipher, and once they have been retrieved, the device decrypts them for use on the server.

To encrypt the files, we recommend the OpenSSL tool. You can get the OpenSSL tool at http://www.openssl.org/. To encrypt the file, use the following syntax:

  • passphrase—Passphrase used to encrypt the configuration file. The passphrase should be the name of the file without the path information or file extension.

  • original-file—Unencrypted configuration file.

  • encrypted-file—Name of the encrypted configuration file.

For example, if you are encrypting the active configuration file juniper.conf.gz, the passphrase is juniper.conf. The openSSL syntax used to encrypt the file is:

Supported Autoinstallation Interfaces and Protocols

Before autoinstallation on a device can take place, the device must acquire an IP address. The protocol or protocols you choose for IP address acquisition determine the device interface to connect to the network for autoinstallation. The device detects the connected interface and requests an IP address with a protocol appropriate for the interface. Autoinstallation is supported over an Ethernet LAN interface or a serial LAN or WAN interface. Table 1 lists the protocols that the device can use on these interfaces for IP address acquisition.

Table 1: Interfaces and Protocols for IP Address Acquisition During Autoinstallation

Interface and Encapsulation Type

Protocol for Autoinstallation

Ethernet LAN interface with High-Level Data Link Control (HDLC)

DHCP, BOOTP, or Reverse Address Resolution Protocol (RARP)

Serial WAN interface with HDLC

Serial Line Address Resolution Protocol (SLARP)

Serial WAN interface with Frame Relay

BOOTP

If the server with the autoinstallation configuration file is not on the same LAN segment as the new device, or if a specific device is required by the network, you must configure an intermediate device directly attached to the new device through which the new device can send Trivial File Transfer Protocol (TFTP), BOOTP, and Domain Name System (DNS) requests. In this case, you specify the IP address of the intermediate device as the location to receive TFTP requests for autoinstallation.

Typical Autoinstallation Process on a New Device

When a device is powered on for the first time, it performs the following autoinstallation tasks:

  1. The new device sends out DHCP, BOOTP, RARP, or SLARP requests on each connected interface simultaneously to obtain an IP address.

    If a DHCP server responds, it provides the device with some or all of the following information:

    • An IP address and subnet mask for the autoinstallation interface.

    • The location of the TFTP (typically), Hypertext Transfer Protocol (HTTP), or FTP server on which the configuration file is stored.

    • The name of the configuration file to be requested from the TFTP server.

    • The IP address or hostname of the TFTP server.

      If the DHCP server provides only the hostname, a DNS server must be available on the network to resolve the name to an IP address.

    • The IP address of an intermediate device if the configuration server is on a different LAN segment from the new device.

  2. After the new device acquires an IP address, the autoinstallation process on the device attempts to download a configuration file in the following ways:
    1. If the DHCP server specifies the host-specific configuration file (boot file) hostname.conf, the device uses that filename in the TFTP server request. (In the filename, hostname is the hostname of the new device.) The autoinstallation process on the new device makes three unicast TFTP requests for hostname.conf. If these attempts fail, the device broadcasts three requests to any available TFTP server for the file.
    2. If the new device cannot locate hostname.conf, the autoinstallation process unicasts or broadcasts TFTP requests for a default device configuration file called network.conf, which contains hostname-to-IP address mapping information, to attempt to find its hostname.
    3. If network.conf contains no hostname entry for the new device, the autoinstallation process sends out a DNS request and attempts to resolve the new device's IP address to a hostname.
    4. If the new device can determine its hostname, it sends a TFTP request for the hostname.conf file.
    5. If the new device is unable to map its IP address to a hostname, it sends TFTP requests for the default configuration file router.conf.
  3. After the new device locates a configuration file on a TFTP server, autoinstallation downloads the file, installs the file on the device, and commits the configuration.
Note
  • If you configure the DHCP server to provide only the TFTP server hostname, add an IP address-to-hostname mapping entry for the TFTP server to the DNS database file on the DNS server in the network.

  • If the new device is not on the same network segment as the DHCP server (or other device providing IP address resolution), configure an existing device as an intermediate to receive TFTP and DNS requests and forward them to the TFTP server and the DNS server. You must configure the LAN or serial interface on the intermediate device with the IP addresses of the hosts providing TFTP and DNS service. Connect this interface to the new device.

Note

Starting in Junos OS Release 15.1X49-D60 and in Junos OS Release 17.3R1, on SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX1500 devices, some of the factory-default configurations are changed.

  • The name-server statement, used to configure one or more Domain Name System (DNS) name servers, is changed to 8.8.8.8 and 8.8.8.4. Previously, it was 208.67.222.222 and 208.67.220.220.

  • A new system service, NETCONF service over SSH, is introduced at the [edit system services] hierarchy:

  • The following configuration setting for HTTPS (secure management) access using the J-Web interface is changed. Now, there is no need to specify the interface details for J-Web management. With this configuration, you can manage the device from any interface through HTTPS.

  • A license autoupdate URL (https://ae1.juniper.net/junos/key_retrieval) is now supported under the [edit system] hierarchy:

  • A new system log configuration is introduced to configure system log messages to record all commands entered by users and all authentication or authorization attempts under the [edit system] hierarchy:

Note

Starting in Junos OS Release 17.4R1, on SRX300, SRX320, SRX340, SRX345, and SRX550M devices, telnet and xnm-clear-text are not part system services in factory-default configurations.

Note

In Junos OS Release 15.1X49-D40 and earlier, configuring autoinstallation using USB and Layer Ethernet switching was supported on the same interface. However, the command caused improper installation of the interface-related configurations.

Starting with Junos OS Release 15.1X49-D50, Layer 2 Ethernet switching is not supported on the same interface for SRX300, SRX320, SRX340, SRX345, and SRX550M devices.

The system autoinstallation interfaces <interface names> command and the set interface <interface names> unit 0 family ethernet-switching command cannot be configured on the same interface.

Note

USB auto-installation is not supported on SRX1500 devices and vSRX instances.

Autoinstallation is the automatic configuration of a device over the network from a preexisting configuration file that you create and store on a configuration server—typically a Trivial File Transfer Protocol (TFTP) server. You can use autoinstallation to configure new devices automatically and to deploy multiple devices from a central location in the network.

You enable autoinstallation so that the switches in your network implement autoinstallation when they are powered on. To configure autoinstallation, you specify a configuration server, an autoinstallation interface, and a protocol for IP address acquisition.

Note

The QFX5200 switches only work with HTTP for autoinstallation. TFTP and FTP protocols are not supported.

Typical Uses for Autoinstallation

Typical uses for autoinstallation of the software include:

  • To deploy and update multiple devices from a central location in the network.

  • To update a device—Autoinstallation occurs when a device that has been manually configured for autoinstallation is powered on.

Autoinstallation Configuration Files and IP Addresses

For the autoinstallation process to work, you must store one or more host-specific or default configuration files on a configuration server in the network and have a service available—typically Dynamic Host Configuration Protocol (DHCP)—to assign an IP address to the switch.

You can set up the following configuration files for autoinstallation on the switch:

  • network.conf—Default configuration file for autoinstallation, in which you specify IP addresses and associated hostnames for devices on the network.

  • switch.conf—Default configuration file for autoinstallation with a minimum configuration sufficient for you to telnet to the device and configure it manually.

  • hostname.conf—Host-specific configuration file for autoinstallation on a device that contains all the configuration information necessary for the switch. In the filename, hostname is replaced with the hostname assigned to the switch.

If the server with the autoinstallation configuration file is not on the same LAN segment as the new device, or if a specific device is required by the network, you must configure an intermediate device directly attached to the new switch, through which the new switch can send TFTP, Boot Protocol (BOOTP), and Domain Name System (DNS) requests. In this case, you specify the IP address of the intermediate device as the location to receive TFTP requests for autoinstallation.

Typical Autoinstallation Process on a New Switch

When the switch configured for autoinstallation is powered on, it performs the following autoinstallation tasks:

  1. The switch sends out DHCP or BOOTP requests on each connected interface simultaneously to obtain an IP address.

    If a DHCP server responds to these requests, it provides the switch with some or all of the following information:

    • An IP address and subnet mask for the autoinstallation interface.

    • The location of the (typically) TFTP server, Hypertext Transfer Protocol (HTTP) server, or FTP server on which the configuration file is stored.

    • The name of the configuration file to be requested from the TFTP server.

    • The IP address or hostname of the TFTP server.

      If the DHCP server provides the server’s hostname, a DNS server must be available on the network to resolve the name to an IP address.

    • The IP address of an intermediate device if the configuration server is on a different LAN segment from the switch.

  2. After the switch acquires an IP address, the autoinstallation process on the switch attempts to download a configuration file in the following ways:
    1. If the DHCP server specifies the host-specific configuration file hostname.conf, the switch uses that filename in the TFTP server request. The autoinstallation process on the new switch makes three unicast TFTP requests for hostname.conf. If these attempts fail, the switch broadcasts three requests to any available TFTP server for the file.
    2. If the switch does not locate a hostname.conf file, the autoinstallation process sends three unicast TFTP requests for a network.conf file that contains the switch’s hostname-to-IP-address mapping information. If these attempts fail, the switch broadcasts three requests to any available TFTP server for the file.
    3. If the switch fails to find a network.conf file that contains a hostname entry for the switch, the autoinstallation process sends out a DNS request and attempts to resolve the switch's IP address to a hostname.
    4. If the switch determines its hostname, it sends a TFTP request for the hostname.conf file.
    5. If the switch is unable to map its IP address to a hostname, it sends TFTP requests for the default configuration file switch.conf. The TFTP request procedure is the same as for the network.conf file.
  3. After the switch locates a configuration file on a TFTP server, the autoinstallation process downloads the file, installs the file on the switch, and commits the configuration.
Note

Please refer to the product Data Sheets for details, or contact your Juniper Account Team or Juniper Partner. Please refer to the Juniper Licensing Guide for general information about License Management.

Autoinstallation Process on Satellite Devices in a Junos Node Unifier Group

Autoinstallation provides automatic configuration for a new router that you connect to the network and power on, or for a router configured for autoinstallation. The autoinstallation process begins any time a router is powered on and cannot locate a valid configuration file in the CompactFlash card. Typically, a configuration file is unavailable when a router is powered on for the first time, or if the configuration file is deleted from the CompactFlash card. The autoinstallation feature enables you to deploy multiple routers from a central location in the network.

For the autoinstallation process to work, you must store one or more host-specific or default configuration files on a configuration server in the network and have a service available—typically Dynamic Host Configuration Protocol (DHCP)—to assign an IP address to the router.

Autoinstallation takes place automatically when you connect an Ethernet interface on a new Juniper Networks router to the network and power on the router. To simplify the process, you can explicitly enable autoinstallation on a router and specify a configuration server, an autoinstallation interface, and a protocol for IP address acquisition.

This topic describes:

Supported Autoinstallation Interfaces and Protocols

Before autoinstallation on a router can take place, the router must acquire an IP address or a USB key. The protocol or protocols you choose for IP address acquisition determine the router interface to connect to the network for autoinstallation. The router detects the connected interface and requests an IP address with a protocol appropriate for the interface. Autoinstallation is supported over an Ethernet LAN interface. For IP address acquisition, the JNU satellite router uses DHCP, BOOTP, or Reverse Address Resolution Protocol (RARP) on an Ethernet LAN interface.

If the server with the autoinstallation configuration file is not on the same LAN segment as the new router, or if a specific router is required by the network, you must configure an intermediate router directly attached to the new router, through which the new router can send HTTP, FTP, Trivial File Transfer Protocol (TFTP), BOOTP, and Domain Name System (DNS) requests. In this case, you specify the IP address of the intermediate router as the location to receive HTTP, FTP, or TFTP requests for autoinstallation.

Typical Autoinstallation Process on a New Router

When a router is powered on for the first time, it performs the following autoinstallation tasks:

  1. The new router sends out DHCP, BOOTP, or RARP requests on each connected interface simultaneously to obtain an IP address.

    If a DHCP server responds, it provides the router with some or all of the following information:

    • An IP address and subnet mask for the autoinstallation interface.

    • The location of the TFTP (typically), HTTP, or FTP server on which the configuration file is stored.

    • The name of the configuration file to be requested from the HTTP, FTP, or TFTP server.

    • The IP address or hostname of the HTTP, FTP, or TFTP server.

      If the DHCP server provides only the hostname, a DNS server must be available on the network to resolve the name to an IP address.

    • The IP address of an intermediate router if the configuration server is on a different LAN segment from the new router.

  2. After the new router acquires an IP address, the autoinstallation process on the router attempts to download a configuration file in the following ways:
    1. If the configuration file is specified as a URL, the router fetches the configuration file from the URL by using HTTP, FTP, or TFTP, depending on the protocol specified in the URL.
    2. If the DHCP server specifies the host-specific configuration file (boot file) hostname.conf, the router uses that filename in the TFTP server request. (In the filename, hostname is the hostname of the new router.) The autoinstallation process on the new router makes three unicast TFTP requests for hostname.conf. If these attempts fail, the router broadcasts three requests to any available TFTP server for the file.
    3. If the new router cannot locate hostname.conf, the autoinstallation process unicasts or broadcasts TFTP requests for a default router configuration file called network.conf, which contains hostname-to-IP address mapping information, to attempt to find its hostname.
    4. If network.conf contains no hostname entry for the new router, the autoinstallation process sends out a DNS request and attempts to resolve the new router’s IP address to a hostname.
    5. If the new router can determine its hostname, it sends a TFTP request for the hostname.conf file.
    6. If the new router is unable to map its IP address to a hostname, it sends TFTP requests for the default configuration file router.conf.
  3. After the new router locates a configuration file on a TFTP server, the autoinstallation process downloads the file, installs the file on the router, and commits the configuration.

In a Junos Node Unifier (JNU) group that contains an MX Series router as a controller that manages satellite devices, such as EX Series Ethernet Switches, QFX Series devices, and ACX Series Universal Metro Routers, the autoinstallation functionality is supported for the satellite devices. JNU has an autoinstallation mechanism that enables a satellite device to configure itself out-of-the-box with no manual intervention, using the configuration available either on the network or locally through a removable media, or using a combination of both. This autoinstallation method is also called the zero-touch facility.

The zero-touch configuration delivers the following benefits:

  • The router can be sent from the warehouse to the deployment site without any preconfiguration steps.

  • The procedure required to deploy the device at the cell site is simplified, resulting in reduced operational and administrative costs.

  • You can roll out large numbers of these devices in a very short time.

The factory default setting is autoinstallation-enabled. After you make the first configuration to the router, you can do either of the following:

  • A JNU factory default file, jnu-factory.conf, is present in the /etc/config/ directory and contains the configuration to perform autoinstallation on satellite devices. The zero-touch configuration can be disabled by including the delete-after-commit statement at the [edit system autoinstallation] hierarchy level and committing the configuration. This way, the saved configuration is used the next time the system reboots.

  • Alternatively, if the router must get the configuration from the server each time a system reboot occurs, the zero-touch configuration must not be changed (that is, you must not include the delete-after-commit statement at the [edit system autoinstallation] hierarchy level and commit the settings).

Release History Table
Release
Description
Starting in Junos OS Release 15.1X49-D60 and in Junos OS Release 17.3R1, on SRX300, SRX320, SRX340, SRX345, SRX550M, and SRX1500 devices, some of the factory-default configurations are changed.