Smart Install Configuration Guide

Smart Install Director

The director in a Smart Install network must be a Layer 3 switch running Cisco IOS Release 12.2(52)SE or later, XE 3.4SG, 15.1(2)SG, 15.0(2)SE or later, 15.1(1)SY or later, 3.2(0)SE or later, or a router running Cisco IOS Release 15.1(3)T or later. See Appendix A, “Supported Devices for Smart Install” for a list of routers and switches that can perform the role of Smart Install director.

Note IE2000 IE3000, and IE3010 support Director with Cisco IOS Release 15.2(2)E.

To configure a device as director, enter the IP address of one of its Layer 3 interfaces in the vstack director ip_ address global configuration command and enable it as director by entering the vstack basic command.

Note If you have entered the no vstack global configuration command to disable Smart Install on a device, the vstack director ip_ address and vstack basic global configuration commands are not allowed on the device. To reenable Smart Install on a device, enter the vstack global configuration command.

When a device is configured as director, The VLAN on which the DHCP snooping is automatically enabled becomes VLAN 1 by default. The director begins building the director database in VLAN 1. To specify another VLAN for Smart Install management, you can use the vstack startup-vlan global configuration command. Depending on the VLAN that is specified in the command, DHCP snooping is enabled on that VLAN so that the director can identify new switches that are connected to the network, known as non-VLAN 1 switches.

The database lists the client devices in the Smart Install network and includes this information:

• Type of switch (PID) for all switches, including switches in a stack
• MAC addresses for all switches, including switches in a stack
• IP address of the switch or stack
• Hostname
• Network topology including neighbors interfacing with the switch
• Serial number (only Smart Install capable switches)

Note When the director is a switch, DHCP snooping is enabled on VLAN 1 by default. It is also enabled on other Smart Install management VLANs that are configured by entering the vstack vlan vlan-range global configuration command. You can use the vstack startup-vlan global configuration command to specify another VLAN that should be used for Smart Install management. Cisco IOS Releases 15.1(1)SY, 15.0(2)SE or later, 15.1(2)SG, 3.6.(0)E, 15.2.(2)E, and Cisco IOS XE 3.4SG support non-VLAN1 management and provide the ability to discover the client switches available on non-VLAN1.

In a Smart Install network that uses DHCP to assign IP addresses, you only need to configure the director. Client switches do not require any configuration. Although you can enter command-line interface commands on clients, configuration commands do not take effect unless the switch assumes the role of director.

Note You can configure the vstack commands in client mode. but this is effective only when the switch is converted to a director.

There can be only one director for a set of clients and you cannot configure a backup director. If the director fails:

• Director database must be rebuilt.
• Any update being performed for a non-Smart Install-capable switch might fail.
• The accumulated download status is lost.
• A configuration backup might not occur before the director restarts.

The director can change status and become a client switch if:

• The director interface that has the director IP address shuts down.
• The director interface that has the director IP address is deleted.
• The director IP address is changed.

If the director becomes a client, DHCP snooping is disabled, and the director database is no longer used.

If the director IP address is provided by DHCP and you configure a different director IP address on a client switch, the client is longer part of the director’s Smart Install network.

Smart Install relies on a TFTP server to store image and configuration files. The TFTP server can be an external device, or the director can act as a TFTP server. If the director is the TFTP server, the available flash file space on the director must be adequate to accommodate the client Cisco IOS image and configuration files. See the “Configuring the TFTP Server” section.

In a Smart Install network using DHCP, the DHCP server can be an external device or the director can act as the DHCP server. See the “Configuring the DHCP Server” section. The director snoops all DHCP packets that pass through it on VLANs that are configured as Smart Install management VLANs. All network DHCP packets from intermediate or client switches or from an external DHCP server must pass through the director. The director must be able to snoop all DHCP packets from clients.

Note Smart Install options in the DCHP offer are option 125, suboption 5 (the image list file), option 125 sub-option 16 (the director IP address), and option 67 (the configuration file).

The director builds a topology director database for the network by collecting information from the network Smart Install switches. The director uses the database:

• To assign a configuration file and image to a client.
• As a reference to obtain the PID, the image name, and the configuration file for an on-demand update of network switches.

The director periodically updates the director database based on CDP updates that it receives from neighbor switches and from Smart Install messages sent to the director by Smart Install capable clients. The updates contain information about the client neighbors.

Image List File

An image list identifies the images to be loaded on the client. The image list file is the file that contains the correct image name for the client. When the director is the TFTP server, this file is stored in flash memory. Otherwise, it is stored in a remote, third-party TFTP server.

• When the file is stored in the director, the prefix for the image list is flash: //, usbflash0: //, bootflash://, bootdisk://, or disk0:// based on the appropriate file systems available on the switch.
• When the file is stored in a remote TFTP server, the prefix is tftp: // ip_address / image. tar.

Note In Catalyst Switches 3850 and 3650, the image is a bundled with .bin extension.

Images must be stored either on the director or on the third-party TFTP server.

For a standalone switch, the image list file contains a single image. For a stack, the image list contains images for all members of the stack, which could be the same image or different images. For a switch stack, the director creates the image list file after the user specifies the tar file for each switch in the stack.

Starting with Cisco IOS Release 12.2(55)SE or later,15.1(1)SY, 15.0(2)SE and later, 3.2(0)SE and later, XE 3.4SG, 15.1(2)SG, 3.6.(0)E, and 15.2.(2)E, when the user specifies the tar file for each switch, the director automatically creates the imagelist file.

When an external TFTP server is used, the director writes the image list file to the TFTP server. It is recommended that the TFTP server permit the director to write the image list files to the TFTP Server. If the director does not have permission to write to the file system of the TFTP server, the director logs the failure in the system log. You can create the image list files and put them on the TFTP server manually if the director fails to do so automatically; you cannot fix the issue that prevents the director from writing to the TFTP server.

Note The upgrade process is initialized even when the imagelist file is copied manually, but the director tries to copy the image list file to the TFTP server and the failure system log is displayed periodically.

Configuration Files

The director manages these configuration files:

• Startup configuration—The configuration that a client uses when it boots.
• Seed configuration—A configuration on the director that is the basis for the client startup configuration.
• Backup configuration—An exact copy of a client startup configuration stored in the director.

Smart Install Clients

Client switches have a direct or indirect connection to the director so that they can receive image and configuration downloads from it. A switch becomes a Smart Install client when either director or when the director IP address is configured on the switch manually. Client switches use the director database for image and configuration downloads and receive the image and configuration files from the Smart Install TFTP server.

A client switch can be an intermediate switch connected to another client switch. A client can be a standalone switch or a switch stack.

• Director can download images and configuration of clients that are not Smart Install. However, such clients are entered into the director database only if they are connected to a Smart Install capable switch. The director can telnet to the client switch and use the archive download-sw privileged EXEC command to download software to the switch. The director must know the client switch password to perform the download.
• Smart Install capable switches can communicate directly with the director to update switch information, can have images and configuration downloaded, and can be managed by the director. A Smart Install capable client with the director IP address and connectivity to the director sends switch and neighbor information to the director by using the Smart Install protocol.

Note Switches running Cisco IOS XE Releases 3.2(0)SE and later, 3.6.(0)E, and 15.2.(2)E support software install.

All switches in the network with “network” connectivity to the director can be clients, whether or not they are Smart Install capable. A client switch needs an IP address for management communication and the director must be able to communicate with that IP address. Client switch IP addresses are assigned by DHCP or statically configured.

Smart Install capable clients send switch and neighbor information to the connected director for the director database. Client switches that are not Smart Install capable or that are not connected to a Smart Install capable switch are not entered into the director database. In a multihop topology, for the director to get the complete topology overview, any client switch upstream of a group of clients must be Smart Install capable. Clients not in the director database can get an on-demand update, but they cannot get a zero-touch or group update.

Figure 1-2 shows some possible ways that clients can be interconnected in a network. Table 1-1 and Table 1-2 shows the director database knowledge of each client and the type of update that is supported.

Note The topology shown in Figure 1-2 does not represent a typical Smart Install topology but is used to demonstrate possible types of client interconnections.

Figure 1-2 Possible Interconnections of Smart Install Clients

Note The Cisco IOS releases12.2(52)SE or later, XE 3.4SG, 15.1(2)SG, 15.1(1)SY and later, 15.0(2)SE and later, and 3.2(0)SE and later, support the director role. The Cisco IOS releases 15.0(2)SE, 15.1(1)SY, 15.1(2)SG, XE 3.4SG, 15.0(2)EX, 15.0(2)EX1, 3.6.(0)E, and 15.2.(2)E are Smart Install capable switches, supporting non-VLAN 1 management and providing the ability to discover the client switches available on non-VLAN 1.

Table 1-1 shows the switches that are in the director database and how the director obtained the information. When a client is a single hop from the director, the client uses CDP to send the director information about itself. When a client is a Smart Install capable switch, it sends information to the director about itself and its neighbors.

Table 1-2 shows the director database knowledge of each client and the type of update that is supported in various software versions. For information about Smart Install supported switches, routers, and minimum software releases for directors and clients, see Supported Devices for Smart Install .

To see the types of Smart Install clients in a network, enter the show vstack status privileged EXEC command.

These fields were added in Cisco IOS Release 12.2(58)SE or 15.1(1)SY to provide more information about each client:

• Device type: S (Smart Install capable, running Cisco IOS Release 12.2(52)SE or later, 15.1(1)SY, 15.0(2)SE and later, 3.2(0)SE and later), 3.6.(0)E, or 15.2.(2)E, N (not a Smart Install device), or P (pending, unable to determine).
• Device health status: Active (the director is receiving periodic updates from the device) or Inactive (the device is disconnected or has not provided updates for three consecutive keepalive periods)
• Join window status: a (allowed), h (on hold), or d (denied). See the “Using a Join Window” section.
• Upgrade status: An image update is i (in progress), I (complete), or X (failed). A configuration upgrade is c (in progress), C (complete), or x (failed).

Smart Install Groups

When all switches in a Smart Install network have the same PID, they can run the same image and the same seed (basic) configuration file. In this case, you can assign a default image and configuration file for all clients. However, if there is more than one PID in the network or if you want a different configuration file to run on some switches, depending on their function in the network, you should configure Smart Install groups and assign an image and configuration file for each group.

• Custom groups take precedence over built-in groups and are based on:

– Stack group—For switches in a stack, you can configure groups based on their number in the stack. Stack groups are used only for switch stack upgrades, and clients do not need to be in the director database. Starting with Cisco IOS Release 12.2(58)SE, 15.1(1)SY, 15.0(2)SE and later, 3.2(0)SE and later, 3.6.(0)E, and 15.2.(2)E if a stack is homogeneous (all one switch type), you do not need to identify each switch type.

– MAC address—You can create a custom group of specific switches by using the MAC addresses of the switches to configure the group. You can include switches with the same or different product IDs, as long as they use the same image and configuration file. Enter the show vstack neighbors all privileged EXEC command to see the MAC addresses of switches in the Smart Install network.

– Connectivity—You can configure a custom group based on network topology; that is, all switches that have the same upstream neighbor. Connectivity groups take precedence over groups with matching product IDs or stack numbers. Connectivity groups include only standalone switches (not switch stacks), and clients must be in the director database.

– Product IDs (PIDs)—These product IDs are all supported models, including newer PIDs that were not shipping when the software was released and therefore are not in the CLI. PID groups include only standalone switches (not switch stacks), and clients do not need to be in the director database.

The priority of custom groups from high to low is stack group, MAC address, connectivity, and product ID.

• Built-in groups are based on PIDs that you can select from the CLI. These represent the fixed Ethernet switching products that were shipping when the software was released, for example, 3750, 3560, 2975, 2960, 3850, and 3650.

Switches that belong to a group use the image and configuration file assigned to that group. If a client switch does not belong to a group in the director database, it is assigned the default image and configuration file.

Note If there is more than one switch PID in the network, we recommend configuring built-in or custom groups. The default image and configuration is used in networks with only one product ID.

An example of the use of custom groups is a network where all client switches are the same PID, but one requires a different configuration. For example, a retail store might have checkout counters and a pharmacy, and the pharmacy switch requires a different configuration. The checkout counters would use the default configuration, but you would create a custom group for the pharmacy.

Security Best Practices

Security best practices around the Cisco Smart Install feature depend on how the feature is used in a specific customer environment. We differentiate the following use cases:

• Customers not using the Smart Install feature.
• Customers leveraging the Smart Install feature only for zero-touch deployment.
• Customers leveraging the Smart Install feature for more than zero-touch deployment (configuration and image-management).

The following sections describe each scenario in detail:

Customers Not Using the Smart Install Feature

Customers who do not use the Cisco Smart Install feature, and are running a release of Cisco IOS and IOS XE Software where the command is available, should disable the Smart Install feature with the no vstack command.

Note The vstack command was introduced in Cisco IOS Release 12.2(55)SE03.

The following is sample output from the show vstack command on a Cisco Catalyst Switch with the Smart Install client feature disabled:

Customers Leveraging the Smart Install Feature Only for Zero-Touch Deployment

Disable the Smart Install client functionality after the zero-touch installation is complete or use the no vstack command.

To propagate the no vstack command into the network, use one of the following methods:

• Execute the no vstack command on all client switches either manually or using a script.
• Add the no vstack command as part of the IOS configuration that is pushed into each Smart Install client as part of the zero-touch installation.
• In the releases that do not support the vstack command (Cisco IOS Release 12.2(55)SE02 and prior releases), apply an access control list (ACL) on client switches to block the traffic on TCP port 4786.

To enable the Smart Install client functionality later, execute the vstack command on all client switches either manually or by using a script.

Note If the configuration changes in between the disabling and re-enabling of the Smart Install feature, to preserve these changes, execute the write memory command on client switches after re-enabling the feature. Configuring the command ensures a successful backup of the startup configuration of client switches.

Customers Leveraging the Smart Install Feature for More Than Zero-Touch Deployment

While designing a Smart Install architecture, care should be taken such that the infrastructure IP address space is not accessible to untrusted parties. In releases that do not support the vstack command, ensure that only the Smart Install director has TCP connectivity to all Smart Install clients on port 4786.

Administrators can use the following security best practices for Cisco Smart Install deployments on affected devices:

• Interface access control lists (ACLs)
• Control Plane Policing (CoPP). This feature is not available in all Cisco IOS Software releases.

The following example shows an interface ACL with the Smart Install director IP address as 10.10.10.1 and the Smart Install client IP address as 10.10.10.200:

ip access-list extended SMI_HARDENING_LIST

permit tcp host 10.10.10.1 host 10.10.10.200 eq 4786

deny tcp any any eq 4786

permit ip any any

This ACL must be deployed on all IP interfaces on all clients. It can also be pushed via the director when switches are first deployed.

To further restrict access to all the clients within the infrastructure, administrators can use the following security best practices on other devices in the network:

• Infrastructure access control lists (iACLs)
• VLAN access control lists (VACLs)

Migration Plan

Customers who can not properly protect their Smart Install IP infrastructure address space, or need the added security of authorization and authentication between the director and clients can migrate to Cisco Plug-N-Play (PnP). For more information, see the PnP Feature Guide.

If your release does not support PnP, migrate to Smart Install Proxy (SMI Proxy). The SMI Proxy feature must be enabled on a network device that is configured as a PnP Agent. This device will bridge the communication between older devices running Smart Install and the PnP Server. The SMI Proxy device will contact the central PnP Server on behalf of the device running older versions, to retrieve the image and configuration information. For more information, see the SMI Proxy chapter.

SMI Proxy is available in Cisco IOS Release 15.2(2)E2 and later releases.

Note The security best practices must be followed for all devices on which the SMI Proxy feature is enabled, and also for all devices on which the Smart Install feature is enabled.

Using a Join Window

A join window is a time window during which the client can update image or configuration files. The director can provide information about the image and configuration to the client only during this window. A client attempting to join the Smart Install network outside the join window is not allowed to do so and cannot update the image and configuration files.

Use the vstack join-window mode auto global configuration command to automatically update clients with the latest image and configuration files when they are added during a join window. Use the no vstack join-window mode global configuration command to put the client in a hold state.

Use the following commands to open or close a join window:

• Enter the vstack join-window start [date] hh:mm [interval] [end date] [recurring] global configuration command to configure a time window to control downloads of configuration and image files to client switches.
• Enter the vstack join-window close global configuration command to manually close a join window, enter the no vstack join-window close global configuration command to manually open a join window.

Note You cannot combine the vstack join-window start and [no] vstack join-window commands to close and open the join window.

If a join window is configured, a zero touch update is possible only during the configured window. If a switch connects to the director at any time other than during the join window, the Smart Install configuration and image files are not automatically downloaded. Instead, the new switch receives the default files from th e DHCP server. This feature provides control of the files and prevents unauthorized switches from receiving the Smart Install configuration.

If a join window is not configured, a zero touch update can happen at any time because that is the default state.

When a join window is configured, and the DHCP acknowledgement occurs outside of the configured window, a client switch sends an error message that it cannot download an image or configuration file.

Configuring Join Window Mode

The join window mode includes a hold state that adds an extra level of security for the client. The hold state lets you control whether or not the client can receive a software upgrade, and how the upgrade is performed. The hold-state is either on or off when the join window is active.

You configure automatic join window mode with the vstack join-window mode auto global configuration command. In this mode, when a client joins the network, the director automatically upgrades it when the join window is open.

When you set the mode to manual by entering the no vstack join-window mode global configuration command, when a client joins the network during an open join window, the client is put on the hold list.

You can review clients on the hold list by entering the show vstack status user EXEC command. You can remove a client from the hold list by entering the vstack on-hold-clients remove global configuration command.

Note When a client has been removed from the hold state to allow that client to join the network, you must restart the client to again put it in the hold state (if the mode is manual) or to automatically upgrade if the mode is auto and the join window is open.

When a new client joins the network and the mode is set to auto, the join window state is active, whether or not the join window is open or closed. When the mode is set to manual and the join window is open, the client is put on the hold list. If the join window is closed, the client cannot join the network (denied).

Table 1-3 lists the join window states and the actions that are allowed or not allowed for each state.

Starting with Cisco IOS Release 12.2(58)SE,15.1(1)SY, 15.0(2)SE and later, 3.2(0)SE and later, 3.6.(0)E, and 15.2.(2)E, you can manually change the join window state for a client or multiple clients from the denied state to the active or held state by using the vstack join-window-status index client-id { allowed | held } privileged EXEC command.

Zero-Touch Installation

A zero-touch installation is an update initiated by the director on a client switch that has no configuration. You can perform a zero-touch installation on Smart Install capable switches and non-Smart Install switches. The zero-touch installation occurs automatically with little or no intervention. A switch with no configuration can be a new, out-of-box switch or one on which you have entered the write erase and reload privileged EXEC commands.

During a zero-touch installation, do not touch the console keyboard or attempt to enter a command or auto return on the switch. Else, the auto install and Smart Install processes stop. To recover and restart the process, you need to return to the system prompt, enter write erase and reload commands, and restart the process.

During a zero-touch installation, the VLAN specified in the seed configuration for a particular client should be the same as the startup VLAN on the director. If it is not, the configuration backup process fails.

If the TFTP server is the director, the file is saved in the director root directory. If the server is another device, it is saved in the tftproot directory. This is the default directory in the TFTP server where the files to be sent using TFTP are stored. The imageclist file, the new configuration file, and the image are also stored in this directory.

See the “Configuring the TFTP Server” section.