Some Channel Indicators on S9700’s Stack Card Are in Abnormal State

Issue Description

As shown in the following figure, two Huawei S9700s set up a cluster through stack cards. The configurations are correct and switches run stably. When the cluster runs for a long time, the indicators on stack cards are in abnormal state.
QQ图片20171123094129
Alarm Information

Log in to a switch. The following Up/Down alarm is generated on the switch:

QQ图片20171123094202

Handling Process

Collect and save device information with the permission of customer.

1. Log in to a switch to view cluster information. The information is abnormal:

QQ图片20171123094233

  1. Interchange the cables on channels 1 and 2 of active chassis card A with the cables on channels 1 and 2 of active chassis card B. Interchange the cables on channels 3 and 4 of standby chassis card A with the cables on channels 3 and 4 of standby chassis card B. Ensure correct connection sequence.

    − If the alarm persists and the indicators on ports 1 and 2 of active chassis card B and on ports 3 and 4 of standby chassis card B are off, the cluster cable is faulty. Replace the cable.
    − If the alarm persists and the indicators on ports 1 and 2 of active chassis card A and on ports 3 and 4 of standby chassis card A are off, the cluster card is faulty. Go to the next step.

    3. Undo all cluster-related commands and power off switches. Interchange cards A and B on active chassis and correctly connect cluster cables. Power on the switches and reconfigure the cluster functions.

    − If the alarm persists and the indicators on ports 1 and 2 of active chassis card B and on ports 3 and 4 of standby chassis card B are off, channels 1 and 2 on the original active chassis card A fail. Replace the stack card.
    − If the alarm persists and the indicators on ports 1 and 2 of active chassis card A and on ports 3 and 4 of standby chassis card A are off, go to the next step.

    4. Undo all cluster-related commands and power off switches. Interchange cards A and B on standby chassis and correctly connect cluster cables. Power on the switches and reconfigure the cluster functions. If the alarm persists and the indicators on ports 1 and 2 of active chassis card B and on ports 3 and 4 of standby chassis card B are off, channels 3 and 4 on the original standby chassis card A fail. Replace the stack card.

Root Cause

A stack card has a hardware fault.

Solution

Replace the stack card.

Suggestions

If the log cannot help you locate the fault, minimize the fault scope to locate the failure point.

Advertisements

The time of syslog on Network Management is 8 hours later than the local time of device

Issue Description

QQ图片20171117104012

The time of syslog on Network Management is 8 hours later than the local time of the device

Alarm Information

None

Handling Process

Add the following command to change the syslog time sending to Network Management:
[huawei]info-center loghost x.x.x.x local-time

Root Cause

Although the local time is displayed on the device UTC +8, but the time which the device sends syslog is  UTC time. Therefore, the time of  syslog displayed on Network Management device is time later than 8 hours

Suggestions

modify the time of syslog to local tme of device.

For more solution of Huawei products, please try:

Contact information:

Telephone: 852-30623083
Email: Sales@Thunder-link.com
Supports@Thunder-link.com
Website: http://www.thunder-link.com

The timestamp of the syslog messages differs from the time synchronized from the NTP server

Issue Description

The S5700 switch synchronizes its time from a NTP server which provides the time in an UTC format. The switch is located in a different region with the NTP server and is configured to add an offset of 2 hours to the UTC time according to the local time zone. Along with the NTP configuration the switch is set to send the log information to a syslog server where the logs are received with a different timestamp than the current time of the device.QQ图片20171117101327

Current time of the switch:

 

[R6_U24_S5710_Stack]display ntp-service status

clock status: synchronized

clock stratum: 3

reference clock ID: 192.168.64.1

nominal frequency: 60.0002 Hz

actual frequency: 60.0002 Hz

clock precision: 2^17

clock offset: 0.0000 ms

root delay: 17.52 ms

root dispersion: 0.21 ms

peer dispersion: 0.00 ms

reference time: 18:09:50.411 UTC Jan 5 2001(BE008C6E.694A2B9D)      //time received from NTP server

synchronization state: clock set

 

[R6_U24_S5710_Stack]display clock

2001-01-05 21:10:09+03:00                        //time adjusted on the switch according to the local timezone

Friday

Time Zone(BUC) : UTC+03:00

Info-center configuration of the device:

 

[R6_U24_S5710_Stack]info-center loghost 172.1.1.19

Warning: There is security risk as this operation enables a non secure syslog protocol.

 

 

The timestamp of the logs received on the syslog server present the time in UTC format:

 

5/23/2016 12:12:31 PM  | 192.168.64.9    | Local7                | Info   |  Jan  5 2001 18:11:06 R6_U24_S5710_Stack %%01MSTP/6/RECEIVE_MSTITC(l)[18]:MSTP received BPDU with TC, MSTP process 0 instance 0, port name is GigabitEthernet0/0/1.

5/23/2016 12:12:42 PM  | 192.168.64.9    | Local7                | Notice               |  Jan  5 2001 18:11:17 R6_U24_S5710_Stack %%01SHELL/5/CMDRECORD(s)[19]:Record command information. (Task=VT0, Ip=172.1.1.19, VpnName=, User=admin, AuthenticationMethod=”Local-user”, Command=”quit”, Result=Success)

Solution

The timestamp of the syslog displays the UTC time by default and in this situation we should adjust the syslog configuration by adding the local-time parameter in the info-center loghost command as below:

[R6_U24_S5710_Stack]info-center loghost 172.1.1.19 local-time

After the local-time parameter is added, the syslog messages should be sent with the current time of the switch.

Result:

5/23/2016 12:12:50 PM  | 192.168.64.9    | Local7                | Notice            |  Jan  5 2001 21:11:25+03:00R6_U24_S5710_Stack %%01SHELL/5/CMDRECORD(s)[20]:Record command information. (Task=VT0, Ip=172.1.1.19, VpnName=, User=admin, AuthenticationMethod=”Local-user”, Command=”info-center loghost 172.1.1.19 local-time”, Result=Success)

5/23/2016 12:12:50 PM  | 192.168.64.9    | Local7                | Notice            |  Jan  5 2001 21:11:25+03:00 R6_U24_S5710_Stack %%01SHELL/5/CMDRECORD(s)[21]:Slot=1;Record command information. (Task=HS2M, Ip=172.1.1.19, VpnName=, User=admin, AuthenticationMethod=”Local-user”, Command=”info-center loghost 172.1.1.19 local-time”, Result=Success)

For more Huawei Switch model, please check http://www.thunder-link.com

 

There are 30 seconds delay when SSH to S5700 switch

Issue Description

Customer configured SSH service on our Huawei S5700. When he access to our S5700 switch through one SSH client. He found there are 30 seconds delay during the access
Through the debugging information (debugging ssh server all all ), we found the debugging is stuck in below process. There is around 21 seconds delay.
<Test>
Jul 17 2015 22:28:41.60.3+01:00 Test SSH/7/NO_INFO:Begin to compute the dh shared key.
<Test>
Jul 17 2015 22:29:03.790.1+01:00 Test SSH/7/RECV_PKT:Received ssh2 msg ecdh reply packet.
<Test>

Handling Process

1.Analyzed the configuration and confirmed that everything is fine. Trying to set up one test environment to verify it.
2.From the debugging information, I found the SSH client customer used is OpenSSH_6.9
Jul 17 2015 22:28:40.830.1+01:00 CPE-POLIZIA_LOCALE SSH/7/VERSION_RECEIVE:Version information received on VTY 1, version string:SSH-2.0-OpenSSH_6.9.
3.Using Cygwin linux environment to built ssh client. after that, test SSH service and faced same issue with cusotmer. There is big delay when S5700 campute DH shared key.

QQ图片20171117100524

4.Debugging this case with RnD. And we found OpenSSH tool is using long bit key with 2068/4097. Since S5700 is low-end switch, the performance is not very strong and it takes long time to compute the shared key.
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<8192<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 2068/4096
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

5.Based on above analysis, we provide one solution: Change the key algorithm on SSH client.
Add below command in file /root/.ssh/config or /etc/ssh/ssh_config
KexAlgorithms=diffie-hellman-group1-sha1

QQ图片20171117100820

After that, we tested it and there is only 2~3 seconds delay. The problem is solved.

Root Cause

The OpenSSH client uses long bit SSH key and exceed the performance of S5700. S5700 takes long time to compute the DH shared key with SSH client.

Solution

Based on above analysis, we provide one solution: Change the key algorithm on SSH client.
Add below command in file /root/.ssh/config or /etc/ssh/ssh_config
KexAlgorithms=diffie-hellman-group1-sha1

When use the windows as NTP server, equipment not synchronization or continuance shock

Issue Description

When used Windows as NTP server, equipment have problem to synchronization NTP time, not synchronization or continuance shock. Use other equipment as the NTP server, can synchronization time.

Handling Process

Step 1: confirm the NTP server version, is usually have this problem in Windows 2003 or Windows 2008, other versions windows rarely have this problem.

Step 2: open debugging ntp all in the  equipment, check the response packet receive from server.

Packet from *.*.*.* (server address) to *.*.*.* (local address) on Vlanif1
Leap: 0, version: 3, mode: 4
Stratum., poll 1: 64, precision: 2 ^6
Rdel: 0.000, rdsp: 10110.870, refid LOCL.

The packet’s rdsp value is 10110.870, which is about 10000ms, can determine the problem  is that the rsp value in windows response packet is too large, lead to NTP does not function normally.

Root Cause

Windows 2003 and windows 2008 the two versions, the default NTP rdsp value is 10s, lead to Huawei equipment thinks it’s not normal, affected NTP synchronization.

Other windows versions, the default values are all 0, Huawei equipment can process normally, but have the possibilty of modified to a non-zero value.

Solution

Step 1: In Windows server, enter regedit to into regedit, change as follow:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services W32Time \ Config \ LocalClockDispersion this field, from 10 change it to 0

For more information

Telephone: 852-30623083
Email: Sales@Thunder-link.com
Supports@Thunder-link.com
Website: http://www.thunder-link.com

Which Switch Models Support the PoE Function

Issue Description

Which Switch Models Support the PoE Function?

Solution

Fixed switches

You can use the display device command to check a switch’s product name and determine whether the switch supports the PoE function according to its product name.

  • If the product name contains PWR, this switch model supports the PoE function.
  • If the product name does not contain PWR, this switch model does not support the PoE function.

Modular switches

Among modular switches, only the S7700 series switches support the PoE function. The PoE card of an S7700 is ES0D0G48VA00.

Why 802.1x or MAC Address Authentication Does Not Take Effect After Being Enabled and the Configuration Is Displayed in the Configuration File

Issue Description

Why 802.1x or MAC Address Authentication Does Not Take Effect After Being Enabled and the Configuration Is Displayed in the Configuration File?

Solution

If ACL resources are used up, the dot1x enable or mac-authen command run globally or on an interface does not take effect.

Contact information:

Telephone: 852-30623083
Email: Sales@Thunder-link.com
Supports@Thunder-link.com
Website: http://www.thunder-link.com