Handle switch port "false" issues

When maintaining the dormitory network for a few days, I encountered a very unique problem at the time: No matter how the 20 Ports of the vswitch on the fourth floor are connected, the link cannot be connected; when the switch enters, the port cannot be enabled; there is no problem connecting to other ports. I thought it was because the port broke down. Later I heard that the 20 ports were shut down because of the loop. It would be nice to repeat the error rules. Huawei Switch configuration

So I checked it online and found out the principle:

The port on which the switch is working is suddenly suspended. First, you can restart the switch to handle the problem. Second, you can call for regulation.

The detailed steps for coping with appeals are as follows:

Step 1: Check the log/port status

Log on to the vswitch and run showlog. The following message is displayed:

21w6d: ETHCNTR-3-LOOP_BACK_DETECTED: Keepalivepacketloop-backdetectedonFastEthernet0/20.

21w6d: % PM-4-ERR_DISABLE: loopbackerrordetectedonFa0/20, puttingFa0/20inerr-disablestate

The above information clearly implies that the port is in the err-disable State because it detects a loop on port 20th.

Check the port status

Switch # showinterfa0/20 status

PortNameStatusVlanDuplexSpeedType

Fa0/20linktodatabackuperr-disabled562auto10/100 BaseTX

This more clearly implies that the port is in the err-disabled state.

Now that the port is in the wrong state, we should have a step to repeat it into a normal state.

Save pace 2: Configure the port from the error status

Go to the Global Setting Mode of the switch and run errdisablerecoverycause ?, The following information is displayed:

Switch (config) # errdisablerecoverycause?

AllEnabletimertorecoverfromallcauses

BpduguardEnabletimertorecoverfromBPDUGuarderrordisablestate

Channel-misconfigEnabletimertorecoverfromchannelmisconfigdisablestate

Dhcp-rate-limitEnabletimertorecoverfromdhcp-rate-limiterrordisablestate

Dtp-flapEnabletimertorecoverfromdtp-flaperrordisablestate

Gbic-invalidEnabletimertorecoverfrominvalidGBICerrordisablestate

L2ptguardEnabletimertorecoverfroml2protocol-tunnelerrordisablestate

Link-flapEnabletimertorecoverfromlink-flaperrordisablestate

LoopbackEnabletimertorecoverfromloopbackdetecteddisablestate

Pagp-flapEnabletimertorecoverfrompagp-flaperrordisablestate

Export cure-violationEnabletimertorecoverfrompsecureviolationdisablestate

Security-violationEnabletimertorecoverfrom802.1xviolationdisablestate

UdldEnabletimertorecoverfromudlderrordisablestate

Unicast-floodEnabletimertorecoverfromunicastflooddisablestate

VmpsEnabletimertorecoverfromvmpsshutdownerrordisablestate

From the listed options, we can see that there are many reasons that may cause the port to be put in the wrong state, as we clearly know that the port on this vswitch is put in an error due to loop problems, we can directly type an appeal:

Switch (config) # errdisablerecoverycauseloopback

Save pace 3: Display the specification of the port that is placed in the error status

Switch # showerrdisablerecovery

ErrDisableReasonTimerStatus

-------------------------------

UdldDisabled

BpduguardDisabled

Security-violatioDisabled

Channel-misconfigDisabled

VmpsDisabled

Pagp-flapDisabled

Dtp-flapDisabled

Link-flapDisabled

Gbic-invalidDisabled

L2ptguardDisabled

Specified cure-violationDisabled

Gbic-invalidDisabled

Dhcp-rate-limitDisabled

Unicast-floodDisabled

LoopbackEnabled

Timerinterval: 300 seconds

Interfacesthatwillbeenabledatthenexttimeout:

InterfaceErrdisablereasonTimeleft (sec)

----------------------------------------

Fa0/8loopback276

Fa0/17loopback267

Fa0/20loopback250

The information shown above shows that the vswitch has three ports (Fa0/8, Fa0/17, and Fa0/20) it will be a normal status after 276, 267, and 250 seconds. The actual situation is the same. After a few minutes, we will find a notebook computer, do not try these ports. Now, with no heavy switch, several ports in the "suspended" status are "saved.

Edit recommendations]