Cisco Nexus Cut-through switching
What You Need to Know
Cut-through feature, as the name suggests, provides low-latency switching behavior. This is achieved thanks to technology, which checks the destination MAC (DMAC) address of the incoming frame and proceeds to the forwarding process immediately. This process requires ports of an identical speed but, in return, offers lower latency.
Sometimes Optical transceivers can have some technical issues, which usually can be solved by changing the EEPROM coding or changing the transceiver itself. The technical problem troubleshooting process can be extensive, ranging from simple equipment debug information analysis to precise transceiver hardware disassembly and component analysis. In this article, we will help you understand what Cisco Nexus Cut-through is.
A Hidden Challenge
One of the optical transceiver troubleshooting steps is equipment port statistics analysis. The output error counter is especially our point of interest because transceiver hardware or compatibility issues result in output packet errors.
There have been occurrences when port output errors are not solvable by transceiver reprogramming to a more updated coding version, or replacing hardware (chipset) with a different solution. One of the examples is Cisco Nexus series datacenter switches. These switches, by default, utilize the Cisco Cut-Through Ethernet Switching for Low-Latency Environments feature.
When Errors Show Up on the Wrong Port
In case you are observing output errors without any other valid explanation, then you must check (on the same switch) the same speed ports for input errors. In the usual case, the corrupt frame source is on a different port.
These frames enter one port, then they are cut through to another and causing errors to increase on destination link ports.
This behavior leads to thinking that the link is producing errors, but in reality, contrary errors are directly injected into this link.
Store-and-Forward Mode: Giving Your Switch Time to Think
Cisco Nexus's second method of packet processing is Store and Forward. This method buffers the entire frame in memory, and the frame check sequence is validated (to help ensure that the packet is free of physical and data-link errors). To test this, use the command:
switch # configure terminal
switch ( config ) # switching-mode store-forward
switch ( config ) #NB! To disable, use the “NO” form of the switching-mode store-forward command.
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 it can handle ports with different speeds.
The downside to this (cut-through) processing mechanism is in case if the frame has arrived broken, and the FCS sequence fails, then it is not possible to fix the frame because it has already left the switch. In this case, the switch drops the frame and increments error counters on the outgoing port. The receiving side switch receives this broken frame and also increments its input port error counter.
Final Thoughts on Cut-Through
Cut-through switching on Cisco Nexus gear is awesome for keeping latency super low, but it can sometimes make life harder when you’re chasing down weird port errors. Since bad frames get pushed through before anyone double-checks them, you might end up blaming the wrong link. If you’re stuck with stubborn output errors that won’t go away, flipping the port to Store and Forward mode can really help — it catches the bad frames before they go anywhere. You might lose a tiny bit of speed, but you’ll gain a lot more stability and way fewer headaches down the road.