Physical Layer
Link Failures
Link failures are one of the most common issues. First, verify the status of the interface using one of the following show commands:
supervisor@rtbrick: op> show interface summary supervisor@rtbrick: op> show interface <ifp-name>
The administrative, link, and operational status should be "Up". Depending on your configuration, logical interfaces should have been created and IP addresses should be assigned like in this example:
supervisor@rtbrick: op> show interface ifp-0/0/52 Interface Admin Link Oper IPv4 Address IPv6 Address ifp-0/0/52 Up Up Up ifl-0/0/52/13 Up Up Up - fe80::ba6a:97ff:fea5:923d/128
Verify further details of the interface using the 'detail' version of the show command:
supervisor@rtbrick: op> show interface ifp-0/0/52 detail
Interface:ifp-0/0/52
Admin/Link/Operational status: Up/Up/Up
Speed configured: 100G
Speed maximum: 100G
Duplex: Full
Autonegotiation: Disabled
Encapsulation mode: ieee
MTU: 16360
Maximum frame size: 16360
Interface type: ethernet
Interface index: 124929
MAC: b8:6a:97:a5:92:3d
Uptime: Mon Nov 23 14:18:46 GMT +0000 2020
Description: Physical interface #52 from node 0, chip 0
Packet statistics:
Rx packets: 263892 Tx packets: 280356
Rx bytes: 23377027 Tx bytes: 154437883
Interface: ifl-0/0/52/13, Instance: default
Admin/Link/Operational status: Up/Up/Up
IPv4/IPv6/MPLS Status: Up/Up/Up
IPv4/IPv6/MPLS MTU: 1500/1500/1500
Interface type: Logical Sub interface
Interface index: 106497
MAC: b8:6a:97:a5:92:3d
IPv4 Address IPv6 Address
- fe80::ba6a:97ff:fea5:923d/128
Packet statistics:
Ingress forwarded packets: 262991 Ingress forwarded bytes: 23313212
Ingress drop Packets: 0 Ingress drop bytes: 0
Egress forwarded packets: 15490 Egress forwarded bytes: 3063609
Egress drop packets: 0 Egress drop bytes: 0
Next, verify the interface statistics. These will show common link errors:
supervisor@rtbrick: op> show interface <ifp-name> statistics
You can also inspect the following BDS tables for even more detailed information:
supervisor@rtbrick: op> show datastore ifmd table global.interface.physical supervisor@rtbrick: op> show datastore ifmd table global.interface.logical supervisor@rtbrick: op> show datastore ifmd table global.interface.address supervisor@rtbrick: op> show datastore fibd table local.bcm.qmx.port
Identify the type of optics and check the optics data:
supervisor@rtbrick: op> show optics inventory supervisor@rtbrick: op> show optics interface <ifp-name>
The output of the 'show optics' command will display the Tx and Rx levels like in the following example. In addition, particularly check for warnings or alarms. These will typically indicate the cause of the issue. Please note the 'show optics' command does not work for passive Direct Attach Cable (DAC).
supervisor@rtbrick: op> show optics interface ifp-0/0/52 Physical Interface: ifp-0/0/52 Lane Id : 1 Laser bias current : 85.100 mA Laser tx power : 1.1107 mW / 0.46 dBm Laser rx power : 0.5521 mW / -2.58 dBm Module temperature : 30.41 degree celsius Module voltage : 3.199 V TX disable : false High power class enable : true Laser TX loss of signal : false Laser TX loss of lock : false Laser RX loss of signal : false Laser RX loss of lock : false <...>
You can also show detailed optics information using the BDS tables:
supervisor@rtbrick: op> show datastore resmond table global.chassis_0.resource.optics.inventory supervisor@rtbrick: op> show datastore resmond table global.chassis_0.resource.optics.module
If there are continuous or reoccurring interface issues like interface flapping, enable logging for the ifm module and inspect the log table as described in section 5.
Hardware Failures
If you suspect a hardware failure or issue, verify sensor information available at the RFBS container layer. Please note this section applies to hardware switches only. Sensor information is not available on virtual deployments.
supervisor@rtbrick: op> show sensor system-led supervisor@rtbrick: op> show sensor power-supply supervisor@rtbrick: op> show sensor fan supervisor@rtbrick: op> show sensor temperature
The sensor information might show hardware failures like in this example:
supervisor@rtbrick: op> show sensor power-supply Name Current In Current Out Voltage In Voltage Out Power In Power Out Status PSU-1 0 mA 11593 mA 0 mV 11984 mV 0 mW 139000 mW PRESENT PSU-2 0 mA 0 mA 0 mV 0 mV 0 mW 0 mW PRESENT, FAILED
Next, verify the status of the hardware at the ONL layer:
supervisor@spine1:~# sudo onlpdump
|
Due to a known issue, the 'sudo onlpdump' command does not work in the current release for the user supervisor. As a workaround switch to user root using 'sudo -i' and then enter the 'onlpdump' command. |
The onlpdump tool provides detailed information about the system and its components, and might show hardware failures like in the following example:
supervisor@spine1:~# sudo onlpdump
<...>
psu @ 1 = {
Description: PSU-1
Model: NULL
SN: NULL
Status: 0x00000003 [ PRESENT,FAILED ]
Caps: 0x00000000
Vin: 0
Vout: 0
Iin: 0
Iout: 0
Pin: 0
Pout: 0
}
If you have identified or suspect an optics issue, verify the status of the optics at the ONL layer. The onlpdump -S tool will show the type of optic installed:
supervisor@spine1:~# sudo onlpdump -S Port Type Media Status Len Vendor Model S/N ---- -------------- ------ ------ ----- ---------------- ---------------- ---------------- 0 NONE <...> 52 100GBASE-CR4 Copper 3m Fiberstore QSFP28-100G-DAC I2706060007 <...>
The following example shows an optic failure:
supervisor @localhost:~# sudo onlpdump -S Port Type Media Status Len Vendor Model S/N ---- -------------- ------ ------ ----- ---------------- ---------------- ---------------- <...> 06-27 08:27:49.823107 [x86_64_accton_as5916_54xk] Unable to read eeprom from port(51), size is different! 51 Error E_INTERNAL