04-17-2023 12:23 PM
Hello Community,
Can you please help me to understand how FCS and IP checksum work? If I understand correctly, when frame is received by L2 Switch, switch checks FCS of that Frame (but only if switching mode of the switch is "store and forward", which is not so common anymore). But what happens when frame is received by Router / L3 Switch? Please correct me if I'm wrong:
1. Frame is received by Router / L3 Switch
2. Router / L3 Switch checks FCS of the Frame.
3. If FCS is not correct, frame is discarded.
4. If FCS is correct, then Frame is processed further and Router / L3 Switch checks IP checksum of the packet.
5. If IP checksum is not correct, packet is discarded.
6. If IP checksum is correct, then packet is processed further.
7. After routing decision is made, Router / L3 Switch change TTL (decrements it by 1), then recalculates IP checksum and writes it to the IP header.
8. Then Router / L3 Switch rewrites the source and destination MAC addresses in the Frame and recalculates FCS and writes it to the Frame's trailer.
04-17-2023 10:20 PM
Hello @NetworkingGeek1,
--When a frame is received by a router or L3 switch, it is first checked for errors, including the FCS. This is typically done by hardware at the physical layer, so it is independent of the switching mode of the device.
--If the FCS is incorrect, the frame is discarded.
--If the FCS is correct, the frame is forwarded to the software of the router or L3 switch, which then extracts the packet from the frame.
--The IP checksum is then checked by the software. If the checksum is incorrect, the packet is discarded.
--If the IP checksum is correct, the packet is processed further.
--After the routing decision is made, the router or L3 switch decrements the TTL and recalculates the IP checksum, as you mentioned. Note that the TTL decrement and IP checksum recalculation are part of the routing process, not the error checking process.
--The router or L3 switch then updates the MAC addresses in the Ethernet frame header to reflect the new path to the destination. The FCS is then recalculated and added to the frame trailer.
So, to summarize, FCS and IP checksum work differently in routers/L3 switches than in L2 switches. In routers/L3 switches, FCS is checked at the physical layer, and IP checksum is checked at the software layer. Additionally, TTL decrement and IP checksum recalculation are part of the routing process, not the error checking process.
04-18-2023 03:01 AM
Hello M02@rt37 Thank you for the detailed reply. Can you please clarify several points?
"--When a frame is received by a router or L3 switch, it is first checked for errors, including the FCS. This is typically done by hardware at the physical layer, so it is independent of the switching mode of the device." - can you please clarify? Do you mean that Router / L3 Switch check FCS regardless of switching mode, whereas L2 switch checks FCS only if it's in "Store and Forward" switching mode and L2 switch doesn't check FCS if it's in Cut-through switching mode? Or maybe, in Cut-through mode, switch first starts to send a Frame and check the FCS during transmission?
Also, can you please clarify, when FCS is checked, before or after L2/L3 Switch and Router reads the destination MAC and knows what with that Frame? The same for IP checksum, it it checked before or after L3 Switch / Router made routing decision on that packet?
04-18-2023 03:07 AM - edited 04-18-2023 03:07 AM
You're welcome@NetworkingGeek1.
First, when a frame is received by a router or L3 switch, it is first checked for errors including the FCS, regardless of the switching mode of the device. This is typically done by hardware at the physical layer of the device, which is responsible for the actual transmission and reception of the electrical or optical signals that make up the network data.
In contrast, when a frame is received by a L2 switch, whether the FCS is checked or not depends on the switching mode of the switch. In "store-and-forward" mode, the switch checks the FCS before forwarding the frame, which allows it to detect and discard any frames with errors. In "cut-through" mode, on the other hand, the switch starts forwarding the frame as soon as it reads the destination MAC address, and doesn't check the FCS until the entire frame has been forwarded.
Then, the FCS and IP checksum are checked before the router or L3 switch reads the destination MAC address and makes a routing decision. The reason for this is that the FCS and IP checksum are both used to detect errors in the data, and if there is an error, the frame or packet will be discarded before any further processing is done.
So, when a frame is received by a router or L3 switch, it is first checked for errors, including the FCS. If the FCS is valid, the device then reads the destination MAC address to determine where to forward the frame. Similarly, when a packet is received by a router or L3 switch, it is first checked for errors, including the IP checksum. If the checksum is valid, the device then reads the destination IP address to determine where to forward the packet.
04-18-2023 09:11 AM
Possibly there are some slight inaccuracies (implicit assumptions?) in M02@rt37's information.
I agree, for a switch doing L2 cut-through, frame begins to be forwarded as soon as destination MAC received.
Transmitting frame before it's validated, does impose risk. For example, since frame is not validated before it begins to be transmitted, frame could be corrupted including the destination MAC could be in error.
Whether a switch, in cut-though mode, bothers to check FCS, cannot say, because the point of doing the FCS validation is to drop a frame that fails the check, but as the frame is being forwarded, there no real purpose for doing the FCS check. (I.e. by the time the switch knows the frame should be discarded, a corrupted frame has already been sent. So, cut-though trades-off forwarding the [hopefully very rare] corrupted frame, for transmitting frames with reduced latency.)
Also for cut-though switches, although it's a L2 operation, it might be done on a L3 switch too, when frame is being processed strictly at L2. Remember, L3 switches are also L2 switches.
Excluding cut-through L2 switching, all Ethernet hosts, upon receiving a frame should do the FCS check. Whether this is done in hardware or software, depends on the host. I believe most if not all (this century) Ethernet NICs would do a FCS check in (the NIC's) hardware. (If FCS is done on the NIC, and fails, as far as the rest of the receiving device might be concerned, no data was received at all.)
If the host "needs" to work with the IP packet (which, don't forget, might span multiple frames), it would check the IP packet's header checksum. Whether this is done in hardware or software, would depend on the host. Devices that need to process lots and lots of packets, e.g. L3 switches or routers, probably have some kind of dedicated hardware support. Devices without such stringent needs might do the computation strictly in software.
BTW, many Enterprise grade L2 switches are smart/intelligent/enhanced, meaning although they don't route, they may support some L3 features, like using L3 ACLs.
I.e. I wouldn't assume all L2 switches ignore L3 data and/or whether hardware or software is used for data validation checks just on the basis of device kind (for example "switches" vs. "routers" [BTW, my favorite example of "switches" vs. "routers" was the 6500 vs. the 7600, as they both could use identical sups, identical line cards, and for a while, might run the same IOS image, and also had the same L2 and L3 performance stats, but the 6500 was a "switch" and the 7600 was a "router"; then there was another network vendor that sold "Smart Switch Routers", a L3 switch and router in one device]).
In theory, on Ethernet, L3 (and L4 or above) data validation fields shouldn't be needed, as any data corruption within the packet should be reflected in the frame's FCS. I suspect the reason for L3 data validation, is because it's independent of L2 validation, i.e. L3 doesn't "know" how "good" L2 data corruption is, or whether there's any at all, so best to have L3's own data validation.
04-18-2023 01:38 PM - edited 04-18-2023 01:44 PM
@Joseph W. Doherty Hello. Thanks for the reply. We all agree that in cut-through mode switch will start to send frames as soon it reads destination MAC (and probably it doesn't check FCS), but as you rightly said, L3 switches are also L2 switches. So, if we say that L3 Switch and Router, unlike L2 switches, always check FCS of the frame, how L3 switch should know whether it should check FCS or not? In case if frame is destined to other network, it should have MAC address of the receiving L3 switch in the destination field, maybe that's how receiving L3 Switch knows that this Frame's FCS needs to be checked?
04-18-2023 02:08 PM
Yes, that would be a good way to make that determination.
Or, it might do it all the time, regardless. If doing cut-through, a failed FCS would be ignored.
If either of the above could be used, which is better? Likely that would depend on the switch's architecture (also likely to be considered proprietary information).
04-18-2023 01:51 PM - edited 04-18-2023 01:52 PM
M02@rt37 thanks for the reply. Can you please clarify this "Then, the FCS and IP checksum are checked before the router or L3 switch reads the destination MAC address and makes a routing decision." I'm a little bit confused, I read it like "Router / L3 Switch first check both FCS and IP checksum at the same time and then reads the destination MAC address and reads destination IP and then makes a routing decision". I thought the order is like this: firstly Router / L3 Switch checks FCS, then reads MAC address, then checks IP checksum, then reads the destination IP and then make a routing decision. Can you please clarify?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide