How can a router know the MTU of the next router?

Question

https://www.cloudflare.com/learning/network-layer/what-is-mtu/

Suppose Server A and Computer A are connected, but the data packets they send to each other have to pass through Router B and Router C along the way. Server A, Computer A, and Router B all have an MTU of 1,500 bytes. However, Router C has an MTU of 1,400 bytes. If Server A and Computer A are not aware of Router C's MTU and send 1,500-byte packets, all their data packets will be fragmented by Router B in transit.

My question is:

How does router B know that the MTU of router C is 1400 bytes and why router B pre-fragment packets to send before router C?

Why doesn't router C perform fragmentation directly?

Answer 1

How does router B know that the MTU of router C is 1400 bytes?

The MTU is a property of a network segment/subnet (more specifically of a link), not of a device/node which can have many interfaces with differing MTUs.

B and C should both have the same link MTU on their shared network, as should all nodes connected to that subnet.

why router B pre-fragment packets to send before router C?

See above. B's link towards C reduces the path MTU to 1400 bytes.

Why doesn't router C perform fragmentation directly?

If you mean reassembly, that's not a router's job. After all, in doesn't make sense to reassemble fragments in-path and then fragment them again on the next hop.

Since in-path fragmentation is inefficient, IPv6 does away with it altogether and limits fragmentation to the source node, relying on path MTU discovery (PMTUD).

Answer 2

To add to Zac67's answer:

why router B pre-fragment packets to send before router C

Fragmentation is expensive in terms of system ressources on routers, and should be avoided.

Routers and Firewalls with modern multicore CPUs and Security ASICs can shoulder a lot of fragmentation work and masquerade the underlying issue. Low- and mid-range routers and L3-switches will punt such workload from their forwarding ASIC (if at all present) to the CPU - and this can kill performance drastically. Single digit Mbit/s throughput, even on Gigabit links can be the result.

If ComputerA supports PathMTUdiscovery and sets the "do not fragment" bit in the header of its IP packets, RouterB may make use of PathMTUdiscovery to let Computer A know that it should send smaller sized packets when talking to ServerA. (see Zac67's answer).

It does this by sendig an ICMP Type 3 Code 4 message ("fragmentation needed but don't fragment set") back to Computer A, which also includes a suggested max packet size and the packet header of the packet that caused the error.

If ComputerA ingests this message and processes it successfully, it will react by sending no more IP packets larger than suggested max packet size towards ServerA. This setting is individual per-destination; when talking to other destination hosts (for example on the local LAN), ComputerA will still use its standard packet size.

Some of this can also be achieved if Routers B and C are configured to perform TCP MSS Clamping. With TCP MSS Clamping, the routers manipulate the SYN and SYN-ACK packets exchanged between ComputerA and ServerA at the start of a TCP session, and they trick both ServerA and ComputerA into believing that the remote peer can only accept a given (lower) number of payload bytes per TCP segment (TCP Maximum Segment Size: usually IP MTU - 40bytes, so here: 1360 bytes).

This will cause both ServerA and ComputerA to send TCP segments with no more than 1360 bytes of payload when talking to each other for the given TCP session, while still using normal TCP segment size when talking to other computers.

TCP MSS clamping is a bit of a kludge: It only works for/with TCP. UDP and other applications must rely on PMTUD, probe the PathMTU themselves somehow, or must be configured to send a given max packet size.