Important notice

• Login security

Login security

1 Function Overview

This product includes the following user account management improvements as countermeasures for ensuring cyber security.

To eliminate the risk of malicious cyber-attacks and ensure the product is used safely, be sure to read this document carefully and specify an appropriate user password before use.

For details, refer to User account management.

• Mandatory administrator registration
  • At least one administrator account must be registered for this product.

    Therefore, a default administrative user (username: admin and password: admin) has been specified for logging in to the product the first time.

  • When first logging in, specify admin for both the username and password.
  • After logging in using the default administrative user account, the user is prompted to change the password setting.

• Stricter limits on guest user operations
  • If the special privileged access password (default administrative password) has not been changed, the following operations that use a special privileged access password will be restricted.
    • Users without administrator rights cannot switch to the privileged EXEC mode.
    • Factory settings cannot be restored using CLI/ GUI operations.
    • Connections as a TFTP server cannot be received.
  • To perform the above operations, change the special privileged access password (default administrative password).

• Countermeasure for Brute-Force Attacks
  • As a countermeasure against brute-force attacks, login restrictions are applied after a login fails.
  • If an incorrect password is entered three successive times when logging into the switch via the console, Web GUI, or other means, login is disabled for one minute thereafter, even if the correct password is entered.
  • If the password is entered incorrectly, wait at least one minute before trying to log in again.

2 Applicable models and revisions

User account management has been improved in the following models and revisions.

3 Precautions when updating firmware

If the firmware is updated with stronger user account management functionality, be sure to register an administrator account according to the following procedure before using the switch.

1. Register the administrator account with the previous firmware running, which has not been updated with stronger user account management functionality.
   • If an administrator account already exists, then no account registration is necessary.
   • However, if a password was not specified for the administrator account, be sure to specify a password.
   • It is not a problem if the user name for the administrator account is the default “admin”.
     

     Yamaha>enable
     Yamaha#configure terminal
     Yamaha(config)#username (username) privilege on password (password)

2. Create guest user
   If necessary, create a guest user as follows.
   • If using the username command, create it with the privilege option disabled (off).
     

     Yamaha(config)#username (username) privilege off password (password)

3. Change the special privileged access password (administrative password)
   • The default special privileged access password (administrative password) setting is “admin”.
   • To change the special privileged access password (administrative password) using a command, use the enable password command.
     

     Yamaha(config)#enable password (special privileged access password)

4. Update the firmware as described in
   • Firmware update“update the firmware to the updated version”.

4 Related Documentation

• User account management
• Remote access control
• Firmware update

Maintenance and operation functions

• User account management
• LED control
• Using external memory
• Boot data management
• Viewing unit information
• System self-diagnostic
• Cable diagnostics
• Config management
• Remote access control
• Time management
• SNMP
• RMON
• SYSLOG
• Firmware update
• L2MS control
• Mail notification
• LLDP
• LLDP automatic setting
• Terminal monitoring
• Performance observation
• Scheduling function
• Dante optimization setting function
• SDVoE setting optimization function
• Stack function
• PTP
• Buzzer
• List of default settings

User account management

1 Function Overview

This product provides the functions shown below for managing user accounts.

• Functions for setting user information
• Functions for user authentication by user name and password

2 Definition of Terms Used

1. Default administrative user

   Users with administrator rights specified in default factory settings.

   Username: admin and Password: admin

2. Administrative user

   Users with administrator rights.

   Administrative users are users with the privilege option switched on using the username command.

3. Guest user

   Users without administrator rights and that require entering the special privileged access password (administrative password) in order to access the privileged EXEC mode.

   Guest users are users with the privilege option switched off using the username command.

4. Special privileged access password (administrative password)

   The password used to assign administrator rights and specified using the enable password command.

5. Unnamed user

   Users with a blank username setting.

   Rev.4.02.09 or earlier firmware versions permitted using unnamed user accounts under factory default settings, but unnamed user accounts were eliminated newer firmware versions with stronger user account management functionality.

3 Function Details

3.1 User account function settings

3.1.1 Setting user information

Use the username command to specify the following user information.

• User name
• Password
• Assignment of administrator rights

With factory default settings, the administrative username and password are both “admin”.

3.1.2 Setting the special privileged access password (administrative password)

Special privileged access passwords (administrative passwords) are set using the enable password command.

Special privileged access passwords (administrative passwords) are used for the following applications.

• To initialize devices
• To transition users without administrator rights to the privileged EXEC mode.
• To use a TFTP client to send a config file or firmware to the switch

The factory default special privileged access password (default administrative password) setting is admin, but the operations described above cannot be performed if the special privileged access password (default administrative password) is set to the default setting.

To perform any of those operations, change the special privileged access password (default administrative password) in advance.

3.1.3 Administrator rights

User login operations can be restricted depending on whether or not the user has administrator rights.

• Administrative users (users with administrator rights) can change device settings or update firmware.
• Guest users (users without administrator rights) can only view device information without changing any settings.

Specifically, the following differences apply depending on whether or not the user has administrator rights.

*1: Cannot view passwords or other security-related settings.

Once the enable command is executed and the special privileged access password (administrative password) is entered, the privileged EXEC mode can be accessed to perform operations equivalent to an administrative user, even if logged in as a guest user.

For information about the rights required to execute each command, refer to the command reference.

3.1.4 Password encryption

Specified passwords can be encrypted using the password-encryption command.

To encrypt a password, specify the password-encryption enable setting.

Once a password has been encrypted, it cannot be restored to an unencrypted character string state, even by specifying the password-encryption disable setting.

Encryption applies to the passwords specified by the following commands.

• enable password command
• username command

3.2 User authentication

3.2.1 When logging in to the console

When the following login prompt appears after connecting to the console, log in by entering the specified username and password.

Username:
Password:

For factory default settings, log in by entering “admin” as the default administrative username (and “admin” as the password).

After using “admin” to log in, the password must be changed to specify a new password.

Username: admin
Password:                                ... (Enter “admin”)

SWX3220-16MT Rev.4.02.00  (Fri Jan  1 00:00:00 2021)
  Copyright (c) 2018-2021 Yamaha Corporation. All Rights Reserved.

Please change the default password for admin.
New Password:                            ... (Enter new password.)
New Password(Confirm):                   ... (Enter the same password again.)
Saving ...
Succeeded to write configuration

If an incorrect password is entered three successive times, login by that same user is restricted for one minute.

Username: User
Password:
% Incorrect username or password, or login as User is restricted.
Password:
% Incorrect username or password, or login as User is restricted.
Password:
% Incorrect username or password, or blocked upon 3 failed login attempts for User.
% Please try again later.

If a login restriction occurs, the following message is output in the INFO level SYSLOG.

Note that if a user with a login restriction enters an incorrect password again, the remaining time until the restriction is cancelled is reset to one minute again.

3.2.2 Logging into the Web GUI

When the following login form appears after accessing the Web GUI, log in by entering the specified username and password.

For factory default settings, log in by entering “admin” as the default administrative username (and “admin” as the password).

If logging in with factory default settings, a Web GUI language selection screen is displayed after logging in.

If prompted to change the password after using “admin” to log in, specify a new password.

3.3 What to do if you forget your login password

If the product is rebooted connected to the serial console and “I” (uppercase letter I) is entered during the booting process, the product can be rebooted with factory default settings.

BootROM - X.XX
Booting from SPI flash

SWX3220-16MT BootROM Ver.1.00      #### Enter “I” as soon as the boot ROM version is displayed. #### 

Initialize or not ?(y/n) y 

Loading config0 because can’t read config in SD card. 
Starting .............................................. 
Loading configuration ... Done!

SWX3220-16MT Rev.4.02.00  (Fri Jan  1 00:00:00 2021)
  Copyright (c) 2018-2021 Yamaha Corporation. All Rights Reserved.
  

4 Related Commands

The related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Adding a user

The following example assigns administrator rights to the user “yamaha” and specifies the password “yamaha_pass”.

Yamaha#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Yamaha(config)#username yamaha privilege on password yamaha_pass
Yamaha(config)#exit
Yamaha#exit

Username: yamaha
Password:

SWX3220-16MT Rev.4.02.00  (Fri Jan  1 00:00:00 2021)
  Copyright (c) 2018-2021 Yamaha Corporation. All Rights Reserved.

Yamaha>enable
Yamaha#

6 Points of Caution

• If no administrative user (user with administrator rights) exists in startup-config when the product is booted, then a default administrative user (with username “admin”and password “admin”) will be added automatically.

  For example, that would occur in the following case.

  • Product is booted with factory default settings configured
  • Firmware is updated to a newer version than Rev.4.02.09 after the product was operated using Rev.4.02.09 or older firmware only by an unnamed user.

• If a user with no password is specified in startup-config when the product is booted, then a password with the same character string as the username will be added automatically.

  For example, that would occur in the following case.

  • Firmware is updated to a newer version than Rev.4.02.09 after Rev.4.02.09 or older firmware was used to specify a user with no password.
    

    Setting with Rev.4.02.09 or earlier firmware version

    username yamaha1
    username yamaha2 privilege on
    

    Setting after updating firmware to a newer version than Rev.4.02.09

    username yamaha1 password yamaha1
    username yamaha2 privilege on password yamaha2
    

• If the password (admin) for the default administrative user admin is left unchanged, then the following restrictions are applied.
  • Switches cannot be accessed by TELNET, SSH, HTTP, or HTTPS from a network segment other than the maintenance VLAN.
  • Login by users other than the default administrative user is not permitted.

    Username: yamaha
    Password:
    % Please login as user "admin".
    

  • The following commands cannot be executed. Similar setting changes cannot be performed via the Web GUI either.
    • ip address / no ip address
      * However, only the ip address dhcp command can only be executed
    • auto-ip / no auto-ip
    • ipv6 / no ipv6
    • ipv6 address / no ipv6 address
    • management interface / no management interface

7 Related Documentation

• Remote access control

LED control

1 Function Overview

This product includes the following indicator lights on the main unit.

Indicator type

The location of each indicator is shown below.

2 Definition of Terms Used

Port Indicator Illumination Guide

Port indicator illumination mentioned in subsequent explanations are illustrated below.

Port Indicator illumination guide

3 Function Details

3.1 POWER Indicator

The POWER indicator indicates the power supply status to this product.

The corresponding status for each POWER indicator illumination mode is described below.

POWER indicator illumination mode and status

When the following errors are detected, the POWER indicator illuminates steady orange.

Check the error that was detected and take the appropriate actions.

• Fan stopped

  The fan that exhausts heat generated by the product has stopped.

  Immediately stop using the product and be sure to contact the dealer for inspection or service.

• Temperature error inside the product

  The temperature inside the product is abnormal.

  Review the ambient conditions where installed and install the product correctly so that internal temperature is appropriate.

• Damage to area where config is saved

  Config information is not read correctly during startup.

  Contact the dealer for inspection and/or service.

You can use the show environment command to check temperature and fan errors.

3.2 microSD Indicator

The microSD indicator indicates the microSD card connection and usage status.

The illumination mode of the microSD indicator and the corresponding status is described below.

microSD indicator illumination mode and status

Do not remove the microSD card while flashing green, because the microSD card is being accessed.

3.3 Port Indicators

3.3.1 Display Modes and Switching Between Them

This product offers the following three display modes.

The display mode can be restored to the default setting (indicator mode after system startup) using the led-mode default command.

However, the STATUS mode only switches automatically, so cannot be switched manually by the user.

The flowchart below shows how the indicator mode changes.

Indicator mode transition sequence

*1 Assuming the initial indicator mode is LINK/ACT

*2 Assuming the initial indicator mode is OFF

The indicator mode after system startup and the indicator mode after error is resolved depend on the default indicator mode setting.

If an error is detected by the following functions, the port indicators automatically switch to the STATUS mode.

• Loop detection
• SFP optical input level monitoring

The system will not transition from STATUS mode to LINK/ACT mode or OFF mode until all errors are resolved.

3.3.2 Indicators Displayed in LINK/ACT Mode

In the LINK/ACT mode, port indicators are illuminated as shown below.

• LAN/SFP port link status
• LAN/SFP port connection speed

The link status is indicated as shown below.

LAN/SFP port link status indicator display modes

	While Link is Down	While Link is Up	While Forwarding Data
LAN Ports	(Off)	(Steady green)	(Flashing green)
SFP Ports	(Off)	(Steady green)	(Flashing green)

The connection speed is indicated as shown below.

LAN/SFP port connection speed indicator display

	100M Link	1G Link	2.5G/5G/10G Link
LAN Ports	(Off)	(Steady orange)	(Steady green)
SFP Ports	(none)	(Steady green)	(Steady green)

3.3.3 Indicators Displayed in STATUS Mode

In STATUS mode, the port indicators indicate the status of errors generated by the following product functions.

• Loop detection
• SFP optical input level monitoring

The port indicator display modes during active errors are indicated below.

Port indicator display modes during active errors

	Normal State	Loop Detected or SFP Input Level　Error
LAN Ports	(Off)	(Left flashes orange)
SFP Ports	(Off)	(Left flashes orange)

When the product detects an error, it overrides the current mode and switches to STATUS mode.

The following conditions trigger an error in respective functions.

• Loop detection
  • Loop was detected, so port was blocked
  • Loop was detected, so port was shut down
• SFP optical input level monitoring
  • SFP optical input level fell below the normal range
  • SFP optical input level exceeded the normal range

The cause of the error can be checked using the show error port-led command.

During active errors in the STATUS mode, indicators will automatically switch to the default indicator mode in the following states.

• All of the following errors were resolved.
  • Blocked status due to loop detection is resolved.
  • Shutdown status due to loop detection is resolved.
    • The monitoring time elapsed after the shutdown due to loop detection.
    • The unit linked up after the no shutdown command was executed during shutdown due to loop detection.
  • SFP optical input level recovered.

3.3.4 Indicators Displayed in OFF Mode

If the default indicator mode is the OFF mode, the port indicators remain off regardless of the link status.

The stack ID indicators also switch off at the same time.

Even if the default indicator mode is OFF, if an error occurs then the mode automatically switches to the STATUS mode and displays the error status.

3.3.5 Changing the Indicator Mode after System Startup

This product enables the indicator mode after system startup (the default indicator mode) to be changed.

The initial default indicator mode is set to LINK/ACT mode, but it can be changed using the led-mode default command.

The default and current indicator modes can be checked using the show led-mode command.

If an active error is resolved in the STATUS mode, the mode is switched back to the default indicator mode.

3.3.6 Other Port Indicator Modes

Regardless of the indicator mode status, all port indicators will illuminate as indicated below during startup initialization and firmware updates.

Other port indicator modes

	Updating firmware	Initializing
LAN Ports	(Flashing green)	(Steady orange)
SFP Ports	(Flashing green)	(Steady orange)

3.4 Stack ID Display

After the countdown display during startup, the stack ID display (seven-segment display) displays the stack ID, if a stack is configured.

If a stack is not configured, the number ‘1’ is displayed.

If an error occurs while a stack is configured, the letter ’E’ is displayed to indicate the error.

If the default indicator mode is the OFF mode, the stack ID display is also switched off.

4 Related Commands

Related commands are indicated below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Checking LAN/SFP Port Status

Use the show interface command to check the LAN/SFP port status.

Yamaha#show interface
show interface
Interface port1.1
  Link is UP
  Hardware is Ethernet
  HW addr: ac44.f23d.0b2c
  ifIndex 5001, MRU 1522
  Speed-Duplex: auto(configured), 1000-full(current)
  Auto MDI/MDIX: on
  Vlan info :
    Switchport mode        : access
    Ingress filter         : enable
    Acceptable frame types : all
    Default Vlan           :    1
    Configured Vlans       :    1
  Interface counter:
    input  packets          : 317111
           bytes            : 31387581
           multicast packets: 317074
    output packets          : 162694
           bytes            : 220469213
           multicast packets: 162310
           broadcast packets: 149
           drop packets     : 0
  ：
(Shows information for all LAN/SFP ports)

5.2 Checking LAN/SFP Port Loop Detection Status

Check the LAN/SFP port loop detection status.

Yamaha#show loop-detect
loop-detect: Enable

loop-detect: Enable

port      loop-detect    port-blocking           status
-------------------------------------------------------
port1.1        enable           enable           Normal
port1.2        enable           enable           Normal
port1.3        enable           enable           Normal
port1.4        enable           enable           Normal
port1.5        enable           enable           Normal
port1.6        enable           enable           Normal
port1.7        enable           enable           Normal
port1.8        enable           enable           Normal
port1.9        enable           enable           Normal
port1.10       enable           enable           Normal
-------------------------------------------------------
(*): Indicates that the feature is enabled.

5.3 Setting the Default Indicator Mode

Set the default indicator mode to the OFF mode.

Yamaha#configure terminal
Yamaha(config)#led-mode default off … (Sets the default indicator mode)
Yamaha(config)#exit
YamahaW#show led-mode … (Displays the indicator mode)
default mode : off
current mode : off

Using external memory

1 Function Overview

This product provides the following functions using external memory.

• SD card boot (firmware, config)
  • The system can be started using a firmware file and config file from an SD card.
• Applying SD card booting automatically (firmware, config)
  • The firmware and config file used for SD card booting can be applied the next time the product is booted, even if the SD card is unavailable.
• Firmware update
  • This unit’s firmware can be updated by loading a firmware file from an SD card.
• Saving and copying a config file
  • The running-config that is currently running on the system can be saved to an SD card, and config files can be copied from the SD card to the unit’s flash ROM or from the unit’s flash ROM to the SD card.
• Saving a log file
  • By executing the save logging command you can back up the log file to an SD card.
• Saving technical support information
  • Technical support information (the result of executing the show tech-support command) can be saved to an SD card.
• Saving statistical information
  • Observations of resource information and traffic information are backed up regularly.
  • This statistical information can be saved as a CSV format file.
• Backing up and restoring system information
  • System information (including configurations) can be backed up to an SD card.
  • Backed up system information can be restored into the unit’s flash ROM.

2 Definition of Terms Used

None

3 Function Details

3.1 External memory that can be used

Requirements for external memory that can be used are as follows.

• Card type: microSD card / microSDHC card
• File format: FAT16/FAT32

3.2 Folder structure

The SD card must contain the following folder structure.

Device name	+-- firmware          Firmware file storage folder
 		|
 		|
 		+-- startup-config    Startup config storage folder
 		|
 		|
 		+-- log               SYSLOG storage folder
 		|
 		|
 		+-- techsupport       Technical support information storage folder
 		|
 		|
 		+-- data              System-wide folder
 		|
 		|
 		+-- backup-system     System backup folder
　　　　　　　　　　　　　　

3.3 Mounting and unmounting the SD card

If the SD card is inserted when starting up or after startup, it is automatically mounted and becomes available.

To prevent loss of files, execute the unmount sd command or execute the unmount operation from the Web GUI before removing the SD card.

If the SD card is unmounted, it cannot be used.

If you want to once again use the SD card after executing the unmount sd command, you must execute the following.

• Remove and reinsert the SD card
• Execute the mount sd command
• Execute mount from the Web GUI

3.4 SD card boot (firmware, config)

The system can be started using a firmware file and config file from an SD card.

In order to use SD card boot, the following conditions must be satisfied.

• SD card using a firmware file
  • The SD card is connected when the system starts up.
  • The following files exist in the SD card.
    • /swx3220/firmware/swx3220.bin
  • boot prioritize sd enable is specified.
    * With the factory settings, boot prioritize sd enable is specified.

• SD card boot using a config file
  • The SD card is connected when the system starts up.
  • The SD card includes the following files.
    • /swx3220/startup-config/config.txt
  • startup-config select sd is specified.
    * With the factory settings, startup-config select sd is specified.

The file used for SD card booting can also be automatically saved to internal flash ROM memory using the automatic SD card booting function (see 3.5 Automatic SD card booting).

You can use the show environment command to check whether SD card boot was successful.

• In the case of SD card boot using a firmware file, “Startup Firmware” will indicate “exec(SD).”
• In the case of SD card boot using a config file, “Startup Configuration” will indicate “config(SD).”

In the case of SD card boot using a config file, executing the write and copy running-config startup-config commands will update the config file on the SD card.

If SD card boot using a config file fails, startup config #0 is loaded.

Also, the following message is shown in the console and in SYSLOG.

Loading config0 because can’t read config in SD card.

3.5 Automatic SD card booting (firmware, config)

The firmware and config used for SD card booting can be automatically saved to internal flash ROM memory.

This function can be used to easily install previously prepared firmware and config files in newly purchased devices (with factory settings).

3.5.1 Preparations before using automatic saving

In order to use this function, the following conditions must be satisfied.

• SD card booting is enabled by either of the following methods. (For details, see 3.4 SD card booting.)
  • The boot prioritize sd enable command is specified and firmware is installed with an appropriate path for SD cards.
  • startup-config select sd is specified and the config file is installed with an appropriate path.
• The automatic SD card booting function is enabled.
  • The automatic SD card booting function can be enabled using the boot auto-apply enable command.

    (Note: Enabled in default factory settings.)

  • The show environment command “boot auto-apply” display results can be used to confirm whether the function is enabled or disabled.
• Prepare a file for automatically applying the automatic SD card booting function.
  • If firmware is applied automatically
    • Prepare an auto-apply.txt file (empty text file) in the firmware folder in the SD card.
      

      /swx3220/firmware/auto-apply.txt

  • If a config file is applied automatically
    • Prepare an auto-apply.txt file (empty text file) in the startup-config folder in the SD card.
      

      /swx3220/startup-config/auto-apply.txt

3.5.2 Procedure for automatic SD card booting

Use the following procedure to automatically apply SD card booting.

1. Implement preparations. (See 3.5.1 Preparations before using automatic saving)
2. Insert the SD card and boot the switch.
3. When SD card booting is finished, automatic save the specified file in internal flash memory. (Booting by automatic SD card booting takes longer than normal.)
4. Save the results from automatic SD card booting. (See 3.5.3 Automatic SD card booting results.)
5. Automatically unmount the SD card.
6. Automatically switch off the microSD LED.

3.5.3 Automatic SD card booting results

Automatic SD card booting results are saved in the SD card.

• Automatic SD card booting results

  File name and directory path	Log
  /swx3220/startup-config/auto-apply-result.txt	Serial : Date/time : Result
  /swx3220/firmware/auto-apply-result.txt	Serial : Date/time : Result

3.5.4 Location for saving config file

To change the config location to a user-specified config ID, rename the auto-apply.txt file created, as indicated below.

If no config location is specified, the default config ID of 0 is applied.

• File name of each config file location

  File name and directory path	Config ID
  /swx3220/startup-config/auto-apply.txt	0
  /swx3220/startup-config/auto-apply0.txt	0
  /swx3220/startup-config/auto-apply1.txt	1

3.5.5 Precautions

Note the following precautions when using this function.

• When the automatic SD card booting is successful, the function is automatically disabled.

  To avoid it being disabled automatically, the character string “keep” must be included at the top of the auto-apply.txt file created, as shown below.

  keep

• This function is disabled if the stack function is enabled.
• If the SD card does not contain an auto-apply.txt file, the function is disabled.
• If the device was not booted from the SD card, the automatic SD card booting function will fail even if an auto-apply.txt file exists.

  Refer to 3.4 SD card booting to confirm that the file in the SD card and the SD card booting function are enabled.

• If automatic SD card booting fails, only the SD card will be unmounted without automatically disabling the function.
• To prevent malfunction, be sure to delete the auto-apply.txt file if the automatic SD card booting function is not used.

3.6 Firmware update

This unit’s firmware can be updated by loading a firmware file from an SD card.

In order to use this function, the following conditions apply.

• The following files exist in the SD card.
  • /swx3220/firmware/swx3220.bin

If the above file exists on the inserted SD card, executing the firmware-update sd execute command updates the firmware in flash ROM using the firmware in the SD card.

When the firmware-update sd execute command is executed, the user will be asked whether to maintain the mounted state of the SD card when the firmware file has finished loading. Remove the SD card as necessary after it is unmounted.

Note that if the SD card is left inserted during the automatic reboot in conjunction with firmware update, the system will start up with the firmware file on the SD card.

The firmware of the member switch can be updated by executing the firmware-update sd execute command from the main switch during stack configuration.

3.7 Saving and copying a config file

The running-config that is currently running on the system can be saved to the SD card. ( copy running-config startup-config command, write command)

You can copy the config file from the SD card to internal flash ROM, or from internal flash ROM to the SD card. ( copy startup-config command)

You can erase or show the startup-config in the SD card. ( erase startup-config command, show startup-config command)

The following folder in the SD card is affected.

• /swx3220/startup-config

3.8 Saving a log file

By executing the save logging command you can back up the log file to an SD card.

The logging backup sd command enables SYSLOG backup to the SD card.

If SYSLOG backup to the SD card is enabled, executing the save logging command will save the following log file with its save date to the SD card.

• /swx3220/log/YYYYMMDD_log.txt *YYYYMMDD=year month day

The log files in the SD card cannot be viewed or erased.

3.9 Saving technical support information

Technical support information (the result of executing the show tech-support command) can be saved to an SD card.

Executing the copy tech-support sd command will save the following technical support information file with its save date to the SD card.

• /swx3220/techsupport/YYYYMMDDHHMMSS_techsupport.txt *YYYYMMDD=year month day, HHMMSS=hours minutes seconds

The technical support information files in the SD card cannot be viewed or erased.

If the copy tech-support sd command is executed from the main switch in a stack configuration, a file containing technical support information for member switches is saved.

3.10 Saving statistical information

Observations of resource information and traffic information are backed up regularly.

To enable backup of statistical information to the SD card, you must make settings via the Web GUI in [Administration]–[Maintenance]–[Statistical information management].

This statistical information for the observed data can be saved via the Web GUI as a CSV format file.

3.11 Backup and restore of system information

This unit’s system information can be backed up to an SD card, and the backed up system information can be restored to a desired switch.
With an SD card connected to this unit, executing the backup system command will create a system information backup in the following folder.

• /swx3220/backup-system

If the file swx3220.bin exists in the /swx3220/firmware/ folder when backup is executed, it is backed up as a firmware file.

To restore the backed up system information, connect the SD card containing the system information backup to the desired switch, and execute the restore system command.
If the firmware file was backed up, a firmware update is also performed using that file.
When restore is completed, the system will restart.

The system information backup contains the following.

• Settings associated with the unit
  • startup-config #0 - #1 and associated information
  • startup-config select command setting values
  • boot prioritize sd command setting values
• Firmware file
  * Only if the specified folder of the SD card contained a firmware file when the backup was executed.

For this reason, when replacing a unit due to malfunction or another reason, the replacement unit can be returned to the same condition as the original unit simply by restoring the backed up system information.
Do not edit or delete the backed up system information.

4. List of related commands

The related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Unmount SD card

Unmount the SD card.

Yamaha>unmount sd

5.2 Mount SD card

Mount the SD card.

Yamaha>mount sd

5.3 Back up log file

By executing the save logging command you can back up the log file to the SD card as well.

Yamaha(config)#logging backup sd enable... (Enable SD card backup of log)
Yamaha(config)#exit
Yamaha#save logging ... (Back up log)

5.4 Saving technical support information

Save technical support information.

Yamaha#copy tech-support sd

6 Points of Caution

In rare cases, external memory can no longer be recognized after repeatedly inserting and removing the media.

The unit must be restarted to enable using the external memory again.

The following SYSLOG message is output when an error is detected.

microSD driver is dead. You must reboot the system to recover this condition.

7 Related Documentation

• Config management
• SYSLOG
• Firmware update
• Performance observation

Boot data management

1 Function Overview

As system boot information, this product manages the information shown in the table below.

System boot information: items managed

This product stores the current boot information and information on the previous four boots, for a total of five boot records.

2 Related Commands

The related commands are shown below.

For details on the commands, refer to the Command Reference.

List of related commands

3 Examples of Command Execution

3.1 Show boot information

• This shows the current boot information.

  Yamaha>show boot 0
   Running EXEC: SWX3220-16MT Rev.4.02.00  (Fri Jan  1 00:00:00 2021)
  Previous EXEC: SWX3220-16MT Rev.4.02.00  (Fri Jan  1 00:00:00 2021)
  Restart by reload command

• This shows a list of the boot history.

  Yamaha>show boot list
  No. Date       Time     Info
  --- ---------- -------- -------------------------------------------------
    0 2018/03/15 09:50:29 Restart by reload command
    1 2018/03/14 20:24:40 Power-on boot
  --- ---------- -------- -------------------------------------------------

3.2 Clear boot information

• This clears the boot information.

  Yamaha#clear boot list

4 Points of Caution

If creation of the system information storage area at startup fails, the following message is output to the serial console screen.
At this time, all logs saved in the product are deleted.

• Message list

  Message	Detection timing
  Failed to create partition.	When the system information storage area could not be created
  Succeeded to re-create partition.	When the system information storage area was successfully recreated
  Boot sequence is interrupted by partition creation failure.	When the system information storage area could not be created and the system could not start up

5 Related Documentation

None.

Viewing unit information

1 Function Overview

This product provides the following functionality that can be used to obtain product information, operating information, and so on.

• Use commands to show chassis information
• Obtain technical support information remotely
• Save technical support information on external memory

Technical support information includes a wide variety of data analysis information, including not only product information and operating information for this product, but also configuration information and process operating status information.

The functions can be used to show all information for a unit at the same time.

2 Function Details

2.1 Showing chassis information using commands

This function shows chassis information by entering a command in the console.

The following chassis information can be shown.

List of Chassis Information Shown

2.1.1 Showing product information

Product information for the main unit and SFP module can be shown using the show inventory command. Product information includes the following information.

• Name
• Description (DESCR)
• Vendor
• Product ID (PID)
• Version ID (VID)
• Serial No. (SN)

2.1.2 Showing operating information

System operating status can be shown using the show environment command. The system operating status includes the following information.

• Boot version
• Firmware revision
• Serial No.
• MAC address
• CPU usage rate
• Memory usage rate
• Fan operating status
• Fan rpm
• Firmware file
• Startup config file
• Setting the automatic SD card booting function
• Serial baud rate
• CPLD version
• Boot time
• Current time
• Elapsed time from boot
• Unit temperature status
• Unit temperature

2.1.3 Showing technical support information

Technical support information can be shown using the show tech-support command. Technical support information includes results from executing the following commands.

If stacking functionality is enabled, technical support information is shown for all devices configured in the stack.

However, the main and member switches execute different commands. For more details, see the command list below.

List of Executed Commands

*1 Not included if obtained by TFTP.

2.2 Obtaining technical support information remotely

Technical support information (output results from show tech-support) can be obtained from the product by remote access via the Web GUI or TFTP.

2.2.1 Web GUI

Use the following procedure to configure a network environment that enables remote access, so that the product can use http server functionality.

1. Decide which VLAN to use for maintenance.
2. Specify an IPv4 address for the maintenance VLAN. Use the ip address command to specify the IPv4 address.
3. Permit the maintenance VLAN to access the http server. To specify a different VLAN than for management interface command settings, use the http-server interface command.

Execute the following operations by accessing the Web GUI.

• Show technical support information on the Web GUI
  • On the [TECHINFO] menu, click the [Show in browser] button to show the show tech-support command results in a sub-window.
  • To stop showing the results, click the web browser close button.
• Obtain technical support information from the Web GUI
  • On the [TECHINFO] menu, click the [Obtain as text file] button to automatically start downloading the file.
  • The file is saved with a file name in the following format.
    • techinfo_YYYYMMDDhhmmss.txt (where “YYYYMMDDhhmmss” is the date/time the command was executed)

2.2.2 TFTP

Use the following procedure to configure a network environment that enables remote access, so that the product can use tftp server functionality.

1. Decide which VLAN to use for maintenance.
2. Specify an IPv4 address for the maintenance VLAN. Use the ip address command to specify the IPv4 address.
3. Permit access from the maintenance VLAN to the tftp server. To specify a different VLAN than for management interface command settings, use the tftp-server interface command.

If using a tftp client, specify techinfo in the remote path for obtaining technical support information.

2.3 Saving technical support information on external memory

The product can save technical support information (output results from show tech-support) on an SD memory card by using the copy tech-support sd command.

The SD card must be inserted before executing the command.

File names are saved in the following format on the SD card.

• /swx3220/techsupport/YYYYMMDDHHMMSS_techsupport.txt (where “YYYYMMDDHHMMSS” is the date/time the command was executed)

3 Related Commands

Related commands are indicated below.

For command details, refer to the command reference.

List of related commands

4 Examples of Command Execution

4.1 Showing product information

The following shows product information for the main unit and SFP module.

Yamaha>show inventory
NAME: L3 switch
DESCR: SWX3220-16MT
Vendor: Yamaha
PID: SWX3220-16MT
VID: 0000
SN: S00000000

NAME: SFP1
DESCR: 1000BASE-LX
Vendor: YAMAHA
PID: YSFP-G-LX
VID: 0000
SN: 00000000000

NAME: SFP2
DESCR: 1000BASE-SX
Vendor: YAMAHA
PID: YSFP-G-SX
VID: 0000
SN: 00000000000

4.2 Showing operating information

The following shows the system operating status.

Yamaha>show environment
SWX3220-16MT BootROM Ver.1.00
SWX3220 Rev.4.02.00 (Fri Jan  1 00:00:00 2021)
main=SWX3220-16MT ver=00 serial=S00000000 MAC-Address=00a0.de00.0000
CPU:   2%(5sec)   2%(1min)   1%(5min)    Memory:  20% used
Fan status: Normal
Fan speed: FAN1=3629RPM FAN2=3698RPM FAN3=3698RPM
Startup firmware: exec0
Startup Configuration file: config0
             selected file: config0
Boot auto-apply: Enable
Serial Baudrate: 9600
CPLD version: 10
Boot time: 2021/01/01 00:00:00 +09:00
Current time: 2021/01/02 00:00:00 +09:00
Elapsed time from boot: 1days 00:00:00
Temperature status: Normal
Temperature: 39 degree C

4.3 Showing technical support information

The following shows technical support information.

Yamaha#show tech-support
#
# Information for Yamaha Technical Support
#

*** show running-config ***
!
!  - Running Configuration -
!  Current Time:  Fri Jan 1 00:00:00 JST 2021
!
dns-client enable
!
vlan database
 vlan 2 name VLAN0002
 vlan 3 name VLAN0003
!
interface port1.1
 switchport
 switchport mode access
...

*** show startup-config ***
...

*** show stack ***
...

*** show environment ***
...

*** show disk-usage ***
...
...
...

#
# End of Information for Yamaha Technical Support
#

5 Points of Caution

• Product internal temperature errors
  • If the internal temperature in the product exceeds the threshold value, a temperature error (temperature alarm) is detected. If an internal temperature error is detected, promptly reassess the system operating environment and implement corrective measures to restore normal temperatures.
  • If a temperature error (TempAlarm) is detected, it is output as follows.
    • Example of SYSLOG output results
      

      [ FANC]:inf: Temp Alarm CPU

    • Example of operating information displayed
      

      Yamaha>show environment
      SWX3220-16MT BootROM Ver.1.00
      SWX3220 Rev.4.02.00 (Fri Jan  1 00:00:00 2021)
      ...
      ...
      Temperature status: Error (Exceeded alarm temperature CPU)

6 Related Documentation

None

System self-diagnostic

1 Function Overview

This product includes system self-diagnostic function.

The system self-diagnostic function detects the following types of errors.

• Startup process errors
• Hardware component errors
  • Interface (Ethernet port)
  • RTC
  • CPLD
  • SFP
  • Fan
• Memory error
• Temperature error

2 Definition of Terms Used

Real-time clock (RTC)

Device used to manage time

CPLD（Complex Programmable Logic Device）

A type of programmable logic device.

Packet processor

Device used to process packets.

3 Function Details

3.1 Diagnostics

Three types of system self-diagnostic functionality, either bootup diagnostics, on-demand diagnostics, or health monitoring diagnostics, are available depending on when diagnostics are performed.

The features of each type are indicated below.

• Bootup diagnostics
  • Automatically executed whenever the system starts up.
  • Detects startup process errors and hardware component errors (RTC, etc.).
• On-demand diagnostics
  • Can be executed at user-specified times set using the system-diagnostics on-demand execute command.
  • Detects hardware component errors (interface, etc.) and memory errors
  • All ports are shut down during diagnostics and the system is rebooted when finished.
• Health monitoring diagnostics
  • Running continuously in the background during system operation.
  • Detects hardware component errors (fan errors, etc.) and temperature errors
  • Health monitoring diagnostic results are displayed via the GUI and LED indicators (only some test results are indicated via the LED indicators).

Each diagnosis runs multiple tests. The tests performed for each diagnosis are indicated below.

For a detailed list of tests performed, refer to 4 Test Details.

3.2 Diagnostic results displayed

Diagnostic results can be checked using the show system-diagnostics command.

Though the system is automatically rebooted after on-demand diagnostics, diagnostic results can be confirmed after rebooting.

3.3 Deleting on-demand diagnostic results

On-demand diagnostic results can be deleted using the clear system-diagnostics on-demand command.

4 Test Details

Details about each test item are indicated below.

4.1 Loading test

This verifies the software module loading status.

A “Pass” result is output if all modules are successfully loaded, whereas a “Fail” result is output if even one module fails to load.

The show system-diagnostics command does not indicate information about modules that failed to load.

To identify which module failed to load, use the show logging command to search the following log.　Note: In this example, the module name is indicated by “XXXX” characters.

[   HAMON]:err: An unexpected error has occurred. (XXXX deamon)

4.2 RTC test

This verifies access to the RTC register.

A time value is obtained from the RTC two times, resulting in “Pass” if the time value changed or “Fail” if the time values are identical.

A “Fail” result also occurs if the test fails to obtain a time value from the RTC (or load the register).

4.3 Packet processor test

This verifies access to the packet processor register.

A “Pass” result occurs if the value written in the packet processor register matches the loaded value, whereas a “Fail” result occurs if the values do not match.

A “Fail” result also occurs if the test fails to access the register.

4.4 PHY test

This verifies access to the PHY register.

A “Pass” result occurs if the value written in the PHY register matches the loaded value, whereas a “Fail” result occurs if the values do not match.

A “Fail” result also occurs if the test fails to access the register.

4.5 CPLD test

This verifies access to the CPLD register.

A “Pass” result occurs if the value written in the CPLD register matches the loaded value, whereas a “Fail” result occurs if the values do not match.

A “Fail” result also occurs if the test fails to access the register.

4.6 Memory Test

This verifies access to the packet processor memory.

It writes and reads values at various regions of the packet processor memory and then returns a “pass” result if the read value matches the written value or a “fail” result if they do not match.

A “fail” result also occurs if memory access fails.

4.7 Thermal Test

This monitors the CPU, MAC, PHY, and SFP module temperatures.

If the temperature exceeds a threshold value, a warning is indicated.

4.8 Fan Test

This monitors the fan rpm.

It indicates a warning if the fan stops rotating or the rotation speed increases.

4.9 SFP test

This monitors the SFP module optical input level.

It generates a warning if the optical input level exceeds a certain range.

5 Related Commands

Related commands are indicated below.

For details on the commands, refer to the Command Reference.

List of related commands

6 Examples of Command Execution

6.1 Displaying system self-diagnostic results

1. Check the system self-diagnostic results as follows.

   Yamaha#show system-diagnostics 
   Test results: (P = Pass, F = Fail, U = Untested, N = Normal, W = Warning)
   
   - Bootup
     Loading Test: Pass
   
     RTC Test: Pass
   
     Packet Processor Test: Pass
   
   - On-demand
   Last on-demand diagnostics information:
    Date     : 2021/07/07 09:00:00 +09:00
    BootROM  : Ver.1.00
    Firmware : Rev.4.02.08
    CPLD     : Ver.16
    PHY      : Ver.10.5.0.0
   
     PHY Test:
       Port   1   2   3   4
       --------------------
              P   P   P   P
   
     CPLD Test: Pass
     
     Memory Test: Pass
   
   - Health monitoring
     Thermal Test:
       CPU: Normal, MAC: Normal, PHY: Normal, SFP: Normal
       
     Fan Test: Normal
     
     SFP Test:
       Port   5   6   7   8   9  10  11  12  13  14  15  16
       ----------------------------------------------------
              N   N   N   N   N   N   N   N   N   N   N   N
   

6.2 Executing on-demand diagnostics

1. Execute on-demand diagnostics as follows.

   Yamaha#system-diagnostics on-demand execute
   The system will be rebooted after diagnostics. Continue ? (y/n) y
   on-demand diagnostics completed (pass). reboot immediately...
   

6.3 Deleting on-demand diagnostic results

1. Delete on-demand diagnostic results as follows.

   Yamaha#clear system-diagnostics on-demand
   

7 Points of Caution

• All ports are automatically shut down and rebooted whenever on-demand diagnostics is executed. Therefore, use particular caution before executing on-demand diagnostics while the system is being operated.
• On-demand diagnostics are only executed if the stack status is standalone or disabled. To perform on-demand diagnostics when a stack is configured, first disconnect the connections between member switches.
• If online diagnostics is executed remotely, such as via Telnet or the web console, simplified results cannot be displayed before rebooting because all ports are shut down during diagnostics. Use the show system-diagnostics command to check diagnostic results after rebooting.

8 Related Documentation

None

Cable diagnostics

1 Function Overview

The cable diagnostic function can be used to easily check whether or not the LAN cable connected to the LAN port has a faulty connection/circuit.

It can be used to troubleshoot network problems or as an easy way to check cables when setting up networks.

2 Definition of Terms Used

TDR (Time Domain Reflector)

The TDR is used to measure the length of LAN cables or the location of damage based on the reflected signals from a pulse signal sent through the LAN cables.

3 Function Details

3.1 How to diagnose cables

The cable diagnostic function can easily diagnose LAN cables using the time domain reflection (TDR) method.

Cable diagnostics is started by executing the cable-diagnostics tdr execute interface command.

If the show cable-diagnostics tdr command is executed after the diagnostics process is finished, the following diagnostic results are displayed.

Results from executing cable diagnostics the previous time can be checked using the show cable-diagnostics tdr command.

Only the immediately previous diagnostic results are retained and then overwritten the next time the cable diagnostics command is executed again.

The immediately previous results can be deleted using the clear cable-diagnostics tdr command.

4 Related Commands

Related commands are indicated below.
For command details, refer to the command reference.

List of related commands

Operations	Operating commands
Execute cable diagnostics	cable-diagnostics tdr execute interface
Display cable diagnostics	show cable-diagnostics tdr
Clear cable diagnostic results	clear cable-diagnostics tdr

The following commands included in smart switches can be used in the same way as the commands above.

• test cable-diagnostics tdr interface
• show test cable-diagnostics tdr
• clear test cable-diagnostics tdr

5 Examples of Command Execution

5.1 Executing cable diagnostics

Diagnose of the LAN cable connected to port 1.1 as follows.

Yamaha# test cable-diagnostics tdr interface port1.1 
The port will be temporarily down during test. Continue? (y/n): y 
% To check result, enter “show cable-diagnostics tdr”

5.2 Checking previous diagnostic results

Display the previous diagnostic results as follows.

Yamaha# show test cable-diagnostics tdr
Last run on Tue May 31 18:12:13 2022
Port      Pair  Status  Fault distance
-------------------------------------------
port1.1   1     OK      -
          2     OK      -            
          3     Open    15  m       
          4     Open    15  m  

6 Points of Caution

• This function performs simplified diagnostics. Note that it cannot be used to for precision diagnosis of more specialized equipment.
• Cables 10 m or longer can be diagnosed. Cables shorter than 10 m cannot be diagnosed in some cases.
• Communication is temporarily stopped during cable diagnostics.
• Diagnostics cannot be performed if a shutdown command is specified for a corresponding port or the port is shut down either because a loop was detected or for any other reason.
• Diagnostics cannot be performed properly in some cases if the port on the opposite end is linked at a speed less than 1 Gbps.
• Diagnostics cannot be performed properly if PoE power is supplied at a corresponding port.
• If a stack is configured, commands cannot be executed from member switches in the stack.

7 Related Documentation

• None

Config management

1 Function Overview

This product uses the following config information to maintain the value of settings.

Table 1.1 Config types

2 Definition of Terms Used

None

3 Function Details

3.1 Running config

running-config is the settings that are currently operating; since it is maintained in RAM, it is destroyed at reboot.

On this product, commands executed in configuration mode are immediately applied to running-config, and the unit operates according to these settings.

The contents of running-config can be viewed by using the show running-config command.

3.2 Startup config

startup-config is settings that are saved in flash ROM or on the SD card, and the contents are preserved through reboot.

When this product is started, the settings of startup-config are applied as the initial settings of running-config.

This product can maintain two startup configs in flash ROM and one startup config on the SD card.

The startup-config data in the internal flash ROM is managed with an ID of 0–1, and the config on the SD card is managed with the keyword “sd”.

To specify which of the five types of config in the unit’s flash ROM are used, use the startup-config select command.

• By default, sd is used.
• When executing the startup-config select command, the user selects whether to restart. If you don’t restart, no change occurs in the command setting.

  If you choose to restart, the unit restarts with the startup-config of the ID specified by the user’s command.

For easier management, you can use the startup-config description command to give each config a Description (explanatory text).

If you attempt to start up in a state where startup-config does not exist, such as after executing the cold start command, the default-config is automatically applied.

The running-config settings can be saved in startup-config by the copy running-config startup-config command or the write command.

The contents of startup-config can be erased by the erase startup-config command, viewed by the show startup-config command, and copied by the copy startup-config command.

3.3 Default config

default-config contains settings saved in internal flash ROM that are needed for this product to operate minimally as a switch. Like startup-config, the contents are preserved even after a restart.

The factory settings are maintained as default-config.

If startup-config does not exist when the system starts, default-config is copied to startup-config, and applied to running-config.

The contents of default-config cannot be viewed.

3.4 Deciding the config file at startup

The following describes the flow for deciding the config file used when this product starts up.

1. The startup-config select command setting is referenced to determine the startup-config that will be used.

   If the startup-config select command has specified sd, and an SD card on which startup-config is saved is not inserted, then startup-config #0 is selected.

2. If the determined startup-config exists, the corresponding data is applied as running-config in RAM.

   If the startup-config determined according to the value of the startup-config select command does not exist in ROM, then default-config is applied to RAM.

If startup using the config in the SD card fails, the following message is shown in the console and in SYSLOG.

Loading config0 because can’t read config in SD card.

3.5 Controlling the config file via TFTP

If this product’s TFTP server function is enabled, a TFTP client installed on a PC or other remote terminal can be used to perform the following.

1. Acquire the currently running running-config and startup-config
2. Apply a previously prepared settings file as startup-config

In order for the TFTP server to function correctly, an IP address must be specified for the VLAN.

Also, specify the administrative password in the form “/PASSWORD” appended to the end of the remote path.

However, the config file cannot be obtained or specified if the default administrative password is still specified. The administrative password setting must be changed in advance.

The startup-config settings are applied as running-config after the system is restarted.

Table 3.1 Remote path for applicable files (No automatic restart)

If you want to restart the system automatically after applying the CONFIG file, specify the following remote path.
The currently running configuration is applicable.

Table 3.2 Remote path for applicable files (with automatic restart)

When applying (PUT) a CONFIG file, confirm that the target CONFIG and the type of the target file are correct.

If an incorrect file is specified, it cannot be reflected correctly.

In the case of running-config, it is necessary to add the following at the start of the CONFIG file.

!
! Switch Configuration
!

• The startup-config settings are applied as running-config when the system restarts.

4 Related Commands

The related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Select startup config

Select startup-config #1 and restart.

Yamaha#startup-config description 1 TEST ... (Assign the description “TEST” to startup-config #1)
Yamaha#startup-config select 1 ... (Select startup-config #1)
reboot system? (y/n): y  ... (Restart)

5.2 Save running config

Save running-config.

Yamaha#copy running-config startup-config
Suceeded to write configuration
Yamaha#

5.3 Copy startup config

Copy startup-config #1 to the SD card.

Yamaha#copy startup-config 1 sd  ... (Copy startup-config #1 to SD card)
Suceeded to copy configuration
Yamaha#show startup-config sd  ... (Show startup-config of SD card)
!
!  Last Modified: Tue Mar 13 17:34:02 JST 2018
!
dns-client enable
!
interface port1.1
 switchport
 switchport mode access
 no shutdown
!
...

5.4 Erase startup config

Erase startup-config from the SD card.

Yamaha#erase startup-config sd  ... (Erase startup-config of SD card)
Suceeded to erase configuration
Yamaha#

6 Points of Caution

None

7 Related Documentation

• Using external memory

Remote access control

1 Function Overview

This product lets you restrict access to the following applications that implement network services.

• TELNET server
• SSH server
• HTTP server / HTTPS server
• TFTP server
• SNMP server

2 Definition of Terms Used

None

3 Function Details

The following four functions are provided to limit access to network services.

• Control whether to leave the service in question running in the background on the system (start/stop control)
• Change reception port number
• Limit access destinations for services currently running
• Limit the source IP addresses that can access services currently running

The following functions that correspond to each network service are shown in the table below.

Network service access control

1. Multiple instances of a network service cannot be started.

   If the start control is applied to the same service that is currently running, the service will restart. Consequently, any connected sessions will be disconnected.

2. Access destinations for network services limited with respect to the VLAN interface.
3. Sources permitted to access network services can be restricted by specifying access source IP address and access permit/deny settings.
4. The default settings for the network services are shown in the table below.

   Network service	Start/stop status	Reception port number	Access destination restriction	Access source restriction
   TELNET server	run	23	Only default management VLAN (VLAN #1) permitted	Allow all
   SSH server	stop	22	Only default management VLAN (VLAN #1) permitted	Allow all
   HTTP server	run	80	Only default management VLAN (VLAN #1) permitted	Allow all
   HTTPS server	stop	443
   TFTP server	stop	69	Only default management VLAN (VLAN #1) permitted	Allow all
   SNMP server	run	161	Allow all	Allow all

4 Related Commands

Related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 TELNET server access control

This example restricts access to the TELNET server.

Change the TELNET server’s reception port to 1024.

Change the management VLAN to VLAN #1000 and allow access. Access from other than the management VLAN is denied.

Connection to the TELNET server is allowed only by clients from 192.168.100.1.

If you specify telnet-server access, access from IP addresses that do not meet the conditions is denied.

Yamaha(config)#telnet-server enable 1024 ... (Change reception port to 1024 and restart Telnet server)
Yamaha(config)#management interface vlan1000 ... (Permit access for VLAN #1000 as the maintenance VLAN)
Yamaha(config)#telnet-server access permit 192.168.100.1 ... (Permit access only from 192.168.100.1)
Yamaha(config)#end 
Yamaha#show telnet-server ... (Check state of settings)
Service:Enable
Port:1024
Management interface(vlan):1000
Interface(vlan):None
Access:
    permit 192.168.100.1
    

5.2 SSH server access control

This example restricts access to the SSH server.

Generate the SSH server host key.

Register a user name and password.

Login from an SSH client is possible only for a registered user and password.

Change the SSH server’s reception port to 1024.

Change the maintenance VLAN to VLAN #1000 and permit access to VLAN #2.

Consequently, access is only permitted from VLAN #1000 and from VLAN #2 on the maintenance VLAN.

If you specify ssh-server access, access from IP addresses that do not meet the conditions is denied.

Yamaha#ssh-server host key generate ... (Create host key)
Yamaha#show ssh-server host key ... (Check contents of key)
ssh-dss （Omit）
ssh-rsa （Omit）
Yamaha#
Yamaha#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Yamaha(config)#username user1 password pw1 ... (Register a username and password)
Yamaha(config)#ssh-server enable 1024 ... (Change reception port to 1024 and restart SSH server)
Yamaha(config)#management interface vlan1000 ... (Permit VLAN #1000 access as the maintenance VLAN)
Yamaha(config)#ssh-server interface vlan2 ... (Permit VLAN#2 access)
Yamaha(config)#end
Yamaha#show ssh-serverr ... (Check state of settings)
Service:Enable
Port:1024
Hostkey:Generated
Client alive :Disable
Management interface(vlan):1000
Interface(vlan):2
Access:None
Yamaha#

5.3 HTTP server access restrictions

This example restricts access to the HTTP server.

Change the HTTP server reception port to 8000 and permit access from VLAN #2.

That permits access only from the default maintenance VLANs VLAN #1 and VLAN #2.

Connection to the HTTP server is allowed only by clients from 192.168.100.1.

If you specify http-server access, access from IP addresses that do not meet the conditions is denied.

Yamaha(config)#http-server enable 8000 ... (Change reception port to 8000 and restart HTTP server)
Yamaha(config)#http-server interface vlan2 ... (Permit access from VLAN #2)
Yamaha(config)#http-server access permit 192.168.100.1 ... (Permit access only from 192.168.100.1)
Yamaha(config)#end 
Yamaha#show http-server ... (Check state of settings)
HTTP :Enable(8000)
HTTPS:Disable
Management interface(vlan):1
Interface(vlan):2
Access:
    permit 192.168.100.1

5.4 TFTP server access restrictions

This example restricts access to the TFTP server.

Change the TFTP server reception port to 2048 and permit access from VLAN #10.

Allow access only from the default maintenance VLANs VLAN #1 and VLAN #10.

Yamaha(config)#tftp-server enable 2048 ... (Change reception port to 2048 and restart TFTP server)
Yamaha(config)#tftp-server interface vlan10 ... (Permit access by VLAN #10)

5.5 SNMP server access restrictions

This restricts access to the SNMP server.

Access to “public” communities is restricted to clients from 192.168.100.0/24.

In addition, access to “private” communities is restricted to clients from 192.168.100.1.

Yamaha(config)#snmp-server access permit 192.168.100.0/24 community public ... (Access to communities named “public” is only allowed from 192.168.100.0/24）
Yamaha(config)#snmp-server access permit 192.168.100.1 community private ... (Access to communities named “private” is only allowed from 192.168.100.1)

6 Points of Caution

If the password (admin) for the default administrative user admin is left unchanged, then the following restrictions are applied.

• Switches cannot be accessed by TELNET, SSH, HTTP, or HTTPS from a network segment other than the maintenance VLAN.

The following restrictions apply if a TFTP server is accessed from a TFTP client.

• Access is denied if the special privileged access password (administrative password) is still set to the default setting. Special privileged access passwords (administrative passwords) must be changed in advance.
• If the primary and secondary addresses for a VLAN being accessed are the same segment, then the IPv4 secondary address cannot be accessed.
• If accessing the VLAN with an IPv6 address, then only the IPv6 address specified last can be accessed.

  Because the internal address is reset if the switch is started, that means only the bottom IPv6 address listed in the order they were configured can be accessed.

• Only the IP address of the VLAN with the closest routing to the TFTP client can be accessed.

  For example, a TFTP client located on VLAN 1 cannot access VLAN 2 IP addresses for the switch.

7 Related Documentation

• User account management

Time management

1 Function Overview

This product provides the functions shown below for managing the date and time.

• Manual (user-configured) date/time information setting function
• Automatic date/time setting information function via network
• Time zone setting function
• Function for setting “summer time” (or “daylight saving time” (DST) or “daylight time”) settings

2 Definition of Terms Used

UTC (Coordinated Universal Time)

This is an official time used when recording worldwide times.

UTC is used as a basis to determine standard time in all countries around the world.

For instance, Japan (JST, or Japan standard time) is nine hours ahead of Coordinated Universal Time, and is thus shown as “+0900 (JST)”.

SNTP (Simple Network Time Protocol)

This is a simple protocol to correct clocks by using SNTP packets.

This protocol is defined in RFC4330.

3 Function Details

3.1 Manually setting the date and time

Use the clock set command to directly enter clock setting values.

3.2 Automatically setting the date and time

Date and time information is collected from a specified time server, and set in this product.

Defined in RFC4330, SNTP (Simple Network Time Protocol) is used as a communication protocol.

Up to two time servers can be specified using either an IPv4 address, IPv6 address, or a fully qualified domain name (FQDN).

Port number 123 is used for the SNTP client. (This setting cannot be changed by the user.)

The ntpdate command can be used to select one of two methods for automatically setting date and time settings.

• One-shot update (a function to update when a command is inputted)
• Interval update (a function to update in a 1–24-hour cycle from command input)

If clock settings are synchronized with two time servers specified, queries are processed in the order they are displayed by the show ntpdate command, which is NTP server 1 and then NTP server 2.

Queries to NTP server 2 are only processed if synchronization with NTP server 1 fails.

Given default settings, one hour is specified as the interval update cycle.

However, when the default time cannot be set right after booting up the system, the time server will be queried in a one-minute cycle, regardless of the interval cycle time.

Synchronization with the time server operates with one sampling (the frequency of replies from the server) and with a timeout of 1 second.

Synchronization is blocked during command execution, and an error message is outputted if a timeout occurs.

3.3 Time zone settings

In order to manage the time for the region considered as the “base of daily life”, the “clock timezone” command is used to manage the time zone of the users, and reflect this into the time.

The time zone can be set in ±1 hour increments for Coordinated Universal Time (UTC), from -12 hours to +13 hours.

The default time zone value for this product is +9.0.

3.4 Summer time setting

Users can set “summer time” (or “daylight saving time” (DST) or “daylight time”) settings using the clock summer-time command.

The following parameter settings are specified.

• Time zone name

  The time zone name is displayed when summer time is in effect.

• Summer time starting and ending times

  The following two methods can be used to specify time setting values.

  • Recurring

    If summer time occurs every year for the same period, then this specifies the week and day of the month it occurs.

  • Specific dates

    This specifies the specific dates summer time is applied.

• Offset

  This specifies how long (minutes) to extend the summer time period.

  The setting range is from 1 to 1,440 minutes. The setting value is 60 minutes unless specified otherwise.

Overlapping summer time periods cannot be specified.

Summer time settings can be checked using the show clock detail command.

4 Related Commands

Related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Manually setting the time

In this example, the time zone is set to JST and the current time is set to 2014.01.21 15:50:59.

Yamaha#configure terminal 
Yamaha(config)#clock timezone JST … (Set time zone)
Yamaha(config)#exit
Yamaha#clock set 15:50:59 Jan 21 2014 … (Set time)
Yamaha#show clock … (Show current time)
15:50:59 JST Tue Jan 21 2014

5.2 Automatically setting the time

In this example, the time zone is set to +9.00 and the local address 192.168.1.1 and ntp.nict.jp are specified as the NTP servers.

Also, the NTP server update cycle is changed to once every 24 hours.

Yamaha#configure terminal
Yamaha(config)#clock timezone +9:00 … (Set time zone)
Yamaha(config)#ntpdate server ipv4 192.168.1.1 … (Set NTP server)
Yamaha(config)#ntpdate server name ntp.nict.jp … (Set NTP server)
Yamaha(config)#ntpdate interval 24 … (Set NTP server update cycle to 24 hours)
Yamaha(config)#exit
Yamaha#show clock … (Show current time)
10:03:20 +9:00 Mon Dec 12 2016
Yamaha#show ntpdate … (Show NTP time synchronization settings)
NTP server 1 : 192.168.100.1
NTP server 2 : ntp.nict.jp
adjust time : Mon Dec 12 10:03:15 2016 + interval 24 hours
sync server : 192.168.100.1

5.3 Summer time setting

5.3.1 Recurring

In this example, summer time is set to occur every year starting from 2 AM on the second Sunday of March to 2 AM on the first Sunday of November.

Yamaha#configure terminal
Yamaha(config)#clock summer-time JDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00 … (Set summer time settings)
Yamaha(config)#exit
Yamaha#show clock detail … (Check summer time settings)
Fri Jan  1 00:00:20 JST 2021
	
Summer Time
  Type   : Recurring
  Offset : 60 (min)
  From   : Sun Mar 14 02:00:00 JST 2021 … (Show the specific date settings for the next (or current) summer time period)
  To     : Sun Nov 7 02:00:00 JDT 2021

5.3.2 Specific dates

In this example, the settings specify starting summer time at 2 AM on March 14, 2021, and ending it on November 7, 2021.

Yamaha#configure terminal
Yamaha(config)#clock summer-time JDT date Mar 14 2021 2:00 Nov 7 2021 2:00 … (Set summer time settings)
Yamaha(config)#exit
Yamaha#show clock detail … (Check summer time settings)
Fri Jan  1 00:02:54 JST 2021
			
Summer Time
  Type   : Date
  Offset : 60 (min)
  From   : Sun Mar 14 02:00:00 JST 2021
  To     : Sun Nov 7 02:00:00 JDT 2021

6 Points of Caution

None

7 Related Documentation

• RFC 4330: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

SNMP

1 Function Overview

Setting SNMP (Simple Network Management Protocol) makes it possible to monitor and change network management information for SNMP management software.

In this instance, this product will operate as an SNMP agent.

This product supports communication using SNMPv1, SNMPv2c, and SNMPv3. In terms of management information bases (MIB), it supports RFC1213 (MIB-II) and private MIBs (Yamaha switches).

SNMPv1 and SNMPv2 protocols send notification of the group name (referred to as a “community”) to recipients and only communicate between hosts that belong to that same community. In that case, different community names can be specified for two access modes, either the read-only or read-write mode.

In this way, community names function as a kind of password, but they carry inherent security risks because they must be sent over a network using plain text. The use of SNMPv3 is recommended when more secure communications are required.

SNMPv3 offers communication content authentication and encryption. SNMPv3 improves security by eliminating the concept of community and instead using so-called “security models”, including the user-based security model (USM) and view-based access control model (VACM).

SNMP messages that notify the status of this product are called “traps.” This product transmits standard SNMP traps. In SNMPv1, trap requests that do not ask for an answer with the confirmation of receipt from the recipient are specified as the notification message format. However, with SNMPv2c and SNMPv3, either an “inform” request asking for an answer from the recipient, or a trap request can be selected.

Since this product does not specifically specify a default community name value for read-only and transmission traps used for SNMPv1 and SNMPv2c protocols, be sure to specify an appropriate community name. However, as described above, community names are sent over the network in plain text, so be careful to never use a login password or administrator password as the community name.

By default, no access is possible in each SNMP version. The transmission host for the trap is not set, so traps will not be sent anywhere.

This product can restrict access to the SNMP server. Specifying access restrictions can restrict access from unintended hosts.

2 Definition of Terms Used

None

3 Function Details

The main characteristics of each SNMP version and the router setting policies are explained below.

For specific examples of settings, see 5 Examples of Command Execution below.

3.1 SNMPv1

Community names are used for authentication between the SNMP manager and agents.

Switches managed by SNMPv1 are managed by dividing them into zones, referred to as “communities”.

• Accessing the MIB objects

  Community names specified using the snmp-server community command are used to permit access.

  Access is possible from a VLAN interface whose IP address has been specified.

• SNMP traps

  The status of switches can be sent to hosts specified using the snmp-server host command.

  The snmp-server enable trap command is used to specify the kind of trap to send.

  The snmp-server startup-trap-delay command is used to specify when to send the trap during startup.

3.2 SNMPv2c

As with SNMPv1, community names are used for authentication between the SNMP manager and agents.

The snmp-server community command is used to specify the community names used to access switches by SNMPv2c.

The “GetBulk” and “Inform” requests are also now supported from this version.

These requests are used to efficiently retrieve multiple MIB objects, and to confirm replies to notification packets sent from this product.

• Accessing the MIB objects

  Community names specified using the snmp-server community command are used to permit access.

  Access is possible from a VLAN interface whose IP address has been specified.

• SNMP traps

  The status of switches can be sent to hosts specified using the snmp-server host command.

  Also, the settings of this command can be used to select whether the transmitted message format is a trap or inform request.

  Inform requests are used to request confirmation of reply to the recipient.

  The snmp-server startup-trap-delay command is used to specify when to send the trap during startup.

3.3 SNMPv3

SNMPv3 offers all the functionality of SNMPv2, but with more robust security functions.

SNMPv3 can authenticate and encrypt SNMP packets sent across the network to protect packets from eavesdropping, spoofing, falsification, replay attacks, and other risks and achieve security levels not possible with SNMPv1 or SNMPv2C functionality, such as community names or SNMP manager IP addresses.

• Security

  SNMPv3 offers the following security functionality.

  1. USM (User-based Security Model)

     USM is a model for maintaining security at the message level. It offers authentication and encryption based on shared key cryptography and prevents falsification of message streams.

     • Security level

       The security level can be specified using the parameter settings for the group to which users belong.

       Security levels are classified based on a combination of authentication and encryption, as indicated below.

       • noAuthNoPriv: no authentication and encryption
       • AuthNoPriv: authentication only
       • AuthPriv: authentication and encryption
     • User authentication

       For authentication, HMAC is used in the procedure to authenticate the integrity (whether data has been falsified or not) and the source.

       A hash is used in the authentication key to confirm whether the message has been falsified, and whether the sender is the user themselves.

       Both HMAC-MD5-96 and HMAC-SHA-96 are supported as hash algorithms.

     • Encryption

       With SNMPv3, SNMP messages are encrypted for the purpose of preventing leakage of managed information.

       Both the DES-CBC and AES128-CFB encryption schemes are supported.

       The snmp-server user command can be used to specify usernames, corresponding group names, user authentication methods, and encryption methods.

       The necessary authentication and encryption settings can be made according to the security level specified in the group settings.

  2. VACM (View-based Access Control Model)

     VACM is a model for controlling access to SNMP messages.

     • Group

       With VACM, the access policies mentioned below are defined per group, not per user.

       Use the snmp-server user command with the optional “group” setting to specify user group affiliation. The MIB views set here that are accessible to the specified groups can be configured.

     • MIB view

       With SNMPv3, a collection of accessible MIB objects can be defined for each group. When defined, the collection of MIB objects is called the “MIB view”. The “MIB view” is expressed as a collected view sub-tree that shows the object ID tree.

       Use the snmp-server view command to specify the MIB view. Whether the MIB view should be included or excluded in each view sub-tree can be selected.

     • Access policies

       With VACM, set the MIB view that will permit reading and writing for each group.

       Use the snmp-server group command to set the group name, security level, and MIB view.

       The MIB view is the MIB view specified using the snmp-server view command.

• SNMP traps

  The status of switches can be sent to hosts specified using the snmp-server host command.

  In order to transmit a trap, the snmp-server user command must first be used to configure the user.

  Also, the settings of this command can be used to select whether the transmitted message format is a trap or inform request.

  Inform requests are used to request confirmation of reply to the recipient.

  The snmp-server startup-trap-delay command is used to specify when to send the trap during startup.

3.4 Restricting SNMP server access

Hosts able to access the product’s SNMP server can be specified using the snmp-server access command.

Access from unintended hosts can be restricted by only allowing access from the intended SNMP manager.

Default settings accept access from all hosts. Specify access restrictions based on the operating environment.

For more details about access restrictions, refer to Remote access control.

3.5 Private MIB

This product supports yamahaSW, which is a proprietary private MIB for switch management.

This private MIB allows the obtaining of information for Yamaha’s proprietary functions, and for more detailed information about the switch.

For information about supported private MIBs and how to obtain private MIBs, refer to the following SNMP MIB reference.

• SNMP MIB Reference

4 Related Commands

Related commands are indicated below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 SNMPv1 setting example

This example makes SNMPv1-based network monitoring possible under the following conditions.

1. Set the read-only community name “public.”
2. Set the trap destination as “192.168.100.11”, and set trap community name to “snmptrapname”.
3. Hosts that can access communities named “public” are restricted to only 192.168.100.0/24.

   Yamaha(config)# snmp-server community public ro                  　          ... 1
   Yamaha(config)# snmp-server host 192.168.100.11 traps version 1 snmptrapname ... 2
   Yamaha(config)# snmp-server access permit 192.168.100.0/24 community public  ... 3
   

5.2 SNMPv2c setting example

This example makes SNMPv2c-based network monitoring possible under the following conditions.

1. Set the community name that enables reading/writing “private.”
2. Specify the notification message destination as “192.168.100.12”, the notification type as “inform” request format, and the notification destination community name as “snmpinformsname”.
3. Hosts that can access communities named “private” are restricted to only 192.168.100.12.

   Yamaha(config)# snmp-server community private rw                  　               ...1
   Yamaha(config)# snmp-server host 192.168.100.12 informs version 2c snmpinformsname ...2
   Yamaha(config)# snmp-server access permit 192.168.100.12 community private         ...3
   

5.3 SNMPv3 setting example

This example makes SNMPv3-based network monitoring possible under the following conditions.

1. Specify the view that shows the internet node (1.3.6.1) and below as “most”.
2. Specify the view that shows the mib-2 node (1.3.6.1.2.1) and below as “standard”.
3. Create the user group “admins” and assign full access rights to the “most” view for all users in the “admins” group.
4. Create the user group “users” and assign read-only access rights for the “standard” view to users in the “users” group.
5. Create an “admin1” user that belongs to the “admins” group.

   Set the password to “passwd1234”, using the “HMAC-SHA-96” authentication algorithm.

   Set the encryption password to “passwd1234”, using the “AES128-CFB” encryption algorithm.

6. Create an “user1” user that belongs to the “users” group.

   Set the password to “passwd5678”, using the “HMAC-SHA-96” authentication algorithm.

7. Send notifications in trap format (without response confirmation) to 192.168.10.3.
8. Send notifications in inform request format to 192.168.20.3.

Yamaha(config)# snmp-server view most 1.3.6.1 include                                  ... 1
Yamaha(config)# snmp-server view standard 1.3.6.1.2.1 include                          ... 2
Yamaha(config)# snmp-server group admins priv read most write most                     ... 3
Yamaha(config)# snmp-server group users auth read standard                             ... 4
Yamaha(config)# snmp-server user admin1 admins auth sha passwd1234 priv aes passwd1234 ... 5
Yamaha(config)# snmp-server user user1 users auth sha passwd5678                       ... 6
Yamaha(config)# snmp-server host 192.168.10.13 traps version 3 priv admin1             ... 7
Yamaha(config)# snmp-server host 192.168.20.13 informs version 3 priv admin1           ... 8

6 Points of Caution

• Check the SNMP version that can be used with the SNMP manager beforehand. It is necessary to configure this product in accordance with the SNMP version that will be used.
• This product is not compatible with the following functions related to SNMPv3.
  • Proxy function
  • Access to MIB objects after the SNMPv2 subtree (1.3.6.1.6). Changing SNMPv3-related settings via SNMP is also not supported.
• Character string specifications for the community name, username, password, and group name are as follows.
  • The character string indicated enclosed in single or double quotation marks is used.
    • Cases with characters located outside single or double quotation marks are not supported.
    • If a character string is enclosed in single or double quotation marks, the single or double quotation marks on both ends are not included in the character count.
    • The group name is assigned to the character string used with the snmp-server user command.
      • It is not assigned to the character string used with the snmp-server group command.
  • The use of \ is not supported.
  • The use of only single/double quotation marks is not supported.
• SNMP server access restrictions specified using the snmp-server access command only apply to SNMPv1 and SNMPv2c access. They do not apply to SNMPv3 access.

7 Related Documentation

• Yamaha rtpro Private MIB
• SNMP MIB Reference

RMON

1 Function Overview

By making settings for the RMON (Remote network MONitering) function, you can monitor and record the traffic volume and error occurrences for each interface.

Since the settings for the RMON function and the data obtained by the RMON function are held as an MIB, they can be retrieved and edited from the SNMP manager.

The RMON function of this product supports the following groups defined in RFC2819.

• Ethernet statistics group
• History group
• Alarm group
• Event group

2 Definition of Terms Used

RMON MIB

MIB for the RMON function, defined in RFC2819

Ethernet statistics group

MIB group defined as group 1 of the RMON MIB.

This holds a table for monitoring Ethernet statistical information.

The information in the table includes counters for the number of packets, the number of errors, etc.

The etherStatsTable is the applicable MIB for this product.

History group

MIB group defined as group 2 of the RMON MIB.

At a specified interval, it measures the same information as the Ethernet statistical information group, and has a table for saving the history of this information.

The MIBs relevant for this product are the historyControlTable and the etherHistoryTable.

Alarm group

MIB group defined as group 3 of the RMON MIB.

At the specified interval, the statistical information of the Ethernet statistical information group is compared with the threshold values.

If the sampled values exceed the threshold values, the event defined for the event group is generated.

The alarmTable is the applicable MIB for this product.

Event group

MIB group defined as group 9 of the RMON MIB.

This is the action taken in response when the alarm group conditions are met.

The eventTable is the applicable MIB for this product.

3 Function Details

The operating specifications for operation of the RMON function are shown below.

3.1 Common between groups

The specifications common between groups are given below.

1. In order to enable the RMON function on this product, the system-wide RMON function must be enabled.
   • Use the rmon command to make settings.
   • This is enabled by default.
   • You can also set this by using the private MIB ysrmonSetting(1.3.6.1.4.1.1182.3.7.1).

3.2 Ethernet statistics group

The operating specifications for the Ethernet statistics group are given below.

1. Make settings by using the rmon statistics command on an interface.
2. Starting at the point at which you specified the rmon statistics command, statistical information is collected, and the etherStatsTable of the RMON MIB will be available for retrieval.
3. This can be specified for a physical interface.
4. A maximum of eight rmon statistics commands can be specified for the same interface.
5. If an rmon statistics command is deleted, the collected statistical information is also deleted.
6. If an rmon statistics command is overwritten, the previously collected statistical information is deleted, and collection is started once again.
7. If the RMON function is disabled system-wide, collection of statistical information is halted.

   If the RMON function is subsequently enabled system-wide, the previously collected statistical information is deleted, and collection is started once again.

8. The supported OIDs in the Ethernet statistical information group are as follows.

 rmon(1.3.6.1.2.1.16)
  +- statistics(1.3.6.1.2.1.16.1)
      +- etherStatsTable(1.3.6.1.2.1.16.1.1)
              + etherStatsEntry(1.3.6.1.2.1.16.1.1.1) { etherStatsIndex }
                  +- etherStatsIndex(1.3.6.1.2.1.16.1.1.1.1)         (read-only)
                  +- etherStatsDataSource(1.3.6.1.2.1.16.1.1.1.2)    (read-create)
                  |     Interface being monitored
                  +- etherStatsDropEvents(1.3.6.1.2.1.16.1.1.1.3)    (read-only)
                  |     Number of packets dropped
                  +- etherStatsOctets(1.3.6.1.2.1.16.1.1.1.4)        (read-only)
                  |     Number of octets received
                  +- etherStatsPkts(1.3.6.1.2.1.16.1.1.1.5)          (read-only)
                  |     Number of packets received
                  +- etherStatsBroadcastPkts(1.3.6.1.2.1.16.1.1.1.6) (read-only)
                  |     Number of broadcast packets received
                  +- etherStatsMulticastPkts(1.3.6.1.2.1.16.1.1.1.7) (read-only)
                  |     Number of multicast packets received
                  +- etherStatsCRCAlignErrors(1.3.6.1.2.1.16.1.1.1.8)(read-only)
                  |     Number of FCS error packets received
                  +- etherStatsUndersizePkts(1.3.6.1.2.1.16.1.1.1.9) (read-only)
                  |     Number of undersize packets received (packets smaller than 64 octets) 
                  +- etherStatsOversizePkts(1.3.6.1.2.1.16.1.1.1.10) (read-only)
                  |     Number of oversize packets received (packets larger than 1518 octets) 
                  +- etherStatsFragments(1.3.6.1.2.1.16.1.1.1.11)    (read-only)
                  |     Number of fragment packets received (packets smaller than 64 octets with abnormal FCS)
                  +- etherStatsJabbers(1.3.6.1.2.1.16.1.1.1.12)      (read-only)
                  |     Number of jabber packets received (packets larger than 1518 octets with abnormal FCS)
                  +- etherStatsCollisions(1.3.6.1.2.1.16.1.1.1.13)   (read-only)
                  |     Number of collisions
                  +- etherStatsOwner(1.3.6.1.2.1.16.1.1.1.20)        (read-create)
                  |     Name of owner
                  +- etherStatsStatus(1.3.6.1.2.1.16.1.1.1.21)       (read-create)
                        Status of statistical group

3.3 History group

The operating specifications for the history group are shown below.

1. Make settings by using the rmon history command on an interface.
2. Starting at the point at which you specified the rmon history command, historical information is collected, and the etherHistoryTable of the RMON MIB will be available for retrieval.
3. This can be specified for a physical interface.
4. A maximum of eight rmon history commands can be specified for the same interface.
5. If an rmon history command is deleted, the collected historical information is also deleted.
6. If an rmon history command is overwritten, the previously collected historical information is deleted, and collection is started once again.
7. If the RMON function is disabled system-wide, collection of historical information is halted.

   If the RMON function is subsequently enabled system-wide, the previously collected historical information is deleted, and collection is started once again.

8. The supported OIDs in the Ethernet history group are as follows.

 rmon(1.3.6.1.2.1.16)
  +- history(1.3.6.1.2.1.16.2)
      +- historyControlTable(1.3.6.1.2.1.16.2.1)
      |       + historyControlEntry(1.3.6.1.2.1.16.2.1.1) { historyControlIndex }
      |           +- historyControlIndex(1.3.6.1.2.1.16.2.1.1.1)           (read-only)
      |           +- historyControlDataSource(1.3.6.1.2.1.16.2.1.1.2)      (read-create)
      |           |     Interface being monitored
      |           +- historyControlBucketsRequested(1.3.6.1.2.1.16.2.1.1.3)(read-create)
      |           |     Number of history group history saves requested
      |           +- historyControlBucketsGranted(1.3.6.1.2.1.16.2.1.1.4)  (read-only)
      |           |     Number of history group histories saved
      |           +- historyControlInterval(1.3.6.1.2.1.16.2.1.1.5)        (read-create)
      |           |     Interval at which history group histories are saved
      |           +- historyControlOwner(1.3.6.1.2.1.16.2.1.1.6)           (read-create)
      |           |     Name of owner
      |           +- historyControlStatus(1.3.6.1.2.1.16.2.1.1.7)          (read-create)
      |                 History group status
      |
      +- etherHistoryTable(1.3.6.1.2.1.16.2.2)
              + etherHistoryEntry(1.3.6.1.2.1.16.2.2.1) { etherHistoryIndex, etherHistorySampleIndex }
                  +- etherHistoryIndex(1.3.6.1.2.1.16.2.2.1.1)         (read-only)
                  +- etherHistorySampleIndex(1.3.6.1.2.1.16.2.2.1.2)   (read-only)
                  +- etherHistoryIntervalStart(1.3.6.1.2.1.16.2.2.1.3) (read-only)
                  |     Interval at which history group histories are saved
                  +- etherHistoryDropEvents(1.3.6.1.2.1.16.2.2.1.4)    (read-only)
                  |     Number of packets dropped
                  +- etherHistoryOctets(1.3.6.1.2.1.16.2.2.1.5)        (read-only)
                  |     Number of octets received
                  +- etherHistoryPkts(1.3.6.1.2.1.16.2.2.1.6)          (read-only)
                  |     Number of packets received
                  +- etherHistoryBroadcastPkts(1.3.6.1.2.1.16.2.2.1.7) (read-only)
                  |     Number of broadcast packets received
                  +- etherHistoryMulticastPkts(1.3.6.1.2.1.16.2.2.1.8) (read-only)
                  |     Number of multicast packets received
                  +- etherHistoryCRCAlignErrors(1.3.6.1.2.1.16.2.2.1.9)(read-only)
                  |     Number of FCS error packets received
                  +- etherHistoryUndersizePkts(1.3.6.1.2.1.16.2.2.1.10)(read-only)
                  |     Number of undersize packets received (packets smaller than 64 octets) 
                  +- etherHistoryOversizePkts(1.3.6.1.2.1.16.2.2.1.11) (read-only)
                  |     Number of oversize packets received (packets larger than 1518 octets) 
                  +- etherHistoryFragments(1.3.6.1.2.1.16.2.2.1.12)    (read-only)
                  |     Number of fragment packets received (packets smaller than 64 octets with abnormal FCS)
                  +- etherHistoryJabbers(1.3.6.1.2.1.16.2.2.1.13)      (read-only)
                  |     Number of jabber packets received (packets larger than 1518 octets with abnormal FCS)
                  +- etherHistoryCollisions(1.3.6.1.2.1.16.2.2.1.14)   (read-only)
                  |     Number of collisions
                  +- etherHistoryUtilization(1.3.6.1.2.1.16.2.2.1.15)  (read-only)
                        Estimated value of network usage ratio

3.4 Alarm group

The operating specifications for the alarm group are shown below.

1. Use the rmon alarm command to make settings.
2. From the point that the rmon alarm command is specified, sampling occurs at the specified interval.
3. If an rmon alarm command is overwritten, the previous sampling data is deleted, and sampling is started once again.
4. If the RMON function is disabled system-wide, sampling is halted.

   If the RMON function is subsequently enabled system-wide, the previous sampling data is deleted, and sampling is started once again.

5. Only etherStatsEntry(.1.3.6.1.2.1.16.1.1.1) MIB objects that have a counter type can be specified as the object of alarm group monitoring.
6. If the Ethernet statistical information group used by the rmon alarm command is deleted, the rmon alarm command is also deleted.
7. If the event group used by the rmon alarm command is deleted, the rmon alarm command is also deleted.
8. The supported OIDs in the alarm group are as follows.

 rmon(1.3.6.1.2.1.16)
  +- alarm(1.3.6.1.2.1.16.3)
      +- alarmTable(1.3.6.1.2.1.16.3.1)
              + alarmEntry(1.3.6.1.2.1.16.3.1.1) { alarmIndex }
                  +- alarmIndex(1.3.6.1.2.1.16.3.1.1.1)              (read-only)
                  +- alarmInterval(1.3.6.1.2.1.16.3.1.1.2)           (read-create)
                  |     Sampling interval
                  +- alarmVariable(1.3.6.1.2.1.16.3.1.1.3)           (read-create)
                  |     MIB object to be monitored
                  +- alarmSampleType(1.3.6.1.2.1.16.3.1.1.4)         (read-create)
                  |     Sampling type
                  +- alarmValue(1.3.6.1.2.1.16.3.1.1.5)              (read-only)
                  |     Estimated value
                  +- alarmStartupAlarm(1.3.6.1.2.1.16.3.1.1.6)       (read-create)
                  |     Threshold value used for first alarm determination
                  +- alarmRisingThreshold(1.3.6.1.2.1.16.3.1.1.7)    (read-create)
                  |     Upper threshold value
                  +- alarmFallingThreshold(1.3.6.1.2.1.16.3.1.1.8)   (read-create)
                  |     Lower threshold value
                  +- alarmRisingEventIndex(1.3.6.1.2.1.16.3.1.1.9)   (read-create)
                  |     Event index when crossing upper limit
                  +- alarmFallingEventIndex(1.3.6.1.2.1.16.3.1.1.10) (read-create)
                  |     Event index when crossing lower limit
                  +- alarmOwner(1.3.6.1.2.1.16.3.1.1.11)             (read-create)
                  |     Name of owner
                  +- alarmStatus(1.3.6.1.2.1.16.3.1.1.12)            (read-create)
                        Alarm group status

Alarm detection is determined by an upper threshold value and a lower threshold value. If the threshold value is crossed, the specified event is executed.

If an alarm is detected, the alarm will not be detected again until the value crosses the opposite threshold.

The following cases are explained as examples.

• At point 1, the upper threshold value is crossed, so an alarm is detected.

  The threshold value that is used for the very first decision can be specified by STARTUP.

  In the example above, we will assume that the STARTUP value is “1” (using only the upper threshold value (risingAlarm)) or “3” (using both the upper threshold value and the lower threshold value (risingOrFallingAlarm)).

• At point 2, an alarm is not detected.
• At point 3, the upper threshold value is crossed, but since the opposite threshold was not previously crossed, an alarm is not detected.
• At point 4, the lower threshold value is crossed, and since the upper threshold was previously crossed, an alarm is detected.
• At point 5, the lower threshold value is exceeded, but since the opposite upper threshold was not previously crossed, an alarm is not detected.
• At point 6, the upper threshold value is crossed, and since the lower threshold was previously crossed, an alarm is detected.

3.5 Event group

The operating specifications for the event group are shown below.

1. Use the rmon event command to make settings.
2. The following operations can be specified for the event group.
   • Record to log
   • Send SNMP trap
   • Record to log and send SNMP trap
3. If trap transmission is specified, the following SNMP commands must be set in order to transmit the SNMP trap.
   • snmp-server host
   • snmp-server enable trap rmon
4. The following operations will be carried out when specifying trap transmission.
   • SNMPv1, SNMPv2c
     • Only the traps for which the community name specified using the rmon event command, and for which the community name specified by the snmp-server host host command are matching will be transmitted.
   • SNMPv3
     • Only the traps for which the community name specified using the rmon event command, and for which the user name specified by the snmp-server host host command are matching will be transmitted.
       
       
5. The supported OIDs in the event group are as follows.

    rmon(1.3.6.1.2.1.16)
     +- event(1.3.6.1.2.1.16.9)
         +- eventTable(1.3.6.1.2.1.16.9.1)
                 + eventEntry(1.3.6.1.2.1.16.9.1.1) { eventIndex }
                     +- eventIndex(1.3.6.1.2.1.16.9.1.1.1)        (read-only)
                     +- eventDescription(1.3.6.1.2.1.16.9.1.1.2)  (read-create)
                     |     Event description
                     +- eventType(1.3.6.1.2.1.16.9.1.1.3)         (read-create)
                     |     Event type
                     +- eventCommunity(1.3.6.1.2.1.16.9.1.1.4)    (read-create)
                     |     Community name
                     +- eventLastTimeSent(1.3.6.1.2.1.16.9.1.1.5) (read-only)
                     |     Event execution time
                     +- eventOwner(1.3.6.1.2.1.16.9.1.1.6)        (read-create)
                     |     Name of owner
                     +- eventStatus(1.3.6.1.2.1.16.9.1.1.7)       (read-create)
                           Event group status

3.6 Setting by SetRequest from an SNMP manager

The same content as the commands of each group can be specified by using SetRequest from an SNMP manager.

The procedure for making settings from an SNMP manager is as follows.

As an example, we explain how to make new settings for the Ethernet statistics information (etherStatsTable) group to port1.1 using index number 1.

Similar operations can be used to make settings for a supported MIB on other groups.

1. Make SNMP settings to allow the MIB to be written.

   For details, refer to the SNMP technical reference.

2. For etherStatsStatus.1, specify “2” (createRequest).

   The “.1” of etherStatsStatus.1 is the etherStatsTable index.

3. For etherStatsDataSource.1, specify iFindex.5001 as the interface to be monitored.

   ifIndex.5001 indicates port1.1.

4. Specifying “owner” is optional, but if you do, specify the text string in etherStatsOwner.1.
5. For etherStatsStatus, specify “1” (valid).

When you perform the above steps, the following commands are specified for port1.1.

We assume that “RMON” was set as the “owner” setting.

 rmon statistics 1 owner RMON

Below we show how to disable the RMON function system-wide from the SNMP manager.

1. Make SNMP settings to allow the MIB to be written.

   For details, refer to the SNMP technical reference.

2. For ysrmonSetting(1.3.6.1.4.1.1182.3.7.1), specify “2” (disabled).

When you perform the above steps, the following commands are specified.

 rmon disable

To specify enable, set ysrmonSetting(1.3.6.1.4.1.1182.3.7.1) to “1” (enabled).

4 Related Commands

Related commands are shown below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Set Ethernet statistical information group

Make Ethernet statistical information group settings for port 1.1, and from the SNMP manager, retrieve the MIB of the Ethernet statistical information group.

1. Enable the Ethernet statistical information group setting for port1.1.

   The index of the Ethernet statistical information group is “1.”

   Yamaha(config)#interface port1.1
   Yamaha(config-if)#rmon statistics 1 ... (Enable the Ethernet statistical information group setting)

2. From the SNMP manager, make SNMP settings that the MIB of the Ethernet statistical information group can be retrieved.

   In this example, we use “private” access on SNMPv1 or SNMPv2c.

   Yamaha(config)#snmp-server community private rw ... (Set the readable/writable community name as “private”)

3. From the SNMP manger, it will be possible to retrieve the etherStatsTable(.1.3.6.1.2.1.16.1.1) with the community name “private.”

5.2 Set history group

Make settings for the history group of port1.1 and retrieve the MIB of the history group from the SNMP manager.

1. Enable the port1.1 history group setting.

   The index of the history group is “1.”

   Yamaha(config)#interface port1.1
   Yamaha(config-if)#rmon history 1 ... (Enable the history group setting)

2. From the SNMP manager, make SNMP settings that the MIB of the history group can be retrieved.

   In this example, we use “private” access on SNMPv1 or SNMPv2c.

   Yamaha(config)#snmp-server community private rw ... (Set the readable/writable community name as “private”)

3. From the SNMP manger, it will be possible to retrieve the etherHistoryTable(.1.3.6.1.2.1.16.2.2) with the community name “private.”

5.3 Set alarm event group

Use the alarm group to monitor the statistical information values of the Ethernet statistical information group.

The conditions for monitoring are as follows.

• The MIB to be monitored is port1.1’s etherStatsPkts(.1.3.6.1.2.1.16.1.1.1.5).
• The sampling interval is 180 seconds.
• The sampling type is delta.
• The upper threshold value is 2000.
• The lower threshold value is 1000.

When the above monitoring conditions are matched, the following event group is executed.

• Record to log and send SNMP trap
• Community name is “RMON”

1. Make the required settings for SNMP trap transmission.

   Yamaha(config)#snmp-server host 192.168.100.3 traps version 2c RMON ... (Set trap transmission destination)
   Yamaha(config)#snmp-server enable trap rmon                         ... (Enable trap transmission for the RMON function)

2. Make event group settings.

   The index of the event group is “1.”

   Yamaha(config)#rmon event 1 log-trap RMON ... (Enable the event group setting)

3. In order to set the alarm group’s monitoring target MIB object, enable the port1.1 Ethernet statistical information group setting.

   The index of the Ethernet statistical information group is “1.”

   Yamaha(config)#interface port1.1
   Yamaha(config-if)#rmon statistics 1 ... (Enable the Ethernet statistical information group setting)

4. Set the alarm group with the listed conditions.

   The index of the alarm group is “1.”

   Yamaha(config)#rmon alarm 1 etherStatsPkts.1 interval 180 delta rising-threshold 3000 event 1 falling-threshold 2000 event 1  ... (Enable the alarm group)

6 Points of Caution

None

7 Related Documentation

• SNMP

SYSLOG

1 Function Overview

This product provides the SYSLOG functions shown below as a means to ascertain the operating state.

1. Functions to collect, reference, and delete the log that is accumulated inside this product
2. Functions for output to the console simultaneously with logging
3. Functions for transmitting to a previously-registered notification destination (SYSLOG server) simultaneously with logging

Logging, output to console, and notifications to the SYSLOG server are performed according to the output level specified by the user. Processing occurs only for the permitted messages.

Logging occurs in RAM, and is automatically backed up to flash ROM or can be backed up manually.

When backing up manually, you can also back up to an SD card at the same time.

Notifications to the SYSLOG server are done simultaneously with logging, but only if a SYSLOG server has been registered.

2 Definition of Terms Used

None

3 Function Details

The SYSLOG function is described below.

1. Logging occurs in RAM, and can accumulate up to 10,000 items.

   Backup to Flash ROM can be performed by the following means.

   • Automatic backup performed every hour since system boot
   • Manual backup performed by the save logging command
   • Backup performed when the write command is executed successfully
2. The accumulated log can be viewed by the show logging command.

   It can also be deleted by the clear logging command.

   The show logging command shows the information in RAM.

   For the log information of this product, it is assumed that the information in RAM always matches the information in flash ROM.

   (When the system starts, the log information in flash ROM is applied to RAM, and the service is started. The log information in RAM is not deleted following execution of a backup.)

3. Log transmission occurs only if the notification destination (SYSLOG server) has been registered.

   You can use the logging host command to register up to two notification destinations.

   Specify the notification destination either by IP address or FQDN.

   As the port number of the notification destination, the default port number 514 is used. (This setting cannot be freely set by the user.)

   Logging facility values included in log notifications can be set using the logging facility command. The factory default setting is local0(16).

   The logging format command can be used to change the format of log notifications to not include the header portion (time stamp and host name). The following are log examples.

   • Without the format specified (no logging format)

     <134>Jan  1 00:00:00 Yamaha [     IMI]:inf: Configuration file is saved in “config0” 

   • With the format specified (logging format legacy)

     <134>[     IMI]:inf: Configuration file is saved in “config0” 

4. The level of log that is transmitted (SYSLOG priority) can be set using the logging trap command.

   This product allows you to enable or disable output for each level of log.

   With the factory settings, the output level enables only Information and Error.

5. The logging backup sd command enables SYSLOG backup to the SD card.

   If SYSLOG backup to the SD card is enabled, executing the save logging command will save the dated log file to the SD card.

4. List of related commands

Related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Settings

1. Enables debug-level log output and starts log output to the SYSLOG server (192.168.1.100) with a facility value of 10.

   Yamaha(config)# logging trap debug         … (Enable debug level log output)
   Yamaha(config)# logging facility 10        … (Sets the facility value to 10)
   Yamaha(config)# logging host 192.168.1.100 … (Register SYSLOG server)
   Yamaha(config)# logging stdout info        … (Output informational-level log to the console)

2. Stop notifications to the SYSLOG server.

   Yamaha(config)# no logging host

3. Save and show the accumulated log information.

   Yamaha# save logging … (Save log from RAM to ROM)
   Yamaha# show logging … (Show accumulated log)
   2018/03/08 20:42:46: [ SESSION]:inf: Login succeeded as (noname) for HTTP: 192.168.1.40
   2018/03/09 10:06:42: [     NSM]:inf: Interface port1.11 changed state to down
   2018/03/09 10:09:48: [ SESSION]:inf: Logout timer expired as (noname) from HTTP: 192.168.1.40
   2018/03/09 16:19:36: [     NSM]:inf: Interface port1.17 changed state to up
    :

4. Clear the accumulated log information.

   Yamaha# clear logging … (Clear all accumulated logs)
   Yamaha# show logging  … (Show log)
    (Since they were cleared, nothing is shown)

6 Points of Caution

None

7 Related Documentation

None

Firmware update

1 Function Overview

This product offers the following three firmware update functions, in order to correct problems in the program and to add new functionality.

1. Firmware updates can be transmitted and applied to this product from a remote terminal such as a PC.
2. This product’s built-in HTTP client can access an HTTP server, to download and apply the latest firmware.
3. A firmware update placed on the SD card can be applied to this product.

These update functions can be used to upgrade or downgrade the version of firmware used on this product.

During firmware updating, all port LEDs flash green, regardless of the LED display mode setting.

When a stack is configured, the updated firmware is written simultaneously to the stack main and members switches.

When successfully finished writing the updated firmware, the system is automatically rebooted in order to apply the new firmware.

For instructions on how to specify rebooting the system, refer to 3.4 Reboot After Writing.

2 Definition of Terms Used

None

3 Function Details

3.1 Update by transmitting the firmware update

This function transmits firmware updates to this product from a remote terminal, such as a PC, and applies it as boot firmware.

The update process is executed using a TFTP client or the Web GUI.

3.1.1 Using a TFTP client to update the firmware

Firmware can be updated by using a TFTP client installed on a computer or other remote terminal to transmit the updated firmware to this device.

In order to operate this product’s TFTP server, use the steps shown below to set up a network environment that allows remote access.

1. Decide on the VLAN that will be used for maintenance.
2. Set the IPv4 address on the maintenance VLAN. Set it using the ip address command.
3. Permit access from the maintenance VLAN to the TFTP server. Use the tftp-server interface command or the management interface command to specify that setting.
4. Enable the TFTP server. Enable the server using the tftp-server enable command.

Follow the rules below when sending the firmware update using the TFTP client.

• Set the transmission mode to “binary mode”.
• As shown in the table below, specify the remote path to which the firmware update is sent.
• Specify the administrative password in the form “/PASSWORD” at the end of the remote path.

  However, the firmware update cannot be applied if the administrative password is still set to the default setting. The administrative password setting must be changed in advance.

When updating firmware that uses TFTP clients, the following updates are possible.

Updated firmware

If there is no problem with the firmware update that was sent, the firmware update will be saved.

3.1.2 Updating the firmware by specifying a local file in the Web GUI

Specify the firmware update located on the terminal accessing the Web GUI, and applies it to this product.

This function does not do a version comparison with the existing firmware, and will overwrite the specified firmware regardless of version.

To update firmware by specifying a local file, click [Maintenance] - [Firmware update] in the Web GUI on the computer. (Refer to the part shown in a red frame on the screenshot below.)

Refer to the help contents within the GUI for the specific operation method.

Initial screen on the Web GUI for updating firmware using a PC

3.2 Using an HTTP client to update the firmware

This method of firmware update uses an HTTP client to obtain the firmware update from a specified URL, and then apply it to this product.

This function assumes that the firmware version will be upgraded. Downgrading to a previous version will only be permitted if “revision-down” is allowed.

The firmware cannot be rewritten with the same version of firmware.

An HTTP client can be used to update the firmware using the methods below.

• Use the firmware-update command in the CLI (command-line interface).
• Execute update firmware via the network in the Web GUI.

Updating the firmware with an HTTP client is done by using the settings value shown in the table below.

Firmware update using an HTTP client: setting parameters

For instructions on using the firmware-update command, refer to “5 Examples of Command Execution” or the “Command Reference”.

To update firmware over the network using the Web GUI, execute [Maintenance] - [Firmware update] on the Web GUI. (Refer to the part shown in a red frame on the screenshot below.)

Refer to the help contents within the GUI for the specific operation method.

Initial Web GUI Screen for Updating Firmware via the Network

3.3 Using an SD card to update the firmware

This function takes a firmware update from the SD card and applies it as boot firmware.

For this update method, execute the firmware-update sd execute command in the CLI (command-line interface).

If a stack was configured, commands can only be executed from the main switch in the stack.

After entering the firmware update confirmation, the update will continue even if the SD card is removed. To unmount the SD card when executing the command, enter “n” when prompted to confirm whether to maintain the SD card mount status or specify the “sd-unmount” command option.

If the system is rebooted with the SD card inserted in the main unit, the system will be booted using the firmware in the SD card, as specified by the boot prioritize sd command.

• File path in the SD card

  /swx3220/firmware/swx3220.bin
  /swx2320/firmware/swx2320.bin
  /swx2322p/firmware/swx2322p.bin

3.4 Reboot after writing

When successfully finished writing the firmware update, the system is automatically rebooted.

However, the system is not rebooted if the “no-reboot” option is specified for firmware-update execute or firmware-update sd execute commands.

If the firmware-update reload-time command is specified without specifying the “no-reboot” option, then the system is rebooted according to the reboot time setting.

The revision after the next reboot can be confirmed by executing the show firmware-update command.

If a stack is configured, the firmware update method can be selected using the firmware-update reload-method command.

• Method to update member switches during configuration simultaneously
• Method to update without stopping network services

For an overview of actions for firmware update methods, see Stack function.

4 Related Commands

Related commands are shown below.

For details, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Using an HTTP client to update the firmware

In this example, the firmware update is stored on the local HTTP server, and this product is set to manage the firmware in order to perform the update.

• Changes the firmware download URL to http://192.168.100.1/swx3220.bin .
• Leaves the proxy server setting blank.
• The downward revision setting is left disabled.
• The timeout value is left at 300 sec.
• A reboot time is not specified, but the system is rebooted immediately after updates.

1. The download URL is changed, and the firmware update settings are confirmed.

       Yamaha(config)#firmware-update url http://192.168.100.1/swx3220.bin … (Sets the download destination URL)
       Yamaha(config)#exit
       Yamaha#show firmware-update … (Shows the firmware update function setting)
       url: http://192.168.100.1/swx3220.bin
       http-proxy: -
       timeout: 300 (seconds)
       revision-down: Disable
       firmware revision for next boot: -
       reload-time: -
       reload-method: Normal
       

2. The firmware update is executed.

       Yamaha#firmware-update execute … (Executes firmware update)
       Found the new revision firmware
       Current Revision: Rev.4.02.01
       New Revision:     Rev.4.02.03
       Downloading...
       Update to this firmware? (y/n)y … (Enters y value)
       Updating...
       Finish
   
       (Reboots automatically)
       

3. Pressing “CTRL+C” during the firmware update process will interrupt the update.

       Yamaha#firmware-update execute
       Found the new revision firmware
       Current Revision: Rev.4.02.01
       New Revision:     Rev.4.02.03
       Downloading...                  … (“Ctrl-C” entered)
       ^CCanceled the firmware download

5.2 Using an HTTP client to update the firmware (in a proxy server environment)

This updates the firmware by specifying a proxy server.

• The initial download URL setting is left unchanged.
• The proxy server is set to http://192.168.100.1:8080.
• The downward revision setting is left disabled.
• The timeout value is left at 300 sec.
• A reboot time is not specified, but the system is rebooted immediately after updates.

1. Specify the HTTP proxy settings and confirm the firmware update settings.

       Yamaha(config)#firmware-update http-proxy http://192.168.100.1 8080 … (Sets the HTTP proxy server)
       Yamaha(config)#exit
       Yamaha#show firmware-update … (Shows firmware update function settings)
       url: http://www.rtpro.yamaha.co.jp/firmware/revision-up/swx3220.bin
       http-proxy: http://192.168.100.1:8080
       timeout: 300 (seconds)
       revision-down: Disable
       firmware revision for next boot: -
       reload-time: -
       reload-method: Normal
   

2. The firmware update is executed.

       Yamaha#firmware-update execute … (Executes firmware update)
       Found the new revision firmware
       Current Revision: Rev.2.04.01
       New Revision:     Rev.2.04.02
       Downloading...
       Update to this firmware? (y/n)y … (Enters y value)
       Updating...
       Finish
   
       (Reboots automatically)
   

5.3 Using an SD card to update the firmware

In this example, the firmware update is placed on an SD card inserted in the unit, and this product is set to manage the firmware in order to perform the update.

This is an example of a two-stack configuration.

• Changes the reboot time to 23:30.
• Changes the reboot method to rebooting the stack main switch and then successively rebooting member switches.

1. Change the reboot time and reboot method.

       Yamaha(config)#firmware-update reload-time 23 30        … (Changes the reboot time setting)
       Yamaha(config)#firmware-update reload-method sequential … (Sets the reboot method)
       Yamaha(config)#exit
   

2. Insert the SD card into the main switch in the stack and execute the firmware update.

       Yamaha#firmware-update sd execute  … (Executes firmware update)
       Update the firmware.
       Current Revision: Rev.4.02.01
       New Revision:     Rev.4.02.03
   
       Update to this firmware? (y/n)y … (Enters y value)
       Continue without unmounting the SD card? (y/n)n     … (Enters n value)
       Unmounted the SD card.  Pull out the SD card.
       Updating...
       Finish
       Yamaha#
       (Reboots at the specified reboot time)
   

3. The stack member firmware is updated at the same time as the stack main switch, but the members are rebooted after the firmware in the stack main switch has been rebooted.

   The following log history is displayed on stack member consoles.

       (The firmware update is received and the update is started after pressing ENTER on the stack main switch.)
       Receiving exec file... 
       Testing received file... 
       Writing to Nonvolatile memory... 
       Done.
   
       (Reboots the device at the specified reboot time.)
   

4. After checking the version of the update firmware, you can enter “n” to cancel.

       Yamaha#firmware-update sd execute  … (Executes the firmware update)
       Update the firmware.
       Current Revision: Rev.4.02.01
       New Revision:     Rev.4.02.03
   
       Update to this firmware? (y/n)n … (Enters n value)
       Yamaha#
   

6 Points of Caution

If the system is rebooted or the power is turned off during firmware update, the update will be interrupted and the system will start with the firmware before the update operation.

7 Related Documentation

• LED control

L2MS control

1 Function Overview

L2MS (Layer2 Management Service) is functionality for managing Yamaha network devices at the layer 2 level.

L2MS is configured with one L2MS manager unit (referred to as “manager” below) that manages multiple L2MS agent units (referred to as “agents” below).

Devices can be used as either a manager or agent.

The following illustrates how to connect the computer, manager, and agents.

L2MS Connections

Connect the computer to the manager via a serial connection or log in via Telnet or HTTP/HTTPS.

The manager includes commands for managing the agents and a Web GUI for specifying the settings or checking the status of agents. These can be used to operate the agents.

The manager is connected to agents via Ethernet cables and uses a proprietary protocol (L2MS) for communication.

This functionality has the following characteristics.

• Initial settings are not required

  Although IP addresses must be specified if using Telnet or SSH, default settings do not need to be specified for agents, because the functionality uses a proprietary protocol (L2MS) for communication.

  When Ethernet cables are connected, the manager automatically detects subordinate agents.

• Multiple supported devices can be controlled simultaneously

  The manager can recognize and control multiple agents simultaneously.

The proprietary communication protocol used by L2MS is the same protocol as used for communication by the switch control functionality supported by Yamaha routers and SWX series and WLX series.

That means both SWX series and WLX series devices can be managed from the manager.

2 Definition of Terms Used

Manager

A manager is a device that manages Yamaha network devices functioning as an agent based on L2MS and switch control functionality.

It manages Yamaha switches and Yamaha wireless apps within the network.

Agent

A Yamaha switch or Yamaha wireless AP that is managed by a manager based on L2MS and switch control functionality.

Settings can be checked or changed from the manager.

3 Function Details

3.1 Supported models

Devices can be used as either an L2MS manager or agent.

If operating as a manager, each manager can control a maximum of 128 agent units.

The following models can be managed as an agent.

As described earlier, any device that supports switch control functionality (agents) can also be controlled.

• SWX2100 series (SWX2100-8G, SWX2100-16G, SWX2100-24G, SWX2100-5PoE, SWX2100-10PoE)
• SWX2110 series (SWX2110-5G, SWX2110-8G, SWX2110-16G)
• SWX2110P series (SWX2110P-8G)
• SWX2200 series (SWX2200-8G, SWX2200-24G, SWX2200-8PoE)
• SWX2210 series (SWX2210-8G, SWX2210-16G, SWX2210-24G)
• SWX2210P series (SWX2210P-10G, SWX2210P-18G, SWX2210P-28G)
• SWX2220 series (SWX2220-10NT)
• SWX2221P series (SWX2221P-10NT)
• SWX2300 series (SWX2300-8G, SWX2300-16G, SWX2300-24G)
• SWX2310 series (SWX2310-10G, SWX2310-18GT, SWX2310-28GT, SWX2310-52GT)
• SWX2310P series (SWX2310P-10G, SWX2310P-18G, SWX2310P-28GT)
• SWX2320 series (SWX2320-16MT)
• SWX2322P series (SWX2322P-16MT)
• SWX3100 series (SWX3100-10G, SWX3100-18GT)
• SWX3200 series (SWX3200-28GT, SWX3200-52GT)
• SWX3220 series (SWX3220-16MT, SWX3220-16TMs)
• WLX series (WLX202, WLX212, WLX222, WLX302, WLX313, WLX402, WLX413)

If operated as an agent, the unit is managed by the Yamaha router or Yamaha switch manager.

For details about compatible Yamaha router models, refer to Switch control functionality of Yamaha routers.

3.2 Usage

The L2MS operation and role is set by the l2ms command.

• L2MS Managers

  L2MS managers manage the SWX and WLX series switches operating as agents.

  The terminal-watch enable command can be used to periodically acquire and monitor information about computers and other terminals present in the network.

  Yamaha(config)#l2ms configuration
  Yamaha(config-l2ms)#l2ms enable
  Yamaha(config-l2ms)#l2ms role manager
  Yamaha(config-l2ms)#terminal-watch enable
  

• L2MS Agents

  L2MS agents are managed by a Yamaha router or Yamaha switch operating as a manager.

  Yamaha(config)#l2ms configuration
  Yamaha(config-l2ms)#l2ms enable
  Yamaha(config-l2ms)#l2ms role agent
  

The show l2ms command can be used to check a slave’s current action and role.

3.3 L2MS Protocol

L2MS control is performed using the proprietary protocol L2 frames indicated below.

Content of L2MS Protocol L2 Frames

If a firewall is specified between the manager and agents, the firewall settings must allow these L2 frames to pass through.

3.4 Monitoring agents

Managers monitor subordinate agents by sending query frames at regular intervals.

Agents respond to query frames by sending a response frame to notify the manager that they exist.

The interval between sending query frames is specified using the agent-watch interval command.

Increasing the setting value will decrease the sending frequency, but will lengthen the time for the manager to recognize an agent after it is contacted.

Decreasing the setting value will, conversely, increase the sending frequency, but shorten the time for the manager to recognize an agent after it is contacted.

If the manager does not receive a response frame from an agent after sending the specified number of query frames, the manager will decide that the corresponding agent has gone down.

The number of attempts is specified by the agent-watch down-count command.

If the Ethernet cable connected to the agent is disconnected, in some cases the manager might decide that the agent has gone down sooner than specified by the command.

Specify appropriate setting values for agent-watch interval and agent-watch down-count commands based on the given network environment being used.

3.5 Agent ownership

No agent may be simultaneously controlled by multiple managers.

Therefore, only specify one manager per network.

If an agent receives a query frame after rebooting, that agent will be managed by the manager that sent the query frame.

That relationship is canceled if any of the following occur.

• A query frame is not received for 30 seconds.
• The manager is rebooted.
• The l2ms reset command is executed by the manager.

3.6 Agent Operations

If a manager sets a setting for an L2MS-compliant agent or checks its operating status, such actions are referred to as “operating the agent”.

Agents are operated using the LAN map on the Web GUI.

To operate an agent, log into the manager Web GUI and select the applicable agent in the LAN map.

For more detailed LAN map operating instructions, refer to the Web GUI help page.

Note that agents cannot be operated using commands executed by the manager.

The following describes how to operate each operable agent via the LAN map.

3.6.1 Controlling SWX2100 Series Units

The following operations can be performed for agents.

• Display the status of the device and ports
• Show and control the power supply status of ports (PoE-equipped models only)
• Show/maintain switch settings (show function settings, update firmware, restart, etc.)

3.6.2 Controlling SWX2110, SWX2110P Series Units

The following operations can be performed for agents.

• Display the status of devices and ports
• Show and control the power supply status of ports (PoE-equipped models only)
• Set/maintain switch settings (change function settings, update firmware, reboot, etc.)
• Specify ports (VLAN tags, etc.)
• Save and restore config settings

3.6.3 Controlling SWX2200 Series Units

The following operations can be performed for agents.

• Display the status of devices and ports
• Show and control the power supply status of ports (PoE-equipped models only)
• Set/maintain switch settings (change function settings, update firmware, reboot, etc.)
• Save settings to the manager and synchronize settings with settings saved in the manager

If SWX2200 settings are set from the manager, the settings are saved in both the manager and SWX2200 unit.

The settings are saved as a separate file from the manager config file, but the startup-config select command can be used to change the config settings at the same time.

If the SWX2200 unit is managed by the manager, settings in the manager and SWX2200 unit will be kept synchronized.
For details on synchronization of settings, refer to “3.6.7 Synchronizing Settings”.

The status of settings in SWX2200 units managed by the manager can be checked using the show l2ms agent-config command.

3.6.4 Operations for SWR2210, SWX2210P, SWX2220, and SWX2221P Series Agents

The following operations can be performed for agents.

• Display the status of devices and ports
• Show and control the power supply status of ports (PoE-equipped models only)
• Change settings and perform maintenance (changing function settings, rebooting, etc.)
• Specify port settings (tagged VLAN, multiple VLANs, etc.)
• Specify link aggregation
• Change the IP address setting
• Save and restore config settings
• Use HTTP proxy functionality to log into the agent GUI
• Find this switch (SWX2220/SWX2221P models only)

If the HTTP proxy functionality is enabled, then it is possible to log into agent GUIs from the manager LAN map.
That eliminates the need to enter a username and password for logging into an agent.

If SWX2210, SWX2210P, SWX2220, or SWX2221P series units are managed by a manager configured with factory settings, then DHCP client settings are specified automatically.
For more details, refer to “3.6.8. HTTP Proxy Function and Setting IP Addresses”.
・ The SWX2210 model supports Rev.1.02.10 and later firmware.
・ The SWX2210P model supports Rev.1.03.08 and later firmware.

3.6.5 Controlling SWX2300, SWX2310, SWX2310P, SWX2320, SWX2322P, SWX3100, SWX3200, or SWX3220 Series Units

The following operations can be performed for agents.

• Display the status of the device and ports
• Show and control the power supply status of ports (PoE-equipped models only)
• Change the IP address setting
• Saving and restoring config settings
  *Saving and restoring SWX2300 config settings is supported by Rev. 2.00.14 and later firmware.
• Use HTTP proxy functionality to log into the agent GUI.

If the HTTP proxy functionality is enabled, then it is possible to log into agent GUIs from the manager LAN map.

That eliminates the need to enter a username and password for logging into an agent.

If SWX2300, SWX2310, SWX2310P, SWX2320, SWX2322P, SWX3100, SWX3200, or SWX3220 series units are managed by a manager configured with factory settings, then DHCP client settings are specified automatically.

For more details, refer to “3.6.8. HTTP Proxy Function and Setting IP Addresses.”

3.6.6 Controlling WLX Series Units

The following operations can be performed for agents.

• Display the status of devices, LAN ports, and wireless modules
• Change the IP address setting
• Save and restore config settings
• Use HTTP proxy functionality to log into the agent GUI

If the HTTP proxy functionality is enabled, then it is possible to log into agent GUIs from the manager LAN map.
That eliminates the need to enter a username and password for logging into an agent.

If a WLX series unit is managed by a manager configured with factory settings, then DHCP client settings are specified automatically.
For more details, refer to “3.6.8. HTTP Proxy Function and Setting IP Addresses”.

3.6.7 Synchronizing Settings

If an SWX2200 unit is managed by a manager, then settings held in the manager and SWX2200 unit are kept synchronized.
Synchronization is unidirectional from the manager to the SWX2200 unit, with the SWX2200 unit always operating based on settings in the manager.

When the manager starts managing an SWX2200 unit, it first checks whether the manager and SWX2200 settings match.
If they do not match, the following processes are performed.

1. All SWX2200 settings are restored to default values.
2. Function setting values held by the manager are sent to the SWX2200 unit.

The manager periodically monitors the settings of subordinate SWX2200 units and synchronizes them if a discrepancy is detected.

Synchronization may take some time (several tens of seconds to several minutes).
During synchronization, other SWX2200 operations are disabled.
Attempting to specify settings will cause an error without applying the settings to the manager or SWX2200 unit.

3.6.8 HTTP Proxy Function and Setting IP Addresses

The following actions are performed for WX2300, SWX2310, SWX2310P, SWX2320, SWX2322P, SWX3100, SWX3200, SWX3220 series, or WLX series series units.

Given factory settings, a fixed IP address is specified immediately after executing the cold start command. (The L2MS operates as an agent.)

If the agent is managed by the manager, then DHCP client settings are specified automatically.

This is to avoid duplicate IP addresses if multiple agents exist.

Since IP addresses are assigned by the DHCP server within the network, agent Web GUIs can be accessed via the HTTP proxy server. However, that requires specifying the http-server enable setting in the agent.

If a DHCP server does not exist in the network, then IP addresses cannot be obtained and agent IP addresses must be specified on the manager LAN map.

Once the IP setting is specified and the startup config has been saved, it will not be automatically specified in the DHCP client thereafter.

3.7 Information Notifications from Agents

If an agent managed by a manager detects a change or error in its own status, it sends information to notify the manager.

Information sent from the agent is output in the manager SYSLOG or LAN map.

For details on messages output to the SYSLOG, refer to “7. SYSLOG Message List.”

The following information is included in notifications from agents.

Information in Notifications from Each Agent to the Manager

3.8 Monitoring Connected Terminals

Specifying the terminal-watch enable command in the manager enables functionality for monitoring connected terminals, so that information about terminals connected to the manager and agents can be managed.

The manager manages the following information about connected terminals.

• If the Manager and Agents are Yamaha Switches
  • MAC address of the terminal
  • Manager or agent port number to which the terminal is connected
  • Date/time when terminal was detected
• If the Agent is a Yamaha Wireless AP
  • MAC address of the terminal
  • SSID to which the terminal is connected
  • Frequency (2.4 or 5 GHz) of terminal connection
  • Date/time when terminal was detected

This information can be viewed using the show l2ms detail command.

The recommended maximum number of terminals managed by this function is 200 units, regardless of network configuration.

Note that more than the recommended number of units in the network could cause LAN map actions on the Web GUI to be sluggish or unresponsive.

The manager will search for connected terminals or delete managed terminal information based on changes in the network.

The target and timing of manager searches for connected terminals are indicated below.

If new terminal information is found as a result of the search, it is determined that a terminal was detected.

Timing and Object of Terminal Searches

The following indicates what managed terminal information is deleted and when it is deleted if the manager determines that the terminal has disappeared from a network.

Terminal for Which Information is Deleted and Deletion Timing

4 Related Commands

Related commands are indicated below.

For details, refer to the Command Reference.

List of L2MS-related commands

5 Examples of Command Execution

5.1 Agent monitoring settings

Set the time interval for monitoring agents.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#agent-watch interval 8

Set the number of monitoring times before deciding an agent is down.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#agent-watch down-count 7

5.2 Specifying Terminal Management Function Settings

Enable the terminal monitoring function.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#terminal-watch enable

Set the time interval for acquiring terminal information.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#terminal-watch interval 3600

Show the terminal information obtained by the manager.

Yamaha>show l2ms detail
Role : Manager

[Manager]
 Number of Terminals   : 0

[Agent]
 Number of Agents      : 2
  [ac44.f230.00a5]
   Model name          : SWX2100-24G
   Device name         : SWX2100-24G_Z5301050WX
   Route               : port2.1
   LinkUp              : 1, 3, 9
     Uplink            : 1
     Downlink          : 3
   Config              : None
   Appear time         : Tue Mar 13 18:43:18 2018
   Number of Terminals : 1
    [bcae.c5a4.7fb3]
     Port              : 9
     Appear time       : Wed Mar 14 14:01:18 2018

  [00a0.deae.b8bf]
   Model name          : SWX2300-24G
   Device name         : SWX2300-24G_S4L000401
   Route               : port2.1-3
   LinkUp              : 1
     Uplink            : 1
     Downlink          : None
   Config              : None
   Appear time         : Tue Mar 13 18:43:18 2018
   Number of Terminals : 0

5.3 Enabling/Disabling Sending/Receiving L2MS Control Frames

Disable sending or receiving L2MS control frames at port 1.5.

Yamaha(config)#interface port1.5
Yamaha(config-if)#l2ms filter enable

5.4 Enabling/Disabling the Event Monitoring Function

Disable the event monitoring function.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#event-watch disable

Set the time interval between acquiring event information.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#event-watch interval 60

5.5 Enabling/Disabling the Zero-Config Function

This specifies whether the manager uses the zero-config function for agents.

This setting must be specified in the manager.

Disable the zero config function.

Yamaha(config)#l2ms configuration
Yamaha(config-l2ms)#l2ms enable
Yamaha(config-l2ms)#l2ms role manager
Yamaha(config-l2ms)#config-auto-set disable

6 Points of Caution

6.1 Device Configuration

A maximum of 128 agents can be managed.

If the agents are used connected in series, a maximum of 8 agents can be connected from the manager.

Nine or more agents cannot be connected to the manager in series.

If up to 8 agents are connected in series from the manager, then the specified maximum number of managed agents can be controlled.

Connecting nine or more agents in series from the manager could prevent properly recognizing or controlling agents due to delays in L2MS communication or cause the following types of problems.

• The synchronization process might not function correctly.
• If agent settings are modified from the GUI, correct execution might not be possible.

If a non-Yamaha switch exists in the L2MS communication route, such as between the manager and an agent, it might not be possible to control the agent correctly.

If you are configuring a network that includes a non-Yamaha switch, verify its operation beforehand.

6.2 Terminal Monitoring

The recommended maximum number of managed units in a network is 200 units.

Including more than the recommended maximum number of managed units could cause the LAN map in the Web GUI to become sluggish or unresponsive.

If necessary, disable the terminal management function (terminal-watch disable command).

Terminal searches use the information registered in the FDB (MAC address table) for the applicable devices.

Therefore, depending on when the search is performed, a connected terminal might not be detected or a terminal no longer in the network might be detected.

If a link is detected to be down for a manager or Yamaha switch port, all information for the terminal connected to that port is deleted even if the terminal is registered in the FDB (MAC address table).

It may take L2MS several seconds to recognize an agent after it is connected to a port.

During that time, the corresponding agent is treated as a terminal.

Yamaha network devices that are not managed as an agent by the manager are treated as terminals.

Terminal searches performed at intervals specified by the terminal-watch interval command search for terminals connected to the manager or all agents, which might take twenty to thirty minutes to complete for some network configurations.

However, other processes are not disabled until terminal searches are completed.

If a non-Yamaha L2 switch is connected to an L2MS-compliant device, the terminals connected to the non-Yamaha L2 switch are detected as terminals connected to the L2MS-compliant device.

However, if a terminal and a Yamaha switch are connected in parallel to a non-Yamaha L2 switch, the terminal connected to the non-Yamaha L2 switch cannot be detected.

6.3 Use in Conjunction with Other Functionality

6.3.1 Use in Conjunction with a VLAN

If using a VLAN, ports used for L2MS communication must be specified as an access port or as a trunk port assigned by the native VLAN.

L2MS communication is not possible via a trunk port not assigned by the native VLAN.

6.3.2 Use in Conjunction with Mirroring

If the mirroring function is used, L2MS communications sent and received at the monitor port are also copied.

Therefore, L2MS might not function properly if the manager or an agent is connected to a mirror port, so do not connect a manager or an agent to a mirror port.

6.3.3 Use in Conjunction with ACL

L2MS communication is not subject to ACL control.

Although the ACL discards frames that are not specified in the permissions list (tacit rejection), L2MS communications are not subject to ACL control, so frames are forwarded without being discarded.

6.3.4 Use in Conjunction with STP or Loop Detection Functionality

L2MS communication is not possible on ports blocked by STP or loop detection functionality.

Link switching by STP could prevent the manager from recognizing the topology correctly, which could prevent finding agents or cause routing errors when agents are found.

In such cases, reset agent management after STP has finished switching the link by executing the l2ms reset command.

If multiple MST instances are operating, L2MS control frames are sent and received on the logical route (tree) formed by CIST (instance #0).

6.3.5 Use in Conjunction with Link Aggregation

If link aggregation is used, L2MS communication is considered to be occurring on “the lowest-numbered linked-up port associated with the logical interface.”

If link aggregation is used in conjunction with the monitoring function for connected terminals and a terminal is discovered at the end of a logical interface connection, then the terminal is considered to be connected to “the lowest-numbered linked-up port associated with the logical interface” and the corresponding port number is shown.

In Configuration 1, L2MS communication is assumed to be occurring between respective ports 1.1.

In Configuration 2, L2MS communication is assumed to be occurring between manager port 1.1 and agent port 1.1.

6.3.6 Use in Conjunction with the Stack Function

L2MS functions if even one unit is operating.

Even if the stack function is enabled, it is operated as one standalone unit if it cannot negotiate with a member switch.

L2MS will function even in that case.

• The L2MS manager can detect L2MS agents.
• L2MS agents are detected by the L2MS manager.

  However, only devices connected below the standalone switch are detected, while not detecting devices connected to other switches assumed to be down.

7. SYSLOG Message List

L2MS outputs the following SYSLOG messages.

Output messages are appended with the "[ L2MS]” prefix.

SYSLOG messages displayed for units functioning as a manager are also appended with the "route (addr):” prefix.

“route” refers to the route and “addr” the agent MAC address (indicated in all lowercase, in the form “xxxx.xxxx.xxxx”).

SYSLOG Messages Displayed When the Unit Starts Up or the Operating Mode is Changed

SYSLOG Messages Displayed When Operating as the Manager

SYSLOG Messages Displayed for Devices Operating as the Manager with the logging event lan-map Command Specified

Messages are appended with the "[ LANMAP]” prefix.

The manager receives the following information notifications from agents.

SYSLOG Messages Displayed When Operating as an Agent

8 Related Documentation

• Switch control functions of Yamaha routers

Mail notification

1 Function Overview

The email notification function sends email notifications of information detected by the L2MS function or terminal monitoring function.

By specifying the following settings, email notifications can be sent with information detected by various functions.

• Specify settings for the mail server used to send emails.
• Specify the email template.

2 Definition of Terms Used

Email Template

The email template defines the collection of information needed for sending email.

• Mail server to use
• Sender email address
• Recipient email address
• Subject of email
• Content of notification
• Transmission wait time

3 Function Details

3.1 Operation

After mail server settings and email template settings having been configured correctly, the email notification function will enter the send-standby state whenever a notification event occurs for a function that supports email notification.

When the email notification function is in the send-standby state, the function will wait until the specified email transmission wait time specified in each email template elapses.

When the email transmission wait time has elapsed, the email notification function combines the information for notification events that occurred during the wait time into a single email and sends it to the recipient.

3.2. Mail Server Settings

Settings can be specified in the List of Registered Mail Servers displayed by clicking [Advanced settings] - [Email notification] in the Web GUI.

To display the Mail server settings, click the [New] button or the [Setting] button for existing settings.

In Mail server settings, make the following settings.

• Account identification name

  Name for uniquely identifying the mail server settings. This setting may be omitted.

• SMTP server address
• Port number of the SMTP server
• SMTP encryption

  Selects either “SMTP over SSL” or “STARTTLS” as the encryption method.

• SMTP authentication

  To use SMTP authentication, enter the username and password.

3.3 Email Template Settings

Email template settings can be specified by clicking [Advanced settings] - [Email notification] in the Web GUI to display the List of email notification settings.

Press the [New] button or the [Setting] button for an existing setting to display email notification settings.

In email notification settings, specify the following settings.

• Source (From)
• Recipient (To)
• Subject

  If the Use default subject box is checked, then the email subject will always be in the form Notification from (device name).

• Content of notification

  Error types can be specified in detail for Detect LAN map errors, so that only the specified type of notifications are output.

• Email sending wait time

3.4 Functions that Support Email Notification

The following functions support email notification.

LAN map

The following notification events can be included in email notifications.

Terminal monitoring function

The following notification events can be included in email notifications.

Stack function

The following notification events can be included in email notifications.

3.5 Email Body Example

The body of a notification email includes content such as the following.

For details, refer to the technical reference for each function.

Up to 100 items can be included in one notification email.

Model: SWX3220-16MT                  *Model name
Revision: Rev.4.02.00                *Firmware version
Name: SWX3220-16MT_XXXXXXXX          *Host name
Time: 2017/06/13 11:42:56            *Email sending time
Template ID: 1                       *Email template ID

<<<<<<<<<<<<<<<<<<<<<<<<    Lan Map Information    >>>>>>>>>>>>>>>>>>>>>>>>>

[SFP RX Power]

  Type                                Device_Name
  MAC_Address                         Err_Port
  Route
  State
============================================================================
(Detected: 2017/06/13 10:09:40  Recovered: 2017/06/13 10:10:10)
  SWX2310P-10G                        SWX2310P-10G_S4K000398
  00a0.deae.b89c                      1.9
  port1.7(UpLink:1.5)
  Low
----------------------------------------------------------------------------

[Queue Usage Rate]

  Type                                Device_Name
  MAC_Address                         Err_Port
  Route
  State
============================================================================
(Detected: 2017/06/13 10:15:42  Recovered: 2017/06/13 10:17:24)
  SWX2310P-10G                        SWX2310P-10G_S4K000398
  00a0.deae.b89c                      1.6
  port1.7(UpLink:1.5)
  Full(Queue:2)
----------------------------------------------------------------------------

[Fan Lock]

  Type                                Device_Name
  MAC_Address
  Route
============================================================================
(Detected: 2017/06/13 10:28:43  Recovered: ----/--/-- --:--:--)
  SWX2200-8PoE                        SWX2200-8PoE_S45000345
  00a0.de83.4146
  port1.5(UpLink:2)
----------------------------------------------------------------------------
(Detected: 2017/06/13 10:42:13  Recovered: 2017/06/13 10:42:22)
  SWX2200-24G                         SWX2200-24G_X00000344
  00a0.de2a.dbbb
  port1.1(UpLink:23)
----------------------------------------------------------------------------

<<<<<<<<<<<<<<<<<<    Terminal Monitoring Information    >>>>>>>>>>>>>>>>>>>

[via Ping]

 Date                      Status    IP Address        Description
----------------------------------------------------------------------------
 2017/06/13 Thu 10:42:56   UP        192.168.100.155   IP_Camera_1
 2017/06/13 Thu 10:51:00   DOWN      192.168.100.155   IP_Camera_1
 2017/06/13 Thu 10:54:02   UP        192.168.100.10    Wireless_AP_1
 2017/06/13 Thu 11:29:27   UP        192.168.100.155   IP_Camera_1
 2017/06/13 Thu 11:30:31   DOWN      192.168.100.10    Wireless_AP_1

[via Bandwidth Usage]

 Date                      Status    Interface         Description
----------------------------------------------------------------------------
 2017/06/13 Thu 10:45:43   UP        port1.4           IP_Camera_2
 2017/06/13 Thu 10:45:56   UP        port1.6           Note_PC_1
 2017/06/13 Thu 10:50:00   DOWN      port1.6           Note_PC_1
 2017/06/13 Thu 10:53:27   DOWN      port1.4           IP_Camera_2

[via LLDP]

 Date                      Status    Interface         Description
----------------------------------------------------------------------------
 2017/06/13 Thu 10:53:56   UP        port1.3           Note_PC_2
 2017/06/13 Thu 11:11:54   DOWN      port1.3           Note_PC_2
 2017/06/13 Thu 11:14:24   UP        port1.3           Note_PC_2

<<<<<<<<<<<<<<<<<<<<<<<<<<    Stack Information    >>>>>>>>>>>>>>>>>>>>>>>>>

 Date                      Information 
----------------------------------------------------------------------------
 2017/06/13 Thu 10:53:44   The stack port changed state to down. (port1.27)
 2017/06/13 Thu 10:53:46   Promoted to a main. (Old main ID : 1)
 2017/06/13 Thu 10:59:10   Occurred the heartbeat error. (ID : 1)
 

3.5.1 Content of LAN map notifications

Content of notifications for each event

The content of LAN map notification emails differs depending on the event type.

The content of notifications for each event type is indicated below.

Detailed content of notification

A detailed description of the various information included notifications is indicated below.

4 Related Commands

Related commands are indicated below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Points of Caution

The following are precautions related to SMTP authentication.

• The SMTP authentication only supports the LOGIN method.
• PLAIN, CRAM-MD5, and other methods are not supported.

Precautions for using firmware not compatible with the email notification function.

• If the firmware is updated from a version that does not support a command to a version that does support the command, commands specified in the Web GUI are directly carried over as command settings.
• To revert to the firmware version that does not support the commands, any changes to settings made using the firmware that does support the commands are not migrated and must be specified again after restoring the older version.
• If no settings were changes, then the current settings can be maintained.

The following are precautions related to LAN map error detection.

• Errors are indicated in notifications as active until the error is resolved, even if the error notification is disabled without resolving the error.
• Specifically, even after a notification is disabled, an email is sent after the error is resolved and is included in emails about the occurrence of other errors.

6 Related Documentation

• L2MS control
• Terminal monitoring
• Stack function

LLDP

1 Function Overview

LLDP is a protocol for passing device management information between a device and its neighboring devices.

This is a simple protocol in which a device unidirectionally advertises its own information and neighbor devices receive this information. However, since LLDP-compliant devices maintain the information received from neighbor devices as MIB objects, the user can access this information via SNMP and ascertain what type of devices are connected to which interfaces are.

2 Definition of Terms Used

LLDP

Link Layer Discovery Protocol.

This is defined in IEEE 802.1AB.

LLDP-MED

LLDP for Media Endpoint Devices.

This is defined in ANSI/TIA-1057.

3 Function Details

3.1 Operating Specifications

3.1.1 Basic Specifications

This product supports the following operations.

• LLDP frames are transmitted from any LAN/SFP port to convey information about the device itself.
• LLDP frames are received at any LAN/SFP port to obtain information about neighboring devices.
• Information transmitted via LLDP about the device itself, and information obtained via LLDP about neighbor devices, etc., can be referenced via SNMP.

LLDP sends and receives information using Type, Length, and Value (TLV) attributes.

For details on the TLV information sent by this product, refer to 3.2 TLV list.

This product’s LLDP supports the following MIBs of SNMP. For details, refer to 3.3 Supported MIBs.

• LLDP-MIB
• LLDP-V2-MIB
• LLDP-EXT-MED-MIB

The following settings are required in order to use the LLDP function.

• Use the lldp run command to enable the system-wide LLDP function.
• Use the lldp-agent command to create an LLDP agent for the applicable interface.
• Use the set lldp command to specify the LLDP frame transmit/receive mode.

With the default settings of this product, the LLDP function is disabled.

LLDP frames are always transmitted without tags, regardless of the VLAN settings of the transmitting switch port.

They are also transmitted without tags from a trunk port without a native VLAN.

3.1.2 Transmitted information settings

Use the following commands to specify the LLDP frames that are transmitted from the device itself. There are also some TLVs (required TLVs) that are transmitted regardless of the settings of the following commands.

• tlv-select basic-mgmt command (basic management TLV)
• tlv-select ieee-8021-org-specific command (IEEE 802.1 TLV)
• tlv-select ieee-8023-org-specific command (IEEE 802.3 TLV)
• tlv-select med command (LLDP-MED TLV)

The system name and description that are transmitted in the basic management TLVs are specified by the lldp system-name command and the lldp system-description command.

The type of management address is set by the set management-address-tlv command.

3.1.3 Transmission timer setting

The interval at which LLDP frames are sent is specified by the set timer msg-tx-interval command.
The multiplier for calculating the hold time (TTL) for device information is set by the set msg-tx-hold command.

The TTL for LLDP transmission is the result of the following calculation. The default is 121 seconds.

• TTL = ( value set by the “set timer msg-tx-interval” command ) × ( value set by the “set msg-tx-hold” command ) ＋ 1 (second)

When a neighbor device is connected to a LAN/SFP port for which LLDP frame transmission is enabled, LLDP frames are transmitted rapidly at a fixed interval according to the high-speed transmission interval setting.

The transmission interval and the number of transmissions for high speed transmission are set by the set timer msg-fast-tx command and the set tx-fast-init.

If from a state in which LLDP frame transmission is enabled, the set lldp command is used to disable it, this product transmits a shut-down frame, notifying the neighbor device that LLDP frame transmission has stopped.

Subsequently, even if LLDP frame transmission is once again enabled, LLDP frame transmission to the neighbor device is stopped for a time.

The stopped duration until the next transmission occurs after transmitting the shutdown frame is set by the set timer reinit-delay command.

3.1.4 Maximum connected devices setting

The maximum number of connected devices that can be managed by the corresponding port is set by the set too-many-neighbors limit command.

The default value for the maximum number of connected devices is 5 devices.

3.1.5 Checking LLDP information

LLDP interface settings and received information about neighbor devices can be checked by using the show lldp interface command or the show lldp neighbors command.

To clear the LLDP frame counter, use the clear lldp counters command.

3.1.6 Other functions using LLDP

This product provides a function that uses LLDP to automatically make optimal settings for the Dante digital audio network. The Dante optimization settings function is set by the lldp auto-setting command. For details, refer to Dante optimization setting function.

This product also provides a function that uses LLDP to monitor the live/dead state of a specific connected terminal. For details, refer to Terminal monitoring.

For the voice VLAN function, you can use LLDP-MED to make voice traffic settings for IP telephony. For details, refer to VLAN.

3.2 TLV list

The TLVs supported by this product are listed below.

• Required TLVs
• Basic management TLVs
• IEEE 802.1 TLV
• IEEE 802.3 TLV
• LLDP-MED TLV

For the detailed specification of each TLV, refer to IEEE 802.1AB (LLDP) and ANSI/TIA-1057 (LLDP-MED).

The TLVs that are transmitted by this product are explained below.

3.2.1 Required TLVs

If LLDP frame transmission is enabled, these TLVs are always transmitted.

Three TLVs are transmitted: chassis ID, port ID, and TTL.

The required TLVs are shown below.

Required TLVs

3.2.2 Basic management TLVs

These TLVs are transmitted if LLDP frame transmission is enabled and the tlv-select basic-mgmt command is specified.

System-related management information is transmitted, such as name, system capabilities, and address.

The basic management TLVs are as follows.

Basic management TLVs

3.2.3 IEEE 802.1 TLV

These TLVs are transmitted if LLDP frame transmission is enabled and the tlv-select ieee-8021-org-specific command is specified.

These transmit information such as VLAN and link aggregation for the corresponding port.

The IEEE 802.1 TLVs are shown below.

IEEE 802.1 TLV

3.2.4 IEEE 802.3 TLV

These TLVs are transmitted if LLDP frame transmission is enabled and the tlv-select ieee-8023-org-specific command is specified.

Auto negotiation support information etc. for the corresponding port is transmitted.

The IEEE 802.3 TLVs are shown below.

IEEE 802.3 TLV

3.2.5 LLDP-MED TLV

These TLVs are transmitted if LLDP frame transmission is enabled and the tlv-select med command is specified.

These are used to transmit network policy information, for example.

The LLDP-MED TLVs are shown below.

LLDP-MED TLV

Network policy is only transmitted via the port specified by Voice VLAN.

3.3 Supported MIBs

Refer to the following SNMP MIB Reference for information on the MIBs that are supported.

• SNMP MIB Reference

4 Related Commands

Related commands are shown below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Set LLDP frame transmission/reception

For port1.1, enable LLDP frame transmission/reception.

Basic management TLVs, IEEE 802.1 TLVs, IEEE 802.3 TLVs, and LLDP-MED TLVs are transmitted.

Set the LLDP frame transmission interval to 60 seconds. Set the LLDP frame TTL to 181 seconds.

Set “SWITCH1” as the name of the transmitting system.

Specify 10 as the maximum number of connected devices managed by the port.

Yamaha#configure terminal
Yamaha(confif)#lldp system-name SWITCH1 ... (Set system name)
Yamaha(config)#interface port1.1
Yamaha(config-if)#lldp-agent ... (Create LLDP agent and transition modes)
Yamaha(lldp-agent)#tlv-select basic-mgmt ... (Set basic management TLV)
Yamaha(lldp-agent)#tlv-select ieee-8021-org-specific ... (Set IEEE 802.1 TLV)
Yamaha(lldp-agent)#tlv-select ieee-8023-org-specific ... (Set IEEE 802.3 TLV)
Yamaha(lldp-agent)#tlv-select med ... (Set LLDP-MED TLV)
Yamaha(lldp-agent)#set timer msg-tx-interval 60 ... (Set transmission interval)
Yamaha(lldp-agent)#set msg-tx-hold 3 ... (Set multiplier for TTL calculation: TTL = 60 × 3 + 1 = 181 seconds)
Yamaha(lldp-agent)#set too-many-neighbors limit 10 ... (Set maximum number of connected devices)
Yamaha(lldp-agent)#set lldp enable txrx ... (Set LLDP transmission/reception mode)
Yamaha(lldp-agent)#exit
Yamaha(config-if)#exit
Yamaha(config)#lldp run ... (Enable LLDP function)
Yamaha(config)#exit

5.2 Show LLDP interface status

Show the port1.1 LLDP interface status.

Yamaha#show lldp interface port1.1  ... (Show interface information)
Agent Mode                    : Nearest bridge
Enable (tx/rx)                : Y/Y
Message fast transmit time    : 1
Message transmission interval : 30
Reinitialization delay        : 2
MED Enabled                   : Y
Device Type                   : NETWORK_CONNECTIVITY
LLDP Agent traffic statistics
  Total frames transmitted       : 0

5.3 Show LLDP connected device information

Show LLDP connected device information.

Yamaha#show lldp neighbors  ... (Show connected device information)
Interface Name           : port1.1
System Name              : SWX3100-10G
System Description       : SWX3100 Rev.4.01.02 (Mon Dec  4 12:33:18 2019)
Port Description         : port1.3
System Capabilities      : L2 Switching
Interface Numbering      : 2
Interface Number         : 5003
OID Number               :
Management MAC Address   : ac44.f230.0000
Mandatory TLVs
  CHASSIS ID TYPE
    IP ADDRESS           : 0.0.0.0
  PORT ID TYPE
    INTERFACE NAME       : port1.3
  TTL (Time To Live)     : 41
8021 ORIGIN SPECIFIC TLVs
  Port Vlan id                : 1
  PP Vlan id                  : 0
  Remote VLANs Configured
    VLAN ID                   : 1
    VLAN Name                 : default
  Remote Protocols Advertised :
    Multiple Spanning Tree Protocol
  Remote VID Usage Digestt    : 0
  Remote Management Vlan      : 0
  Link Aggregation Status     : 
  Link Aggregation Port ID    : 
8023 ORIGIN SPECIFIC TLVs
  AutoNego Support            : Supported Enabled
  AutoNego Capability         : 27649
  Operational MAU Type        : 30
  Power via MDI Capability (raw data)
    MDI power support         : 0x0
    PSE power pair            : 0x0
    Power class               : 0x0
    Type/source/priority      : 0x0
    PD requested power value  : 0x0
    PSE allocated power value : 0x0
  Link Aggregation Status     : 
  Link Aggregation Port ID    : 
  Max Frame Size              : 1522
LLDP-MED TLVs
  MED Capabilities            :
    Capabilities
    Network Policy
  MED Capabilities Dev Type   : End Point Class-3
  MED Application Type        : Reserved
  MED Vlan id                 : 0
  MED Tag/Untag               : Untagged
  MED L2 Priority             : 0
  MED DSCP Val                : 0
  MED Location Data Format    : ECS ELIN
    Latitude Res      : 0
    Latitude          : 0
    Longitude Res     : 0
    Longitude         : 0
    AT                : 0
    Altitude Res      : 0
    Altitude          : 0
    Datum             : 0
    LCI length        : 0
    What              : 0
    Country Code      : 0
    CA type           : 0
  MED Inventory

6 Points of Caution

None

7 Related Documentation

• SNMP
• Terminal monitoring
• Dante optimization setting function
• VLAN
• LLDP automatic setting

LLDP automatic setting

1 Function Overview

The LLDP automatic setting function automatically sets settings based on information in LLDP notifications in proprietary LLDP frames sent and received between Yamaha switches and Yamaha wireless AP.

The following functionality can be achieved by LLDP automatic settings.

• RADIUS server automatic settings
  • This automatic specifies information about RADIUS servers currently operating at the Yamaha wireless AP in the Yamaha switch. That makes it easy to configure an authentication function in Yamaha wireless APs as a RADIUS server or in Yamaha switches as a RADIUS client.
• Yamaha wireless AP dead/alive monitoring
  • This uses LLDP to automatically monitor whether Yamaha wireless APs connected to the product are dead or alive.

To determine Yamaha switch and wireless AP models that support LLDP automatic setting function, refer to the following.

• Technical reference: LLDP automatic setting examples

2 Definition of Terms Used

LLDP

Link Layer Discovery Protocol。

This is defined in IEEE 802.1AB.

3 Function Details

3.1 Key specifications

If LLDP automatic setting function is enabled, proprietary LLDP frames will be sent and received between Yamaha switches and Yamaha wireless AP.

LLDP automatic settings are specified using the lldp auto-setting command.

LLDP automatic setting function is enabled in default settings.

In order to use this function, reception of LLDP frames must be enabled.

For this reason, check in advance that the following settings have been made.

• Enable LLDP functionality for the overall system using the lldp run command.
• Create LLDP agents at applicable interfaces using the lldp-agent command.
• Specify the LLDP frame transmit/receive mode using the set lldp command.

LLDP frame transmission and reception are enabled in product default settings.

3.2 RADIUS server automatic settings

This function automatically specifies information in the product about RADIUS servers currently operating at Yamaha wireless APs (clusters). That makes it easy to configure an authentication function in Yamaha wireless APs as a RADIUS server or in Yamaha switches as a RADIUS client.

Authentication settings for each port on the product must be set manually by the user based on the given environment. For more details about authentication settings, refer to Port authentication functions in the technical reference.

3.2.1 RADIUS server information sent by Yamaha wireless APs

Yamaha wireless APs send RADIUS server information based on the following criteria.

• LLDP and LLDP automatic settings are enabled
• Cluster functionality is enabled
• Cluster leader APs are functioning as a RADIUS server
• Cluster follower APs are functioning as RADIUS client that connects to a leader AP RADIUS server.

For details about Yamaha wireless AP settings, refer to the Yamaha wireless AP technical reference.

If the criteria for sending information are satisfied, Yamaha wireless APs send notifications with the following RADIUS server information at regular intervals.

• IP address of the RADIUS server
• UDP port number for RADIUS server authentication
• Shared password for communicating with RADIUS server

3.2.2 RADIUS server entry control

If the product LLDP automatic setting function is enabled and RADIUS server information is received from a Yamaha wireless AP, then a radius-server host command with an optional dynamic string added to the end is automatically specified in the running-config.

In the remaining explanation below, the radius-server host command appended by an optional dynamic string is referred to as a “dynamic entry”, whereas the manually specified radius-server host command is referred to as a “static entry”.

Dynamic entries appended with the optional dynamic string are not saved in the startup-config file, even if the write command is executed.

After dynamic entry is set by automatic settings, static entry can be set by manually deleting the dynamic option.

However, static entry cannot be changed to dynamic entry by manually adding the dynamic option.

• Example of Dynamic Entry of radius-server host Command

  radius-server host 192.168.100.241 auth-port 1234 key EXAMPLE dynamic
  

Dynamic entries specified by LLDP automatic settings are appended with LLDP reception port number and validity period information.

If identical RADIUS server information is received from multiple ports, the RADIUS server information received from the port with the smallest port number is retained.

The TTL (Time to Live) value included in the received LLDP frame is specified as the validity period.

The default TTL value for LLDP frames sent from Yamaha wireless APs is 120 seconds.

If new RADIUS server information is received within TTL seconds, then the validity period is updated, whereas if new RADIUS server information is not received within TTL seconds, then the dynamic entry is deleted.

However, if an LLDP shutdown frame with TTL = 0 is received, then the dynamic entry is immediately deleted.

The show radius-server command can be used to confirm RADIUS server information, with the automatically specified RADIUS server host marked with an asterisk and

the LLDP reception port number (LLDP received port) and validity period (Expires) information also listed.

• Example of using the show radius-server command to show dynamic entry information

  SWX#show radius-server
  Server Host : 192.168.100.241*
   LLDP Received port : port1.2
   Expires : 00:00:33
   Authentication Port : 1234
   Secret Key : EXAMPLE
   Timeout : 10 sec
   Retransmit Count : 5
   Deadtime : 0 min
  
  * - Assigned by LLDP.
  

A total of up to 8 RADIUS server information entries, including dynamic and static entries, can be specified for the product.

Using static entries is prioritized over using dynamic entries.

Therefore, even if the maximum number of RADIUS server information entries are already specified, new static entries can be specified if there are any dynamic entries among existing entries.

In that case, the dynamic entry with the highest LLDP reception port number is deleted.

3.2.3 Precautions

If the above functionality is used, note the following precautions.

• Connection to Yamaha wireless AP unit
  • To enable automatic setting of RADIUS server information, Yamaha switches must be connected directly to Yamaha wireless AP that support LLDP automatic setting functionality.
  • For Yamaha switches not directly connected to a Yamaha wireless AP, specify RADIUS server settings manually.
• Command input mode restrictions when the stack function is enabled
  • If the stack function is enabled, users permitted to transition to the global configuration mode are restricted. For details, refer to Stack function.
  • Because settings automatically transition to the global configuration mode if RADIUS server settings are received by LLDP from a Yamaha wireless AP and applied, users that are already in the global configuration mode via the console or who are in an individual configuration mode are forced to transition to the privileged EXEC mode.
• Characters permitted in shared passwords for communicating with RADIUS servers
  • Question mark and space characters cannot be used. Do not use those characters when setting shared passwords (RADIUS server, client, or secret) for Yamaha wireless AP units.
• Set response wait time for the entire RADIUS server
  • If multiple RADIUS servers are configured, set the auth timeout server-timeout command setting value, which sets the total wait time for all RADIUS servers, to a value equal to or larger than the product of the radius-server timeout command setting value times the radius-server retransmit command setting value plus one times the number of RADIUS servers. For command details, refer to the command reference.

3.3 Yamaha wireless AP dead/alive monitoring

When a Yamaha switch receives a request from a Yamaha wireless AP to start dead/alive monitoring, it automatically starts monitoring by LLDP whether the Yamaha wireless AP is dead or alive.

Yamaha wireless APs send dead/alive monitoring requests based on the following criteria.

• LLDP and LLDP automatic settings are enabled

If the dead/alive monitoring request is received with the LLDP automatic setting function enabled in the Yamaha switch, then an LLDP reception interval monitoring setting is registered for the LLDP reception port.

If no LLDP frame was received during a given period of dead/alive monitoring at the port where the setting was registered, then notification is sent that a communication interruption was detected at the SNMP trap and L2MS trap.

For details, refer to the technical reference for Terminal monitoring.

3.3.1 Precautions

If the above functionality is used, note the following precaution.

• If dead/alive monitoring is no longer necessary, such as after the Yamaha wireless AP connection port was changed, manually delete the settings that became unnecessary after the Yamaha wireless AP connection port was changed.

4 Related Commands

Related commands are indicated below.

For details, refer to the Command Reference.

List of related commands

5 Setting Examples

For instructions on how to configure respective Yamaha switch and wireless AP settings, function refer to the following.

• Technical reference: LLDP automatic setting examples

6 Points of Caution

See the precautions indicated for each function.

7 Related Documentation

• LLDP
• RADIUS server
• Port authentication functions
• Terminal monitoring
• Stack function
• Technical reference: LLDP automatic setting examples

Terminal monitoring

1 Function Overview

The terminal monitoring function checks the dead-or-alive state of specific terminals connected to the network switch.

The operating specifications for the terminal monitoring function are shown below.

Terminal monitoring function overview

Examples of an L2MS manager with an L3 switch and an L2MS agent with an intelligent L2 PoE switch are shown below.

As dead/alive monitoring methods, the following three types are provided.

1. Monitoring by ping

   Ping (ICMP Echo request/reply) is issued at regular intervals to a terminal that has an IP address, and the terminal is determined to be down if there is no longer a response.

   The user can specify the ping response wait time and the number of failures before the connection is determined to be down.

2. Frame reception amount monitoring

   The frame reception amount is monitored at regular intervals for an individual port, and the terminal is determined to be down if the traffic falls below a specified amount.

   The user can specify the monitoring start threshold value and the threshold value at which a down condition is determined.

   Monitoring starts when the traffic exceeds the monitoring start threshold value, and a down condition is determined when the traffic falls below the down decision threshold.

3. LLDP reception interval monitoring

   The LLDP received at regular intervals by an individual port is monitored.

   Using the TTL which is a required item in the data portion of an LLDP packet, a down condition is determined if LLDP is not received within the TTL interval.

If monitoring detects a terminal fault (down), the following processing is automatically performed.

1. Alert shown in dashboard screen

   An indication that a fault (down) occurred for the monitored terminal is displayed in the alert screen of the dashboard.

2. Alert shown in LAN map screen

   • If L2MS manager switch is used for terminal monitoring:

     An indication that a fault (down) occurred for the monitored terminal is shown in the LAN map notification and history information.

   • If L2MS agent switch is used for terminal monitoring:

     The L2MS trap function is used to notify the L2MS manager.

     When the L2MS manager receives a notification, it uses the LAN map screen to indicate an error (down) occurred in a monitored terminal.

By the user’s choice, the following operations can be applied in parallel.

1. Fault detection notification by mail

   Notification that a monitored terminal has experienced a fault is sent to the desired recipient.

2. Notification to the SNMP manager

   A trap is sent to the SNMP manager specified by a command.

3. Restart terminal by temporarily stopping the PoE power supply

   If a down condition is detected on a port to which PoE power is being supplied, PoE power supply is temporarily turned off in an attempt to recover the monitored terminal.

2 Definition of Terms Used

None

3 Function Details

3.1 Monitoring by ping (ICMP Echo request/reply)

Specifications for terminal monitoring by ping are given below.

1. The interval of ICMP Echo request transmission from the network switch is fixed at 5 seconds.
2. The ICMP Echo request that is transmitted has the following format.
   • As the ID field of the ICMP header, the unique ID assigned to each monitored terminal is specified.
   • As the sequence field of the ICMP header, a number that is sequentially incremented from 0 is specified.
3. The validity of the ICMP Echo reply is checked as follows.
   • Whether the ID field of the ICMP header contains the ID that was specified when sending the request
   • Whether the sequence field of the ICMP header contains the sequence number that was specified when sending the request
4. The wait time for ICMP Echo reply can be changed in the range of 1–60 sec, and the default is 2 sec.
5. The number of failures to receive the ICMP Echo reply from the monitored terminal after which a fault is determined can be set in the range of 1–100, and the default is twice.
6. Monitoring via ping can be done for a maximum of 64 units.
7. If sending an email notification or SNMP trap is enabled, they are sent in the following cases.
   • When a terminal is detected to be down (sent every 24 hours while down)
   • When a terminal is detected to be up (sent when monitoring is started or restored)

3.2 Monitoring by frame reception amount

The way in which this device monitors by frame reception amount is described below.

Overview of frame reception amount monitoring

1. At one-second intervals, the number of octets received at the port is referenced, and the number of octets received during one second is calculated.
   • All ports are the object of observation.
2. Using the number of octets received during one second and the link speed, the reception throughput (bps) and reception ratio (%) are calculated.
3. Monitoring by frame reception amount starts when the monitoring start threshold value (bps) specified by the user is exceeded.
4. After monitoring has started, a fault (down) is detected if the amount falls below the down detection threshold value (bps) specified by the user.
5. If sending an email notification or SNMP trap is enabled, they are sent in the following cases.
   • When a terminal is detected to be down
   • When a terminal is detected to be up (sent when monitoring is started or restored)

3.3 Monitoring by LLDP

1. Using the TTL which is a required item in the data portion of an LLDP frame, a down condition is determined if LLDP is not received within the TTL time.
2. Monitoring starts when an LLDP frame is first received.
3. This monitoring can be specified individually by port.
4. If sending an email notification or SNMP trap is enabled, they are sent in the following cases.
   • When a terminal is detected to be down
   • When a terminal is detected to be up (sent when monitoring is started or restored)
   • When a terminal stopped LLDP functionality

4 Related Commands

This function does not support settings via commands.

5. Settings via the Web GUI

Terminal monitoring settings can be done from [Advanced settings]-[Terminal monitoring] of the Web GUI.

Details on the settings in each screen can be referenced via the Web GUI help.

5.1 Terminal monitoring top page

The top page of terminal monitoring is shown below.

Terminal monitoring top page

• If you want to newly add a terminal for monitoring, press the New icon.
• If you want to change a currently-specified monitored terminal, press the [Setting] button in the list.

  If you want to delete a currently-specified monitored terminal, select the check box of that terminal, and press the [Delete] button.

• If you want to ascertain the current state of the monitored terminal for which you are making settings, press the [Update] button to acquire the latest state.

5.2 Adding or modifying a monitored terminal

The method for adding a new monitored terminal, or for making changes, is shown below for each method of monitoring.

1. Monitoring by ping

   

2. Monitoring frame input volumes

   

3. Monitoring LLDP receiving intervals

   

• Restart terminal by controlling PoE power supply can be specified only for models that support PoE power supply.
• Use the traffic observation function when deciding the monitoring start threshold value and the down detection threshold value settings for frame input volume monitoring.
• If you want mail notification to be sent in the event of a fault, you must separately make mail notification settings.

  For details, refer to Technical reference: [Maintenance and operation functions] - [Mail notification] and to Web GUI help: [Advanced settings] - [Mail notification].

5.3. Checking the state of a monitored terminal

The state of a specified monitored terminal can be checked in the terminal monitoring gadget of the dashboard.

Dashboard terminal monitoring gadget

• For each monitored terminal, this shows the monitoring target, model name, monitoring type, and status.
• The following three states are shown as the state of the monitored terminal.
  • Idle: Monitoring is not yet being performed:
  • Up: The monitored terminal is operating correctly:
  • Down: The monitored terminal is not operating correctly:
• When you place the mouse cursor on the status field, the status of the monitored terminal is shown.
• If you click the [Idle] , [Up], or [Down] button in the upper part of the dashboard, only the monitored terminals that are in the corresponding state are shown. (The [All] button shows terminals of all states.)
• If not even one monitor terminal is registered, the display indicates “No monitored terminals are registered.”

6 Points of Caution

None

7 Related Documentation

• Performance observation

Performance observation

1 Function Overview

This product provides a mechanism for constantly observing the system’s performance.

An overview of the function is given below.

Performance observation

This product constantly observes the following two types of data.

1. Resource usage: CPU and memory usage
2. Traffic amount: The amount of communication port bandwidth used (transmission/reception)

Based on the results of observation, one year’s worth of the following change data is accumulated inside this product.

• Hourly change: Change for each hour (e.g. 0:00, 1:00, ...)
• Daily change: Change for each day of each month (e.g. 1/1, 1/2, ...)
• Weekly change: Change for each day of the week (e.g. SUN, MON, ...)
• Monthly change: Change for each month (e.g. Jan, Feb, ...)

The accumulated data can be backed up to an SD card. By accessing this product via the Web GUI, the maintainer can view the various types of change data including live data in the dashboard, and can also acquire the accumulated result in a PC.

Since the acquired data is in CSV format, it can also be manipulated using spreadsheet software on a PC.

By using this function, the maintainer can accomplish the following:

• Ascertain the short-term communication status
• Predict long-term future demand for network facilities

2 Definition of Terms Used

None

3 Function Details

3.1 Resource and traffic usage observation

Starting immediately after boot, this device automatically observes the CPU and memory and the transmit/receive throughput of each port every second.

The observed data is normalized using a moving average, and one year of data is saved in RAM.

3.3 Observation data backup

Backup of observation data can be specified only in the Web GUI.

Backup of observation data assumes that an SD card is inserted in this device.

If backup is enabled, the most recent hour of observation data every hour starting at the point it was enabled (e.g., 1:00, 2:00 ...) is saved on the SD card.

The saved data is dedicated binary data of this device.

The save-destination on the SD card and the file name of the backup data file are as follows.

1. Resource information

   1. Hourly change data

      /[model name]/data/resource/YYYYMM_smsys_res_monitor_hour.bin

   2. Daily change data (data for each day)

      /[model name]/data/resource/YYYYMM_smsys_res_monitor_day.bin

   3. Weekly change data

      /[model name]/data/resource/YYYYMM_smsys_res_monitor_week.bin

   4. Monthly change data

      /[model name]/data/resource/YYYY_smsys_res_monitor_month.bin

2. Traffic information

   1. Hourly change data

      /[model name]/data/trf/YYYYMM_trf_bandwidth_hour.bin

   2. Daily change data

      /[model name]/data/trf/YYYYMM_trf_bandwidth_day.bin

   3. Weekly change data

      /[model name]/data/trf/YYYYMM_trf_bandwidth_week.bin

   4. Monthly change data

      /[model name]/data/trf/YYYY_trf_bandwidth_month.bin

• [Model name] is the following.
  • For the SWX2320-16MT: swx2320
  • For the SWX2322P-16M: swx2322p
  • For the SWX3220-16MT/16TMs : swx3220
• YYYY: year, MM: month are specified.
• Since this is a proprietary Yamaha format, it cannot be referenced.

3.4. Observation data export

Export of observation data to a PC can be executed only in the Web GUI.

As with backup data, export of observation data to a PC assumes that an SD card is inserted in this device.

The exported data is multiple CSV files compressed in zip format. The structure of the compressed files are given below.

1. When resource observation data is exported
   • zip file name: YYYYMMDDhhmmss_resource_csv.zip
   • Folder structure

   YYYYMMDDhhmmss_resource_csv
       +- 20170922_resource_hour.csv ... (CPU and memory data for each hour of 2017/9/22)
       +-     :
       +- 20170925_resource_hour.csv ... (CPU and memory data for each hour of 2017/9/25)
       +- 201709_resource_day.csv    ... (CPU and memory data for each day of 2017/9)

2. When transmission traffic observation data is exported
   • zip file name: YYYYMMDDhhmmss_trf_tx_csv.zip
   • Folder structure

   YYYYMMDDhhmmss_trf_tx_csv
       +- 20170922_trf_tx_hour.csv  ... (Transmission traffic data for each hour of 2017/9/22)
       +-     :
       +- 20170925_trf_tx_hour.csv  ... (Transmission traffic data for each hour of 2017/9/25)
       +- 201709_trf_tx_day.csv     ... (Transmission traffic data for each day of 2017/9)

3. When reception traffic observation data is exported
   • zip file name: YYYYMMDDhhmmss_trf_rx_csv.zip
   • Folder structure

   YYYYMMDDhhmmss_trf_rx_csv
       +- 20170922_trf_rx_hour.csv  ... (Reception traffic data for each hour of 2017/9/22)
       +-     :
       +- 20170925_trf_rx_hour.csv  ... (Reception traffic data for each hour of 2017/9/25)
       +- 201709_trf_rx_day.csv     ... (Reception traffic data for each day of 2017/9)

• YYYYMMDDhhmmss specifies the date and time at which export was executed (the date and time that the file was generated).

4 Related Commands

This function does not support settings via commands.

5. Settings via the Web GUI

Performance observation can be controlled from the following pages of the Web GUI.

• Viewing the resource usage amount
  • This can be viewed in the [Dashboard] item [Resource information (graph)].
• Viewing the traffic usage amount
  • This can be viewed in the [Dashboard] item [Traffic information (graph)].
• Backing up, clearing, or exporting observation data
  • Select [Management], and then use [Maintenance] - [Summary data management] to make these settings.

Details on how to view and make settings in each screen can be referenced via the Web GUI help.

5.1 Viewing the resource usage amount

The resource information (graph) screen is shown below.

Example when Live is selected for resource information (graph)

1. The graph rendering can be changed using the following buttons.

   • Current status: [Live]

     The various current usage ratios are obtained at one-second intervals and shown on the graph.

   • Hourly change: [Day]

     The various usage ratios for the specified day are shown at one-hour intervals on the graph.

     To specify the day, use the day-specifying box in the upper right of the gadget.

   • Daily change: [Month]

     The various usage ratios for the specified month are shown at one-day intervals.

     To specify the month, use the month-specifying box in the upper right of the gadget.

   • Monthly change: [Year]

     The various usage ratios for the specified year are shown at one-month intervals.

     To specify the year, use the select box in the upper right of the gadget.

   • It is not currently possible to reference changes in the day of the week.
2. If the CPU and memory usage ratios exceed 80%, then a warning message is shown on the dashboard.

   If the ratio falls below 80% after having exceeded 80%, the warning is automatically cleared.

5.2 Viewing the traffic usage amount

The traffic usage amount (graph) screen is shown below.

Example of when traffic usage amount (graph) Day is selected / Example of transmission traffic

1. The traffic usage amount of each port can be shown separately for transmission and reception.
2. The graph rendering can be changed using the following buttons.

   • Current status: [Live]

     The various current usage ratios are obtained at one-second intervals and shown on the graph.

     The most recent two minutesof the obtained data is held and rendered on the graph.

   • Hourly change: [Day]

     The various usage ratios for the specified day are shown at one-hour intervals on the graph.

     To specify the day, use the day-specifying box in the upper right of the gadget.

   • Daily change: [Month]

     The various usage ratios for the specified month are shown at one-day intervals.

     To specify the month, use the month-specifying box in the upper right of the gadget.

   • Monthly change: [Year]

     The various usage ratios for the specified year are shown at one-month intervals.

     To specify the year, use the select box in the upper right of the gadget.

   • It is not currently possible to reference changes in the day of the week.

3. To select the interface to be shown, click the interface select button (), and then make a selection in the following screen.

   
4. If the traffic usage ratio exceeds 60%, a warning message is shown on the dashboard. If the ratio falls below 50% after having exceeded 60%, the warning is automatically cleared.

5.3 Backing up, clearing, or exporting observation data

Backup, clearing, and exporting of observation data is performed from [Management] - [Maintenance] - [Summary data management].

The Summary data management screen is shown below.

Summary data management screen (top page)

5.3.1 Observation data backup settings

Backup settings for observation data are performed from [Top page] - [Backup settings for summary data].

The screen that appears when you press the [Settings] button is shown below.

• Observation data backup settings screen

  

• Place a check mark in the check box of the summary data for which you want to enable backup, and then press the [Confirm] button.

  After you press the button, the following screen appears.

  
• If you decide to cancel this setting, press the [Back] button in each screen.

5.3.2 Clearing observation data

Clearing the observation data is performed from [Top page] - [Clearing summary data].

The screen that appears when you press the [Next] button is shown below.

• Clear observation data screen

  

• In the select box, choose the statistical data that will be cleared, and press the [Confirm] button. After you press the button, the following screen appears.

  

• If you decide to cancel this operation, press the [Back] button in each screen.

5.3.3 Exporting observation data

Exporting observation data is performed from [Top screen] - [Export summary data].

The screen that appears when you press the [Next] button is shown below.

• Observation data export screen

  

• From the select box, choose the observation data that you want to export to the PC that is accessing the Web GUI, and then specify the term of observation data that you want to export.

  After making the selection, press the [OK] button, and the following screen will appear.

  
• If you decide to cancel this operation, press the [Back] button in each screen.

6 Points of Caution

None

7 Related Documentation

None

Scheduling function

1 Function Overview

Scheduling functionality is used to execute specific processes when any particular time or event occurs.

This functionality enables the following types of actions using a Yamaha switch.

• Apply QoS to a specific VLAN only during a specific period.
• Supplies PoE power to wireless LAN access points only during the specified period.
• Periodically saves “tech-support” information in microSD memory.

  

2 Definition of Terms Used

Trigger

General term for conditions/criteria, such as that the internal clock time matches a specified time or that a specific event occurs.

Time Trigger

Condition that the internal clock time matches a specified time.

Event Trigger

Condition that a specific event occurs.

Action

Action executed when a trigger is activated.

3 Function Details

Scheduling functionality involves specifying triggers and actions, which are the two parameter settings for executing specific process actions when a particular specified time or event trigger occurs.

3.1 Time Trigger

Time triggers can be specified in terms of year, month, day, hour, minute, and second.

Time triggers are specified using the schedule command.

Available setting parameters are indicated below.

3.2 Event Triggers

Either of the following events can be specified as an event trigger.

Event triggers are specified using the schedule command.

Events that can be specified are indicated below.

3.3 Actions

Processes executed when a time trigger or event trigger is activated are called actions.

To specify actions, use the schedule template command to switch to the schedule template mode and then specify the action using the cli-command command or script command.

The following two actions are available.

4 Related Commands

Related commands are indicated below.
For details on the commands, refer to the Command Reference.

List of related commands

5 Setting Examples

5.1 Supplying PoE Power to Wireless LAN Access Points Only During Specified Hours

Supply PoE power to wireless LAN access points connected to port1.1 and port1.2 on weekdays only between 8:00 and 17:00.

Yamaha#
Yamaha# configure terminal
Yamaha(config)# schedule 1 time */mon-fri 8:00:00 1
Yamaha(config)# schedule template 1 
Yamaha(config-schedule)# cli-command 1 configure terminal
Yamaha(config-schedule)# cli-command 2 interface port1.1-2
Yamaha(config-schedule)# cli-command 3 power-inline enable
Yamaha(config-schedule)# exit
Yamaha(config)#
Yamaha(config)# schedule 2 time */mon-fri 17:00:00 2
Yamaha(config)# schedule template 2
Yamaha(config-schedule)# cli-command 1 configure terminal
Yamaha(config-schedule)# cli-command 2 interface port1.1-2
Yamaha(config-schedule)# cli-command 3 power-inline disable
Yamaha(config-schedule)# end
Yamaha#

5.2 Obtaining Internal Information when microSD Memory is inserted

Automatically saves tech-support in microSD memory when microSD card is inserted.

Yamaha#
Yamaha# configure terminal
Yamaha(config)# schedule 1 event sd-attached 1
Yamaha(config)# schedule template 1
Yamaha(config-schedule)# cli-command 1 copy tech-support sd
Yamaha(config-schedule)# end
Yamaha#

6 Unavailable Commands

The following commands cannot be executed for the schedule function.

• backup system
• baudrate select
• boot prioritize sd / no boot prioritize sd
• certificate user
• Commands that begin with “clock”
• cold start
• copy radius-server local
• crypto pki generate ca / no crypto pki generate ca
• disable
• enable password
• exit
• firmware-update execute
• firmware-update sd execute
• logout
• Commands that begin with “ntpdate” or “no ntpdate”
• password / no password
• password-encryption / no password-encryption
• ping /ping6
• quit
• reload
• remote-login
• restart
• restore system
• schedule / no schedule
• schedule template / no schedule template
• Commands that begin with “show”
• ssh
• ssh-server host key generate
• Commands that begin with “stack” or “no stack”
• startup-config select / no startup-config select
• telnet
• traceroute / traceroute6

7 SYSLOG

The schedule function outputs the following syslog messages.

8 Points of Caution

• When actions are executed, the cli-command executes actions in ascending ID number order.
• When actions are executed, even a command specified by the cli-command results in an execution error, the remaining commands are executed.
• If both a cli-command and script command are specified in the same schedule template, then the script command is executed and the cli-command is not executed.
• If multiple triggers are activated simultaneously, then actions are executed in ascending order of schedule template ID number.
• The following precautions apply for devices that include a stack.
  • A “startup” event trigger is not activated in stack member switches.
  • A “sd-attached” event trigger is not activated in stack member switches.
• The trigger is not activated if a stack is enabled and is in the standalone state.
• If the trigger activation time elapses due to the time setting being set manually by the clock set command or being changed by NTP, then any existing triggers scheduled to be activated within 59 seconds of when the current time setting was changed will be activated.
• If the trigger activation time was changed backward manually by the clock set command or by NTP, then the time triggers are checked again starting from the time to which it was set back.
• This function can be used to periodically save the configuration, but periodic rewriting will consume ROM capacity more quickly. ROM failures due to frequent rewriting are not warranted for free repairs, even if they occur during the warranty period.

9 Related Documentation

• None

Dante optimization setting function

1 Function Overview

Dante optimization settings is a function that makes it easy to specify the optimal environment for the Dante digital audio network.

This allows the user to easily make settings such as QoS settings, IGMP snooping settings, flow control disable settings, and EEE disable settings.

The following items can be set using the Dante optimization setting function.

Use the Dante optimization setting function after you have made all of the basic switch settings (such as VLAN and IP).

If you make new changes to the settings, the Dante optimization settings will not follow.

2 Definition of Terms Used

Dante

A digital audio network specification developed by the Audinate Corporation.

3 Function Details

This function provides the following operations.

• Automatic optimization settings using LLDP
• Manual optimization settings via the Web GUI

3.1 Automatic optimization settings using LLDP

By receiving special LLDP frames from certain Dante-enabled devices made by Yamaha, optimal settings for using Dante can be automatically applied.

Automatic optimization settings via LLDP are set by the lldp auto-setting command.

By default, this product is set to enable automatic optimization settings via LLDP.

Certain Dante-enabled devices made by Yamaha transmit Yamaha-proprietary LLDP frames that include the following content.

• EEE (Energy-Efficient Ethernet) disable setting
• Flow control disable setting
• Diffserve base QoS setting
• IGMP snooping setting

If this function is enabled and the corresponding LLDP frame is received, the following settings are automatically applied to running-config.

[System-wide]

flowcontrol disable ... (Disable flow control)
qos enable ... (Enable QoS)
qos dscp-queue 0 0 ... (Set the DSCP-transmission queue ID conversion table; same for the following)
qos dscp-queue 1 0
qos dscp-queue 2 0
qos dscp-queue 3 0
qos dscp-queue 4 0
qos dscp-queue 5 0
qos dscp-queue 6 0
qos dscp-queue 7 0
qos dscp-queue 8 2
qos dscp-queue 9 0
qos dscp-queue 10 0
qos dscp-queue 11 0
qos dscp-queue 12 0
qos dscp-queue 13 0
qos dscp-queue 14 0
qos dscp-queue 15 0
qos dscp-queue 16 0
qos dscp-queue 17 0
qos dscp-queue 18 0
qos dscp-queue 19 0
qos dscp-queue 20 0
qos dscp-queue 21 0
qos dscp-queue 22 0
qos dscp-queue 23 0
qos dscp-queue 24 0
qos dscp-queue 25 0
qos dscp-queue 26 0
qos dscp-queue 27 0
qos dscp-queue 28 0
qos dscp-queue 29 0
qos dscp-queue 30 0
qos dscp-queue 31 0
qos dscp-queue 32 0
qos dscp-queue 33 0
qos dscp-queue 34 0
qos dscp-queue 35 0
qos dscp-queue 36 0
qos dscp-queue 37 0
qos dscp-queue 38 0
qos dscp-queue 39 0
qos dscp-queue 40 0
qos dscp-queue 41 0
qos dscp-queue 42 0
qos dscp-queue 43 0
qos dscp-queue 44 0
qos dscp-queue 45 0
qos dscp-queue 46 5
qos dscp-queue 47 0
qos dscp-queue 48 0
qos dscp-queue 49 0
qos dscp-queue 50 0
qos dscp-queue 51 0
qos dscp-queue 52 0
qos dscp-queue 53 0
qos dscp-queue 54 0
qos dscp-queue 55 0
qos dscp-queue 56 7
qos dscp-queue 57 0
qos dscp-queue 58 0
qos dscp-queue 59 0
qos dscp-queue 60 0
qos dscp-queue 61 0
qos dscp-queue 62 0
qos dscp-queue 63 0

[VLAN interface that received LLDP]

interface vlanX *Applies to the VLAN
  ip igmp snooping enable ... (Enable IGMP snooping)
  ip igmp snooping query-interval 30 ... (Set query transmission interval)
  ip igmp snooping querier ... (Set query)
  ip igmp snooping check ttl disable ... (Disable IGMP packet TTL value checking function)

[LAN/SFP port that received LLDP]

interface portX.X
  qos trust dscp ... (Set DSCP trust mode)
  flowcontrol disable ... (Disable flow control)
  eee disable ... (Disable EEE)

If you save using the copy running-config startup-config command or the write command, the settings are also applied to the startup-config that is used for the next and subsequent startups.

Even if the port to which the device is connected experiences a link-down state after automatic optimization settings, the automatically added settings are maintained.

This function can be used only for a physical interface (LAN/SFP port). It cannot be used with a link aggregated logical interface.

This does not apply to the trunk port.

In order to use this function, reception of LLDP frames must be enabled.

For this reason, check in advance that the following settings have been made.

• Use the lldp run command to enable the system-wide LLDP function.
• Use the lldp-agent command to create an LLDP agent for the applicable interface.
• Use the set lldp command to specify the LLDP frame transmit/receive mode.

With the default settings of this product, LLDP frame transmission and reception is enabled.

3.2 Manual optimization settings via the Web GUI

The Web GUI of this product allows you to manually specify Dante optimization settings and to enable/disable automatic settings using LLDP.

If manual settings are executed, the settings shown in 3.1 Automatic optimization settings via LLDP are specified for all LAN/SFP ports and VLAN interfaces.

In addition, the no shutdown command is set for the VLAN interface.

Dante optimization settings are performed from [Management] - [Dante optimization].
The Dante optimization screen is shown below.

Dante optimization screen (top page)

To execute manual settings, press the [Next] button for Manual settings.

To enable/disable automatic settings, press the [Setting] button for Automatic settings using LLDP.

3.2.1 Manual settings

The screen that appears when you press the [Next] button for Manual settings is shown below.

Manual settings - execution screen

To execute manual settings, press the [OK] button.

3.2.2 Auto-configure via LLDP

The screen that appears when you press the [Setting] button for Auto-configure via LLDP is shown below.

Auto-configure via LLDP - execution screen

To enable/disable the automatic setting function using LLDP, select the [Enable] or [Disable] radio button, and then press the [Confirm] button.

The screen that appears when you press the [Confirm] button is shown below.

Auto-configure via LLDP - confirmation screen

To enable/disable automatic settings using LLDP, press the [OK] button.

4 Related Commands

Related commands are shown below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Examples of Command Execution

5.1 Automatic optimization settings using LLDP

Enable automatic optimization settings using LLDP.

Enable LLDP transmission and reception on port1.1.

Yamaha#configure terminal
Yamaha(config)#interface port1.1
Yamaha(config-if)#lldp-agent ... (Create LLDP agent and transition modes)
Yamaha(lldp-agent)#set lldp enable txrx ... (Set LLDP transmission/reception mode)
Yamaha(lldp-agent)#exit
Yamaha(config-if)#exit
Yamaha(config)#lldp run ... (Enable LLDP function)
Yamaha(config)#lldp auto-setting enable ... (Enable automatic optimization settings using LLDP)

6 Points of Caution

• Note that if you use this function when settings such as QoS settings, flow control settings, EEE settings, and IGMP snooping have already been made, those settings are overwritten by Dante-optimized settings.
• It is assumed that you will use the Dante optimization setting function after you have made all of the basic switch settings (such as VLAN and IP).
  If you make new changes to the settings (such as adding a VLAN), the Dante optimization settings will not follow.
• The setting values requested from Dante-enabled devices must be consistent between all devices. If the values are different, operation cannot be guaranteed.
• In general, IGMP snooping operates as version “3”.

7 Related Documentation

• LLDP
• QoS
• Flow control
• IGMP Snooping
• Interface basic functions

SDVoE setting optimization function

1 Function Overview

The SDVoE setting optimization function can be used to easily optimize settings for Software Defined Video over Ethernet (SDVoE).

More specifically, it enables users to easily specify multicasting settings and IGMP snooping settings.

The following settings can be set using the SDVoE setting optimization function.

Use the SDVoE setting optimization function after all basic switch settings (such as VLAN and IP address settings) have been specified.

The SDVoE setting optimization function will not track new changes to settings.

2 Definition of Terms Used

• SDVoE

  An AV standard for using software to transmit AV signals via an IP address.

3 Function Details

The function is available by clicking [Management] - [SDVoE optimization] in the Web GUI.

Press the Next button to display the execution screen.

Press the Execute button to apply the settings optimized for SDVoE.

Executing the SDVoE setting optimization function will specify the following commands and save the settings.

• [System-wide]

  l2-unknown-mcast discard ... (Discard multicasting frames not registered in the MAC address table)

• [VLAN interface]

  interface vlanX Note: Applies to all enabled VLANs 
    no shutdown                        ... (Enable VLAN interface) 
    ip igmp snooping enable            ... (Enable IGMP snooping) 
    ip igmp snooping version 2         ... (Specify IGMP version 2) 
    ip igmp snooping fast-leave        ... (Enable IGMP snooping fast-leave) 
    ip igmp snooping query-interval 60 ... (Set IGMP query interval to 60 seconds) 
    ip igmp snooping querier           ... (Enable IGMPquery transmission function)
   

4 Related Commands

Related commands are indicated below.

For details on the commands, refer to the Command Reference.

List of related commands

5 Points of Caution

• This function cannot be used if the stack function is enabled.
• Note that if this function is used while IGMP snooping or other settings are specified, the SDVoE setting optimization function will overwrite those settings.
• The SDVoE setting optimization function assumes all other basic switch settings (such as VLAN and IP address settings) have already been specified.

  If new changes were made (such as additional VLANs), the optimized SDVoE settings are not tracked.

6 Related Documentation

• IGMP Snooping

Back to home

Stack function

1 Function Overview

A stack is a function that connects multiple switches and operates as a single virtual switch.

The features of the stack are shown below.

1. Realization of highly efficient redundancy

   There are two methods for removing single points of failure (SPOF) in the network configuration: the method composed of VRRP and STP, and the method composed of stack and link aggregation.

   By using the stack, unlike VRRP, there is no standby switch, so you can increase the usage efficiency of the switch while ensuring redundancy.

2. Easy port expansion

   You can easily increase the number of available ports by adding switches.

Stack overview

The stack function is disabled when shipped from the factory.

2 Definition of Terms Used

Member switch

Network switches that make up the stack.

Each switch is identified by a stack ID.

Stack ID

An ID that identifies the member switches that make up the stack.

The stack ID can be set from 1 to the maximum number of stacks that can be configured (currently 2).

Main switch

The main switch is selected from among member switches for managing other member switches.

Given default settings, the switch with stack ID 1 operates as the main switch.

Virtual switch

A single logical switch consisting of multiple member switches using the stack function.

Stack port

SFP+ slot used to connect the network switches that make up the stack.

Stack link

A connection between member switches that make up a stack.

3 Function Details

3.1 Stack configuration

The configurations that can be stacked for each model are shown below.

Only two units of the same model are supported.

Note that the stack must be configured with two stack links in order to reduce the impact of failure.

SWX2320-16MT stack configuration

SWX2322P-16MT stack configuration

SWX3220-16MT stack configuration

SWX3220-16TMs stack configuration

3.2 Connection between member switches

When the stack function is enabled, the following SFP+ slots are switched to stack ports as connecting ports between members.

• SWX2320-16MT: ports 15, 16
• SWX2322P-16MT: ports 15,16
• SWX3220-16MT: ports 15, 16
• SWX3220-16TMs: ports 15,16

Unlike normal communication ports, stack ports are used only for communication between member switches.

Connection between member switches is only possible with the direct attach cable (YDAC-10G-1M/3M) or SFP+ module (YSFP-10G-SR/LR) provided by Yamaha.

When connecting with another company’s product, the stack link will be forced down.

The stack port to be connected connects the lower number port and the higher number port of the member switch.

3.3 Main switch selection and MAC address assignment

The main switch selection and MAC address assignment rules are shown below.

Note that the MAC address used in the stack configuration is applied according to the following rules in order to eliminate the impact on communication.

1. In the default stack configuration, the MAC address of the main switch (switch with ID 1) is used as the MAC address for the virtual switch.
2. If a member switch other than the main switch is disconnected (due to an error) during stack configuration, then the virtual switch will continue to use the specified MAC address.
3. If the main switch is disconnected (due to an error) during stack configuration, the virtual switch will continue to use the specified MAC address.

   In other words, the MAC address of the switch that is not included in the stack configuration is used.

4. Even when a switch other than the failed switch (a switch with a different MAC address) is installed as a member switch, the virtual switch continues to use the configured MAC address.

   If you want to reconfigure the stack with the current configuration status, restart the virtual switch at the same time to perform reconstruction.

   (The stack with ID 1 becomes the main switch and the virtual switch uses the MAC address of the main switch.)

Main switch selection and MAC address assignment

No	Stack configuration		Main switch selection rule
1	Initial composition		The stack with ID 1 specified is selected as the main switch. At this time, the MAC address of stack ID 1 is used as the virtual switch MAC address.
2	Fault occurrence		If an error occurs in the main switch, the member switch with the smallest stack ID number is selected as the main switch. At this time, the virtual switch MAC address retains the MAC address of stack ID 1.
3	Abnormal state recovery		If a switch with a failure is reinstalled in the stack, the switch currently selected as the main switch will continue to function as the main switch. At this time, the virtual switch MAC address retains the MAC address of the faulty stack ID 1.

3.4 Operations on virtual switches

Operations on virtual switches in a stack configuration are basically controlled from the master switch.

The specifications related to operation are shown below.

1. Logging in to a virtual switch always logs into the main switch.
   If necessary, the remote-login command can be used to log into another member switch.
   • Prompt when logging in to main switch

     Yamaha>

   • Prompt when logging in to member switch

     Yamaha-2> ... (Stack ID is displayed after the host name)

2. The configuration (running-config, startup-config) for the virtual switch is always synchronized between member switches.

   After completing the configuration, be sure to save running-config with the write command.

   The write command can only be executed from the main switch side.

3. When operating a virtual switch, the information stored in the L2 network switch (e.g. FDB learning information, ARP cache, etc.) is automatically synchronized.

   There is no need for the user to be aware of this.

4. Use the show logging command to show logging for the virtual switch after logging in.

   In that state, the log shown is for the main switch. To view the log for a member switch, use the remote-login command to log into the applicable member switch and view the corresponding log.

3.5 Switch status when stacking

The member switch manages the status in the stack configuration as follows.

This state can be shown using the show stack command.

1. Setting

   • A state in which one or more stack port links are up, and the settings necessary for stacking between member switches are performed.

     Specifically, the configuration is automatically ascertained between member switches.

2. Active

   • A state in which automatic recognition of the configuration between member switches is completed, various settings are synchronized, and virtualization is performed by multiple member switches.

     Virtualization is performed by two or more switches.

3. Inactive

   • A state in which a failure has occurred and the virtual switch has been removed.

     All communication ports including the stack port are forcibly shut down and communication cannot be established. (Closed state)

4. Standalone

   • The stack function is enabled, but since negotiation cannot be performed with the member switch, it is operating on one unit.

     Transition to this state occurs when there is no opposing switch temporarily, such as during initial installation.

     In this state, the stack ID that has been set must be enabled, so it is operated with the set ID.

5. Standalone(separated)

   • Same status as Standalone status indicated above.

     However, it remembers that a stack was once configured, so it retains main switch selection information that can be used when reconfiguring the stack.

6. Disable

   • The stack function is disabled.

     In this state, the stack ID is forcibly operated at 1. (Even if the stack ID is set to other than 1)