Support

What are the two methods to manage a switch

You can manage a switch through a web system or a CLI. The CLI enables you to implement fine-grained device management through commands. However, you must be familiar with the command syntax and understand how the CLI operates. The web system provides only basic routine maintenance and management functions. You can use the CLI or web system according to your management requirements.

To use the CLI, you must log in to the switch through a console port or a mini USB port, or using Telnet or STelnet. To use the web system, you must log in to the switch through HTTPS.

Today, we are about to talk CLI and WebUI to manage a switch.

Command Line Interface (CLI):

There are four CLI access methods: console port (serial interface), mini USB port, Telnet, and STelnet. After logging in to the CLI of a switch, you can run the commands provided by the switch to manage and configure the switch. Typically, a user interface is required for each access method. Before using the CLI, configure a user page for the corresponding login mode.

Compares the four CLI login methods:

Login Method Advantage Disadvantage Applicable Scenario Description
Login Through the Console Port A dedicated console cable is used for effective device control. You cannot remotely log in to a switch to maintain it. ·         You need to configure a switch that is powered on for the first time.

·         You cannot remotely log in to a switch.

·         A switch fails to start and you need to enter the BootROM menu to diagnose the fault or upgrade the switch.

Console port login is the basis for other login methods.

By default, you can log in to a switch through the console port and have the user level of 15 after login.

Login Through the Mini USB Port If no console port is available on a PC, you can use a mini USB cable to connect the USB port on the PC to the mini USB port of a switch and then log in to the switch for effective control. You cannot remotely log in to a switch to maintain it. You need to configure a switch that is powered on for the first time but no console port is available on your PC. The device connection method for mini USB port login is different from that for console port login but the communication parameters during login and configurations after login are the same.
Login Through Telnet ·         Facilitate remote management and maintenance of switches.

·         You do not need to connect each switch to a terminal, simplifying operations.

Data is transmitted using TCP in plain text, posing potential security risks. You need to configure a switch remotely on a network that does not require high security. By default, you cannot log in to a switch directly using Telnet. Before using Telnet to log in, you must locally log in to the switch through the console port or mini USB port.
Login Through STelnet Provide secure remote login on insecure networks, ensuring data integrity and reliability, and securing data transmission.

NOTE:

SSH in this document refers to SSH 2.0 unless otherwise stated.

The configuration is complex. You need to configure a switch remotely on a network that requires high security. By default, you cannot log in to a switch directly using STelnet. Before using STelnet to log in, you must locally log in to the switch through the console port or mini USB port or remotely log in using Telnet.

Web system

The web system is a GUI-based device-management tool that helps provision the device, simplify device deployment and manageability, and improve user experience. You can use the Web system to build configurations, and monitor and troubleshoot the device without having CLI expertise. The web system provides only basic maintenance and management functions. You still need to use the CLI to implement fine-grained management.

Concepts involved in web system login are described as follows:

  • HTTP

Hypertext Transfer Protocol (HTTP) is used to transfer web page files over the Internet. It runs at the application layer of the TCP/IP protocol stack. The transport layer uses the connection-oriented TCP protocol. Due to the security vulnerability of HTTP, devices only allow you to log in to the web system through the more secure Hypertext Transfer Protocol Secure (HTTPS).

  • HTTPS

HTTPS uses secure sockets layer (SSL) to encrypt data exchanged between the client and device and defines access control policies based on certificate attributes. HTTPS enhances data integrity and transmission security, ensuring that only authorized clients can log in to the device.

  • SSL policy

An SSL policy defines parameters that the device uses during startup. Before HTTPS configuration, the SSL policy needs to be deployed and the corresponding digital certificate is loaded on the device. The SSL policy takes effect only after it is applied to application layer protocols, such as HTTP.

  • Digital certificate

A digital certificate is issued by a certificate authority (CA) and uses a digital signature to bind a public key with an identity (applicant who possesses the certificate). The digital certificate includes information such as the applicant name, public key, digital signature of the CA, and validity period of the digital certificate. Digital certificates validate the identities of two communicating parties to improve communication reliability.

  • CA

A CA issues, manages, and revokes digital certificates by checking the validity of digital certificate owners, issuing digital certificates to prevent eavesdropping and tampering, and managing keys. A worldwide trusted CA is called a root CA. The root CA can authorize other CAs as subordinate CAs. CA identity needs to be verified and is described in a trusted-CA file.

For example, CA1 is a root CA. It issues a certificate for CA2, which can then issue a certificate for CA3. This process continues until the final server certificate is issued.

Assume that CA3 issues the server certificate. A certificate authentication process on the client starts from server certificate authentication:

  • The client first verifies the validity of the server certificate based on the CA3 certificate.
  • The client then checks the CA2 certificate to verify the validity of the CA3 certificate.
  • The client then checks the CA1 certificate to verify the validity of the CA2 certificate.
  • The server certificate passes the authentication only if the CA2 certificate is verified as being valid according to the CA1 certificate.

The below picture shows the certificate issuing and authentication processes.

Web System Login of Switch

  • Certificate Revocation List (CRL)

A CRL is issued by a CA and specifies a list of certificates that have been revoked.

Each digital certificate has a limited lifetime and a CA can revoke a digital certificate to shorten its lifetime. The validity period of a certificate specified in the CRL is shorter than the original validity period of the certificate. If a CA revokes a digital certificate, the key pair defined in the certificate can no longer be used even if the digital certificate has not expired. When a certificate expires, it is deleted from the CRL.

You can load the CRL and a certificate (trust certificate) with a higher level than the digital certificate on your PC. If not loaded, you are prompted to trust the server when establishing a connection with a web server. After the connection is established successfully, the PC cannot immediately verify the digital certificate on the server. However, data transmitted between the PC and server is confidential. To ensure that you are connecting to a valid web server, you can load a trust certificate and CRL on the PC.

For details on how to load trust certificates, please contact with sales@thunder-link.com

Related Posts