skip to content

How do store-and-forward and cut-through Ethernet switching differ, and what does each trade between latency and error handling?

level: seniorimportance: nice to knowfreq 22%

answer

  1. when does transmission start
  2. the checksum is at the end
  3. frame size times link rate
  4. bad frames travel further

basics

~20 s

A store-and-forward switch receives the whole frame and checks its FCS before sending, adding one frame's serialisation delay per hop. A cut-through switch starts sending once it has read the destination MAC, cutting latency but passing on corrupted frames.

solid answer

~50 s

In **store-and-forward**, the switch buffers the entire frame, verifies the **FCS** (the CRC-32 trailer) and discards it if it is corrupt, then forwards it. The cost is latency: each hop waits for the whole frame, so a 1,518-byte frame adds about 12.1 microseconds on a 1 Gb/s port before transmission can even begin. In **cut-through**, the switch starts transmitting as soon as it has read the 6-byte destination address, so its latency barely depends on frame size, but the FCS arrives at the end, after forwarding has begun, so corrupt frames are propagated and dropped only by a later store-and-forward device or the receiving NIC. Cut-through also only works when the egress port is idle and no faster than the ingress port; otherwise the frame is buffered anyway. Both are implementation modes, not protocol options: the frames on the wire are identical.

go deeper

for a junior

Recall the one-line difference: store-and-forward waits for the whole frame and checks it; cut-through starts sending once it knows the destination address.

for a middle

Explain why the FCS position at the end of the frame forces the trade, and compute serialisation delay as frame bits divided by link rate.

for a senior

Show the production consequences: corrupted frames spreading on cut-through paths, misleading error counters, the speed-mismatch and busy-port fallbacks, and congestion erasing the gain.

for a principal

Decide where microseconds justify cut-through, such as latency-sensitive fabrics, against where error containment and simpler fault isolation matter more, and set error-monitoring practice to match.

## Where the difference comes from An Ethernet frame arrives one bit after another. After the preamble and start frame delimiter come the **destination MAC** (6 bytes), the **source MAC** (6 bytes), the **EtherType** (2 bytes), the payload (46 to 1,500 bytes for IP over Ethernet, per RFC 894) and finally the **FCS** (frame check sequence, a 4-byte CRC-32 computed over everything from the destination address to the end of the payload). Two facts follow: - the switch knows **where** to send the frame after only 6 bytes; - the switch knows **whether the frame is intact** only after the last byte. The two switching modes differ purely in which of those moments they wait for. They are **implementation choices** inside a switch; nothing in the frame format or the bridging protocol tells a neighbour which one is in use. ## Store-and-forward 1. Receive the entire frame into a buffer. 2. Check the FCS; discard frames that fail it and frames that are too short or too long. 3. Learn the source, look up the destination, queue the frame on the egress port. Its latency per hop includes the **serialisation delay** of the whole frame: frame bits divided by link rate. | Frame (excluding preamble) | 100 Mb/s | 1 Gb/s | 10 Gb/s | |---|---|---|---| | 64 bytes (minimum) | 5.12 µs | 0.512 µs | 0.0512 µs | | 1,518 bytes (maximum untagged) | 121.4 µs | 12.1 µs | 1.21 µs | The delay is paid at **every** store-and-forward hop, so a path through several switches multiplies it, and it grows with frame size. Across five store-and-forward hops at 1 Gb/s, a 1,518-byte frame accumulates about 61 µs of serialisation delay (5 x 12.1 µs), while a 64-byte frame accumulates about 2.6 µs. Jumbo frames, which lie outside the 802.3 standard sizes, make the per-hop wait proportionally longer still, which is one reason latency-sensitive designs care about the mode. ## Cut-through 1. Read the destination MAC as soon as it arrives. 2. Look it up and, if the egress port is free, start transmitting while the rest of the frame is still arriving. 3. The FCS passes through at the end; the switch can count a bad one, but the frame is already gone. The latency is roughly constant regardless of frame size, which is why it matters most for large frames on slower links and for workloads that care about microseconds. Some implementations offer an intermediate mode, often called **fragment-free**, that waits for the first 64 bytes: on half-duplex shared Ethernet, collision fragments are shorter than the 64-byte minimum frame, so this filters them without waiting for the full frame. It is an implementation feature, not part of any standard. ## The conditions under which cut-through cannot cut through - **Busy egress port**: if another frame is already being sent out of that port, the new one must wait in a buffer, and once it is buffered the switch behaves like store-and-forward for that frame. - **Slower ingress than egress** (for example 1 Gb/s in, 10 Gb/s out): the egress side would transmit faster than bits arrive and run out of data mid-frame, so the frame must be buffered first. - **Congestion** in general: under load, queueing delay dwarfs the few microseconds of serialisation that cut-through saves, so its advantage is largest on lightly loaded, same-speed paths. ## The trade-off in production - **Latency**: cut-through wins, by one frame's serialisation time per hop. - **Error containment**: store-and-forward wins. A frame corrupted by a bad cable or optic is dropped at the first store-and-forward hop. With cut-through it crosses every cut-through hop, wasting bandwidth, and is dropped only by a later store-and-forward switch or the receiving network card. - **Troubleshooting**: on a cut-through path, FCS errors are counted on many ports downstream of the fault, not only on the port with the bad cable. The port with the most errors is not necessarily where the fault is; trace upstream to the first port counting errors on ingress. - **Higher layers**: either way, the corrupted frame is eventually discarded at the link layer, so the transport protocol sees a loss (TCP retransmits) rather than corrupted data. Neither mode changes MAC learning or flooding. Both learn from source addresses and decide from destination addresses; cut-through simply starts sending earlier.

  • On a cut-through network, why can the port reporting the most FCS errors be the wrong place to look for a bad cable?
    A cut-through switch forwards a frame before its FCS arrives, so a frame corrupted on one link is sent onward and each later hop counts the same error. Errors appear on many ports downstream of the fault. Trace the errors upstream to the first port that counts them on received frames; that link is the faulty one.
  • Does cut-through switching still help when the network is congested?
    Very little. A frame headed for a busy egress port has to wait in a buffer, and once buffered it is effectively store-and-forward. Under load, queueing delay is far larger than the one frame's serialisation time that cut-through saves, so its benefit is largest on lightly loaded paths between ports of the same speed.

saying these in an interview costs you the question

  • Cut-through switches check the FCS before they start forwarding the frame.
  • Store-and-forward latency is the same for a 64-byte and a 1,518-byte frame.
  • Cut-through is an Ethernet protocol option negotiated between neighbouring switches.
  • Cut-through can forward from a 1 Gb/s port to a 10 Gb/s port without buffering.
  • The FCS covers only the header, so a switch can verify it early.