Interfaces will transition into an error-disabled state due to reasons like excessive link-flaps or speed mismatch. A link-flap happens when there is a high number of flaps in a short time-frame due to a low light level or inconsistency in the incoming Rx optical signal or due to a faulty cable in the path. If the Arista switch observes more than 5 flaps within a 10-sec interval, Arista’s default behavior is to put the port in an error-disabled state. This prevents port(s) from going into a wedged state because of excessive flapping, thereby eliminating instability on the network.
Steps to Check
Let us take a look at how to verify state and take corrective action once all issues are resolved.
1. To check the default setting we can use the following command:
switch#sh errdisable flap-values ErrDisable Reason Flaps Time ================= ===== ==== link-flap 5 10.0
2. To check the reason the port(s) have gone into errdisabled state, we look at the below output:
switch#show interfaces status errdisabled Port Name Status Reason ---------- -------------------------- ----------------- --------------------- Et23 errdisabled link-flap Et24 errdisabled link-flap Et33 Link-DCA-R1C20SW3B-E errdisabled speed-misconfigured Et34 Link-DCA-R1C20SW3B-E errdisabled speed-misconfigured Et35 Link-DCA-R1C20SW3A-E errdisabled speed-misconfigured Et36 Link-DCA-R1C20SW3A-E errdisabled speed-misconfigured
3. Now that we have identified the symptom, let’s restore the port.
a. A general rule of thumb when the reason cited is “link-flap” is to check the underlying cables/connections in the path ensuring proper Tx/Rx power for the optical ports. Once the L1 path is inspected and cleaned, we can bounce the port(s) by simply using the “shut/no shut” command and check to see the link has stabilized and is back in a connected state.
b. Alternatively, to keep the port in Link-Up and to prevent the port from going into an err-disabled state due to marginal optical light levels, we can also perform the below command
after we determine the cause of flap in step2
Switch(conf-if-Etx/y)#errdisable recovery cause? <<List of options .. .. link-flap Enable the link-flap cause no-internal-vlan Enable the no-internal-vlan cause portchannelguard Enable the portchannelguard cause portsec Enable the portsec cause speed-misconfigured Enable the speed-misconfigured cause xcvr-misconfigured Enable the xcvr-misconfigured cause xcvr-overheat Enable the xcvr-overheat cause xcvr-power-unsupported Enable the xcvr-power-unsupported cause xcvr-unsupported Enable the xcvr-unsupported cause
4. Another common reason for port(s) transitioning to an errdisabled state is due to speed mismatch. This is also dependent on port speed combinations on various platforms. Please refer to our datasheet: https://www.arista.com/en/products/platforms
For example, note the 7050X3/Trident3 platform below:
The high-density SFP ports can be configured in groups of 4 (1-4, 5-8….) to run either at 25G or a mix of 10G/1G speeds. Where ethernet 1,5,9 and so on are master interfaces in the quad group. The speed on slave interfaces must be compatible with the master interface or they will go into an errdisable state.
For a fiber cleaning guide based on the type of optic, please refer to the literature in the technical resources section:
If the issue is still seen after following the above steps, please collect the below outputs and reach out to Arista TAC support by sending an email at email@example.com.
show tech-support | gzip > /mnt/flash/show-tech-$HOSTNAME-$(date +%m_%d.%H%M).log.gz show agent log | gzip > /mnt/flash/show-agentlog-$HOSTNAME-$(date +%m_%d.%H%M).log.gz bash sudo tar -cvf - /var/log/qt/ > /mnt/flash/qt-logs-$HOSTNAME-$(date +%m_%d.%H%M).tar.gz show agent qtrace | gzip >/mnt/flash/show-agentqt-$HOSTNAME-$(date +%m_%d.%H%M).log.gz show logging system | gzip >/mnt/flash/show-logsys-$HOSTNAME-$(date +%m_%d.%H%M).log.gz bash sudo tar -cvf - /mnt/flash/schedule/tech-support/* > /mnt/flash/history-tech-$HOSTNAME-$(date +%m_%d.%H%M).tar