Nexus Cut-through 100G switching
Sometimes Optical transceivers can have some technical issues which usually can be solved by changing EEPROM coding, or changing transceiver itself. Technical problem troubleshooting process can be extensive, ranging from simple equipment debug information analysis to precise transceiver hardware disassembly and component analysis.
One of the optical transceiver troubleshooting steps is equipment port statistics analysis. Output error counter especially is our point of interest because transceiver hardware or compatibility issues are result for output packet errors.
There has been occurrences when port output errors are not solvable by transceiver reprogramming to more updated coding version, or replacing hardware (chipset) to different solution. One of examples is Cisco Nexus series datacenter switches. These switches by default utilizes Cisco Cut-Through Ethernet Switching for Low-Latency Environments feature.
Cut-through feature as the name suggests, provides low latency switching behavior. This is achieved thanks to technology which checks destination MAC (DMAC) address of incoming frame and proceeds to forwarding process immediately. This process requires ports of an identical speed but in return offers lower latency.
The downside to this (cut-through) processing mechanism is in case if frame has arrived broken, and FCS sequence fails, then it is not possible to fix the frame because it has already left the switch. At this case switch drops the frame and increments error counters on outgoing port. Receiving side switch receives this broken frame and also increments its input port error counter.
In case you are observing output errors without any other valid explanation, then you must check (on the same switch) same speed ports for input errors. In usual case the corrupt frame source is on different port. These frames enter one port, then they are cut-through to another and causes errors to increase on destination link ports.
This behavior leads to thinking that link is producing errors but in reality, contrary – errors are directly injected into this link.
Cisco Nexus second method of port packet process is Store and Forward. This method buffers entire frame in memory and frame check sequence is validated (to help ensure that the packet is free of physical and data-link errors). Only after this validation frame is forwarded. Whereas a store-and-forward switch drops invalid packets, cut-through devices forward them because they do not get a chance to evaluate the FCS before transmitting the packet. This method takes time to process frames but can handle ports with different speeds.