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 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.
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. In this article we will help you to understand what Cisco Nexus Cut-through is.
A Hidden Challenge
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.
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) 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.
Store-and-Forward Mode: Giving Your Switch Time to Think
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). 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 can handle ports with different speeds.
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.
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.
