End of Support

Timing Protocols

The Precision Time Protocol (PTP) provides clock accuracy for networked devices, allowing clocks to be synchronized locally in increments of less than a microsecond. PTP uses a master-slave hierarchy similar to that used by NTP. The master clock provides the most precise time, and slave devices use its signal to synchronize their clocks.

The master clock sends a sync request, called an announce message by the IEEE 1588-2008 standard, at a regular interval. The slave clock responds with a time-stamped delay request message in order to measure and compensate for packet delays between the devices. The slave then receives a message from the master specifying the time of the delay message and allows the slave to calculate final values for clock synchronization. The time maintains synchronization by regularly exchanging PTP packets between master and slave.

Note: Arista switches do not support setting the system clock using PTP. Use the NTP service on the PTP grandmaster for system clock synchronization.

EOS disables PTP globally by default. Enabling PTP on an interface requires the following steps:

Optional PTP global configurations include the following:

Optional PTP interface-level configurations include the following:

Setting the PTP Mode

To enable PTP on switch interfaces, set the PTP mode using the ptp mode command. PTP mode options include the following:

boundary - The device acts as a boundary clock and runs and participates in the best master clock algorithm.
disabled - Disables PTP, and the device forwards all PTP packets as normal traffic.
end-to-end transparent - The device acts as an end-to-end transparent clock, synchronizing all ports to a connected master clock and updating the time interval field of forwarded PTP packets using switch residence time.
peer-to-peer transparent - The device acts as a peer-to-peer transparent clock, synchronizing all ports to a connected master clock and updating the time interval field of forwarded PTP packets using switch residence time and inbound path delays.
generalized Precision Time Protocol (gPTP) - The device runs generalized Precision Time Protocol (gPTP), participating in the best master clock algorithm but also updating the interval field of forwarded PTP packets using switch residence time and inbound path delays.

To disable PTP globally on the switch, use the no or default forms of the ptp mode command.

Example

This command configures the device as a PTP boundary clock.

switch(config)# ptp mode boundary
switch(config)#

Enabling PTP on an Interface

To enable PTP on a specific interface on the device, use the ptp enable command.

Example

This command enables PTP on interface ethernet 5.

switch(config)# interface ethernet 5
switch(config-if-Et5)#ptp enable

Configuring the PTP Domain

To set the domain number to use for the clock, use the ptp domain command.

Example

This command configures the domain 1 to use with a clock.

switch(config)# ptp domain 1
switch(config)#

Configuring the Offset Hold Time

To set the PTP offset hold time, use the ptp hold-ptp-time command.

Example

This command configures the PTP offset hold time to 600 seconds.

switch(config)# ptp hold-ptp-time 600
switch(config)#

Setting the PTP Priority

To set the priority 1 value, use the ptp priority1 command. Lower values take precedence.

This command configures the priority 1 value of 120 to use when advertising the clock.

switch(config)# ptp priority1 120
switch(config)#

To set the priority 2 value for the clock, use the ptp priority2 command.

This command configures the priority 2 value of 128.

switch(config)# ptp priority2 128
switch(config)#

Connection Management

The switch supports three connection methods:

console
SSH
Telnet

The switch always enables the console and SSH. By default, the Telnet is disabled.

Management commands place the switch in a configuration mode to change session connection parameters.

Examples

The management console command places the switch in console management mode:
```
switch(config)#management console
switch(config-mgmt-console)#
```
The management ssh command places the switch in SSH management mode:
```
switch(config)#management ssh
switch(config-mgmt-ssh)#
```
The management telnet command places the switch in Telnet management mode:
```
switch(config)#management telnet
switch(config-mgmt-telnet)#
```
The exit command returns the switch to global configuration mode:
```
switch(config-mgmt-ssh)#exit
switch(config)#
```

The idle-timeout commands shown in the following examples configure the idle timeout period for the configured connection type. The idle timeout is when the connection waits after a user's most recent command before shutting down the connection. Setting the idle timeout to zero will automatically disable the connection timeout, which is the default setting.

Examples

This idle-timeout (SSH Management) command configures an SSH idle-timeout period of three hours.
```
switch(config)# management ssh
switch(config-mgmt-ssh)# idle-timeout 180
```
This idle-timeout (Telnet Management) command automatically disable the connection timeout for telnet connections.
```
switch(config)# management telnet
switch(config-mgmt-telnet)# idle-timeout 0
```

The shutdown (Telnet Management) command turns the Telnet on and off on the switch.

These commands enable Telnet.

switch(config)# management telnet
switch(config-mgmt-telnet)# no shutdown

These commands disable Telnet.

switch(config)# management telnet
switch(config-mgmt-telnet)# shutdown

Switch Storage Device Secure Erase

The Secure erase removes all data from the flash and optional SSD storage device(s) within an Arista switch. It securely erases the storage devices whose partitions mount to /mnt/crash, /mnt/drive, and /mnt/flash (as applicable), then repartitions these storage devices and re-creates the file systems for each of their partitions. In other words, the partition table of each storage device is the same as before this secure erase procedure (MBR gets destroyed during a secure erase); each partition will have the same file system type and partition label and mount to the same mount point with the same options. It makes it possible to boot the EOS again by installing a new boot-config and EOS SWI, then rebooting (done using Aboot/fullrecover).

All secure erasing is the best effort; we use firmware-based secure erase when available and a software-based mechanism when the firmware mechanism might fail or be insufficient (e.g., writing random data even after sending an ATA Secure Erase command) or does not exist (e.g., eUSB). Unfortunately, no non-physically destructive mechanism can guarantee the destruction of all data on a storage device.

Note: Certain Arista switches have a dedicated storage device for serial console logging. The console output is sensitive data, and we do not secure erasing this storage device. Platform support and usage information regarding serial console logging is here: https://www.arista.com/en/support/toi/eos-4-21-0f/14038-reload-console-logs.

Preparing for Secure Erase

Always connect to the switch/supervisor via the serial console before executing the CLI command. Executing the CLI command will leave the switch in Aboot since the Aboot shell is only available from the serial console, a switch will only be accessible via its serial port after executing this command.

If a system has two supervisors, standby has the redundancy state of the erased supervisor.

Performing Secure Erase

To securely erase the flash and optional SSD storage device(s) on supported platforms, use the reset system storage secure command.

Examples

The following commands check the redundancy status of the supervisor to be erased, then perform a switchover to change its status to standby preparatory to initiating the secure erase:
```
switch#show redundancy status
  my state = active
peer state = standby
switch#config
switch(config)#redundancy manual switchover
This supervisor is restarted.
```

The following command securely erases data stored on the switch, excluding dedicated console logging storage:

switch#reset system storage secure
WARNING! This will destroy all
data and will NOT be recoverable.
Device will reboot into Aboot, and
execution may take up to one hour.
Would you like to proceed? [y/N] y

Configure Session

The command configure session creates a configuration session for CLI commands, which can occur later when the session commits. Each configure session has a unique name. A session can enter, modify, and exit anytime without impacting the currently running system configuration.

When a session is in the commit stage, running-config has copies of the modified configuration of the session, overwriting any other configuration changes made since it creates the session. A session can be aborted or removed, thereby removing the session completely and freeing up memory used by the session. The user must explicitly request the changes in a deferred session to the router's configuration by entering a commit command and exiting the mode. Alternatively, the user may abandon the changes by entering an abort command. An uncommitted configuration session will be discarded if the switch reboots and will time out after 24 hours.

Configuration sessions use to make changes after verifying that there are no CLI errors. Configuration sessions allow the administrator to pre-provision a group of CLI commands in a named session and execute each configuration session at specified times.

Configuration Session

The configure session command allows users to make a series of configuration changes in a temporary location and commit them to running-config by issuing the commit command.

configure session <name of session> and running-config: The user enters a session (versus configure terminal where configuration sessions are not used). It creates a system-named session if a session name is not specified, and it copies a snapshot of the current running-config into the session’s data structure as the basis of further configuration changes.
CLI configuration commands: The user can run any commands inside the session.
rollback clean-config: The user can run the rollback command to revert the session configuration to the factory-default configuration (or clean configuration).
show session-config: The user can run show session-config to show the session configuration, which will be the future running-config after committing.
commit: User issues commit to commit the changes, which will replace the current running-config.
abort: To abort the session and throw away all changes.
exit: The user can exit from the session and return to the same session by running the configure session again.
For a named session: More than one CLI instance can enter the same session and change the session configuration. After the session commits in any of the CLIs, no other CLI can commit or make any other changes in that session.

Note: committing a configuration session replaces running-config with the session configuration, which consists of the running configuration at the initial session and the commands entered as part of the session. Any changes made to running-config since the initiation of the session overwrite when the session is in the commit stage.

Configure Replace

The command configure replace <URL> replaces the current running-config with the configuration saved in <URL>. By default, configure replace <URL> will replace running-config only if the configuration in <URL> loads without errors. The command configure replace <URL> ignore-errors force the operation even if there are errors.

Note: The command copy <URL> running-config applies a saved configuration file to the system and appends that configuration to the current running-config (instead of replacing it). However, Arista recommends using the CLI command configure replace <URL> to streamline the process of deterministically restoring the system to a known good configuration.

The normal workflow internally uses a configuration session to perform the replace.

Configuration CLI

In the CLI, execute the following configuration steps to create a configuration session.

configure session [name of session]
Create or enter a session. If a name is not specified, it automatically generates. The user is in the session configuration mode, and the prompt will change to show the first six characters of the session name. Designating the name of a session is optional. When the name of session is not specified, a unique name is assigned.
```
no configure session  name of session 
```
Delete the specified configuration session. Designating the name of a session is required.
commit
Commit the changes made in the session. Configuration mode issues this command within the session.
```
abort
```
Abort the session, which is the same as deleting it. Configuration mode issues this command within the session.
rollback clean-config
Revert the configuration in the session to the clean, factory-default configuration. Configuration mode issues this command within the session.
service configuration session max completed number
Sets a limit on the maximum number of saved committed sessions.
service configuration session max pending number
Sets a limit on the maximum number of uncommitted sessions that can be outstanding.

Recovery Procedures

These sections describe switch recovery procedures:

Removing the Enable Password from the Startup Configuration
Reverting the Switch to the Factory Default Startup Configuration
Restoring the Factory Default EOS Image and Startup Configuration
USB Support for ZeroTouch Provisioning
Restoring the Configuration and Image from a USB Flash Drive

The first three procedures require Aboot Shell access through the console port. If the console port is inaccessible, use the last procedure in the list to replace the configuration file through the USB Flash Drive.

1 describes the switch booting process and includes descriptions of the Aboot shell, Aboot boot loader, and required configuration files.

Removing the Enable Password from the Startup Configuration

The enable password controls access to Privileged EXEC mode. The switch stores the enable password as an encrypted string generated from the clear-text password to prevent unauthorized disclosure.. When the switch authentication mode is local and configures an enable password, the CLI prompts the user to enter the clear-text password after the user types enable at the EXEC prompt.

The startup-config file stores the encrypted enable password to ensure the switch loads it when rebooting. If the text version of the enable password is lost or forgotten, access to enable mode restored by removing the encrypted enable password from the startup configuration file.

Note: During the recovery process, the secondary supervisor must be physically removed from the system containing more than one supervisor. It ensures the previous configuration is not recovered from the secondary supervisor upon reboot during the recovery process.

This procedure restores access to enable mode without changing any other configuration settings.

Access the Aboot shell:
1. Power cycle the switch by successively removing and restoring access to its power source.
2. Type Ctrl-C when prompted early in the boot process.
3. Enter the Aboot password if prompted. If the Aboot password is unknown, refer to Restoring the Factory Default EOS Image and Startup Configuration for instructions on reverting all flash directory contents to the factory default, including the startup configuration and EOS image.
Change the active directory to the /mnt/flash directory.
```
Aboot# cd /mnt/flash
```
Open the startup-config file in vi.
```
Aboot# vi startup-config
```
Remove the enable password line.
This is an example of an enable password line:
```
enable password 5 $1$dBXo2KpF$Pd4XYLpI0ap1ZaU7glG1w/ 
```
Save the changes and exit vi.
Exit Aboot. It boots the switch.
```
Aboot# exit
```

Reverting the Switch to the Factory Default Startup Configuration

The startup-config file contains configuration parameters that the switch uses during a boot. Parameters not appearing in startup-config are set to factory defaults when the switch reloads. The process requires the Aboot password if Aboot is password protected.

This procedure reverts EOS configuration settings to default by bypassing the startup-config file during a switch boot.

Access the Aboot shell through the console port:
1. Type reload at the Privileged EXEC prompt.
2. Type Ctrl-C when prompted early in the boot process.
3. Enter the Aboot password if prompted. If the Aboot password is unknown, refer to Restoring the Factory Default EOS Image and Startup Configuration for instructions on reverting all flash directory contents to the factory default, including startup-config and EOS image.
Change the active directory to the /mnt/flash directory.
```
Aboot# cd /mnt/flash 
```

Rename the startup configuration file.

Aboot# mv startup-config startup-config.old

Exit Aboot. This boots the switch.
```
Aboot# exit
```
Cancel Zero Touch Provisioning (ZTP). Refer to Canceling Zero Touch Provisioning for instructions.
For non-canceled ZTP, the switch either:
- boots, using the startup-config file or boot script that it obtains from the network, or
- remains in ZTP mode if the switch cannot download a startup-config file or boot script.

Configure the admin and enable passwords.

switch> enable
switch# configure terminal
switch(config)# enable password xyz1 
switch(config)# username admin secret abc41

Save the new running-config to the startup configuration file.
```
switch# write
```
(Optional) Delete the old startup configuration file.
```
switch# delete startup-config.old
```
After canceling ZTP, the switch reboots using the factory default settings, to avoid entering ZTP mode on subsequent reboots, create a startup-config file before the next switch reboot.

Restoring the Factory Default EOS Image and Startup Configuration

A fullrecover command removes all internal flash contents (including configuration files, EOS image files, and user files), then restores the factory default EOS image and startup-config. When the default image is outdated, a subsequent installation of the current EOS image is required. This process requires Aboot shell access through the console port.

Note: For hardware available after June 2017, the factory default partition will not have the backup EOS software image. It increases the flash size on smaller flash disks. Other options are available in the fullrecover command functionality to restore the factory default EOS image. It applies to both fixed system and modular system hardware.

This procedure restores the factory default EOS image and startup configuration.

Access the Aboot shell through the console port:
1. Type reload at the Privileged EXEC prompt.
2. Type Ctrl-C when prompted early in the boot process.
3. Enter the Aboot password if prompted. If the Aboot password is not known, enter an empty password three times, after which the CLI displays:
```
Type "fullrecover" and press Enter to revert /mnt/flash to factory default state, or just press Enter to reboot:
```
4. Type fullrecover and go to 4.

Type fullrecover at the Aboot prompt.

Aboot#fullrecover

Aboot displays this warning:

All data on /mnt/flash will be erased; type "yes" and press Enter to proceed, or just press Enter to cancel:

Type yes and select the Enter key.
The switch performs these actions:
- erases the contents of /mnt/flash.
- writes new boot-config, startup-config, and EOS.swi files to /mnt/flash.
- returns to the Aboot prompt.
Exit Aboot. It boots the switch.
```
Aboot#exit
```
The serial console settings restore to their default values (9600/N/8/1/N).
Reconfigure the console port if non-default settings are required.
Cancel Zero Touch Provisioning (ZTP). Refer to Canceling Zero Touch Provisioning for instructions.
For non-canceled ZTP, the switch either:
- Boots, using the startup-config file or boot script that it obtains from the network or
- Remains in ZTP mode if the switch cannot download a startup-config file or boot script.
For canceled ZTP, the switch reboots using the factory default settings. To avoid entering ZTP mode on subsequent reboots, create a startup-config file before the next switch reboot.

USB Support for ZeroTouch Provisioning

Use Arista’s Zero Touch Provisioning to configure a switch without user intervention. The USB adds another way to provide the bootstrap name and verify the authenticity of the file server.

USB Deployment

By using a USB drive during ZTP, the following features are possible:

Specify the location of the bootstrap file instead of using DHCP Option 67.
Provide the x509 root of trust for verifying the bootstrap download location.
Provide the enrollment token for CloudVision Service customers.

Configuration

A USB containing a yaml configuration file is plugged into the Arista EOS switch before powering it on.

The configuration (<USB-ROOT>/ztp/ztpConfig.yaml) should look like this:

 "bootstrapUrl"
 "serverCaCertificate"
 "enrollmentToken"
"version": "1.0"

bootstrapUrl: URL for bootstrap file, such as https://cvp/config.py.

 "bootstrapUrl"

serverCaCertificate: path for x509 root of trust for the remote file server on the USB, such as “ca.crt”.

"serverCaCertificate"

enrollmentToken: path for enrollment token on the USB, such as “token.tok”

"enrollmentToken"

All ZTP related files, serverCaCertificate and enrollmentToken, should be present in (<USB-ROOT>/ztp/* ), and the location is to be specified in the ztpConfiguration yaml w.r.t to this folder.

"version": "1.0"

All the fields are optional. For example, this is a valid configuration. It will act as though there is no USB in place.

 "bootstrapUrl"
 "serverCaCertificate"
 "enrollmentToken"
"version": "1.0"

The following is a sample of the configuration. The structure of the USB drive is:
USB Drive Roo
- ca.crt
- token.tok

 "bootstrapUrl"
 "serverCaCertificate"
 "enrollmentToken"
"version": "1.0"

Advantages

DHCP Server no longer needs to have Option 67 configured.
The boot script location can now undergo additional checks, such as validating the endpoint before downloading and running the boot script.
Customers wishing to enroll their devices in the CloudVision Service have an easy means to do so.

Restoring the Configuration and Image from a USB Flash Drive

The USB flash drive port restores an original configuration when you cannot establish a connection to the console port. This process removes the contents of the internal flash drive, restores the factory default configuration, and installs a new EOS image from the USB flash drive.

This procedure restores the factory default configuration and installs an EOS image stored on a USB flash drive.

Prepare the USB flash drive:
1. Verify the drive is formatted using MS-DOS or FAT file system. Most USB drives are pre-formatted with a compatible file system.
2. Create a text file named fullrecover on the USB flash drive. The filename does not have an extension. The file may be empty.
3. Create a text file named boot-config. The last modified timestamp of the boot-config file on the USB flash must differ from the timestamp of the boot-config file on the switch.
4. Enter this line in the new boot-config file on the USB flash:
```
SWI=flash:EOS.swi
```
5. Copy an EOS image file to the flash drive. Rename it EOS.swi if it has a different file name. For best results, the flash drive should contain only these three files because the procedure copies all files and directories on the USB flash drive to the switch.
  - fullrecover
  - boot-config
  - EOS.swi
Insert the USB flash drive into the USB flash port on the switch, as shown in Figure 1.
Connect a terminal to the console port and configure it with the default terminal settings (9600/N/8/1) to monitor progress messages on the console.
Power up or reload the switch.
The switch erases internal flash contents and copies the files from the USB flash drive to internal flash. The switch then boots automatically.
Cancel Zero Touch Provisioning (ZTP). Refer to Canceling Zero Touch Provisioning for instructions.
If ZTP is not canceled, the switch either:
- Boots, using the startup-config file or boot script that it obtains from the network or
- Remains in ZTP mode if the switch cannot download a startup-config file or boot script.
After canceling ZTP, the switch reboots using the factory default settings to avoid entering ZTP mode on subsequent reboots and creates a startup-config file before the next switch reboot.

Page 13 of 15

End of Support

EOS 4.33.1F User Manual - Timing Protocols

Timing Protocols

EOS 4.33.1F User Manual - Setting the PTP Mode

Setting the PTP Mode

EOS 4.33.1F User Manual - Enabling PTP on an Interface

Enabling PTP on an Interface

Example

EOS 4.33.1F User Manual - Configuring the PTP Domain

Configuring the PTP Domain

EOS 4.33.1F User Manual - Configuring the Offset Hold Time

Configuring the Offset Hold Time

EOS 4.33.1F User Manual - Setting the PTP Priority

Setting the PTP Priority

EOS 4.33.1F User Manual - Connection Management

Connection Management

Examples

Examples

EOS 4.33.1F User Manual - Switch Storage Device Secure Erase

Switch Storage Device Secure Erase

Preparing for Secure Erase

Performing Secure Erase

Examples

EOS 4.33.1F User Manual - Configure Session

Configure Session

Configuration Session

Configure Replace

Configuration CLI

EOS 4.33.1F User Manual - Recovery Procedures

Recovery Procedures

Removing the Enable Password from the Startup Configuration

Reverting the Switch to the Factory Default Startup Configuration

Restoring the Factory Default EOS Image and Startup Configuration

USB Support for ZeroTouch Provisioning

USB Deployment

Configuration

Advantages

Restoring the Configuration and Image from a USB Flash Drive