The amount of data that can be transmitted in a frame varies with Ethernet access devices.

A typical Ethernet card can transmit up to 1500 bytes of data per frame. And some virtual devices, the transmission capacity is a little bit discounted. In addition, there are other protocols in the link layer besides Ethernet, and the data frame transmission capabilities of these protocols are also different.

Maximum transmission unit

If the data to be sent exceeds the maximum frame capacity, the data needs to be shard and then transmitted over several frames.

The following is a typical example, with a total of 4000 bytes of data to be sent, assuming that the Ethernet device can only carry 1500 bytes per frame at most. Obviously, the data needs to be split into three pieces and sent over three frames:

In other words, we need to know how much data the access device can send in a frame. This parameter is known in the network world as the Maximum Transmission Unit, or MTU. MTU Describes the maximum data unit that can be transmitted at the link layer.

View and set MTU

As we know, in Linux system, you can use ifconfig or IP to check the network adapter information, including MTU.

Next, let’s open Docker and enter the Netbox environment for demonstration:

docker run --name netbox --rm -it --privileged --cap-add=NET_ADMIN --cap-add=SYS_ADMIN -v /data -h netbox Fasionchan/netbox: 0.5 bash/script/netbox. ShCopy the code

The ifconfig command is used as an example.

root@netbox [~] ➜ ifconfig eth0: Flags = 4163 < UP, BROADCAST, RUNNING, MULTICAST > mtu 1500 inet 192.168.1.2 instead netmask 255.255.255.0 BROADCAST 0.0.0.0 Mr 5A: FF: 7E :28:81: BC TXQueuelen 1000 (Ethernet) RX packets 24 bytes 2165 (2.1 KB) RX errors 0 Dropped 0 Overruns 0 frame 0 TX packets 27 bytes 2164 (2.1 KB) TX errors 0 Dropped 0 Overruns 0 carrier 0 collisions 0 LO: Flags =73<UP,LOOPBACK,RUNNING> MTU 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixLen 128 scopeid 0x10<host> loop Txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0b) RX errors 0 Dropped 0 Overruns 0 frame 0 TX packets 0 Bytes 0 (0.0b) TX errors 0 Dropped 0 Overruns 0 carrier 0 collisions 0Copy the code

The IP command also works, and we prefer to use this one:

root@netbox [~] ➜ IP Link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: tunl0@NONE: <NOARP> MTU 1480 qdisc noop state DOWN mode DEFAULT group DEFAULT qlen 1000 Link/ipIP 0.0.0.0 BRD 0.0.0.0 3: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/tunnel6 :: brd :: 6: eth0@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 5a:ff:7e:28:81:bc brd ff:ff:ff:ff:ff:ff link-netnsid 0Copy the code

You can run the IP command to change the MTU of eth0. Take eth0 as an example:

root@netbox [~] ➜ IP link set eth0 MTU 68Copy the code

Different access devices support different MTU ranges. If we set the MTU too small, the device will report an error:

root@netbox [~] ➜ IP link set eth0 MTU 40 Error: MTU less than device minimum.Copy the code

MTU Impact on the sending process

We take two hosts directly connected by network cables as the experimental environment to observe the influence of MTU of network adapters on sending and receiving Ethernet frames:

The experimental environment is also started by Docker:

docker run --name mtu-lab --rm -it --privileged --cap-add=NET_ADMIN --cap-add=SYS_ADMIN -v /data -h mtu-lab Fasionchan/netbox: 0.5 bash/script/cable - lab. ShCopy the code

We set the MTU of ant host eth0 to 68 and found that Ethernet frames larger than 68 bytes cannot be sent:

root@ant [~] ➜ IP link set eth0 mtu 68 root@ant [~] ➜ sendether -i eth0 -t 32:65:21:d3:01:2f -d 'Hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! ' Fail to send ethernet frame: : Message too longCopy the code

After the MTU is restored to the default value 1500, the MTU can be sent successfully:

root@ant [~] ➜ IP link set eth0 mtu 1500 root@ant [~] ➜ sendether -i eth0 -t 32:65:21:d3:01:2f -d 'Hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! 'Copy the code

This is the impact of the MTU on the transmission process: If the amount of data is larger than the MTU, the data cannot be sent through a single Ethernet frame. Instead, the data can only be fragmented by the MTU and then encapsulated into several frames for transmission.

MTU Impact on the receiving link

So what impact does MTU have on the receiving loop?

We set the MTU of the eth0 network adapter on the bee host to 68 and started tcpdump to capture packets:

root@ant [~] ➜ IP link set eth0 MTU 68 root@ant [~] ➜ tcpdump -ni eth0Copy the code

Next, we send an Ethernet frame larger than 68 bytes to host BEE on host Ant:

root@ant [~] ➜ sendether -i eth-t 32:65:21:d3:01:2f -d 'Hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! hello, world! 'Copy the code

However, the tcpdump program on the host Ant tells us that the eth0 network card did not receive this frame! Therefore, if the length of Ethernet frame data is greater than the MTU of the receiving device, it is discarded.

conclusion

  • The length of Ethernet frame data to be sent is larger than that of the sending deviceMTU, cannot be sent.
  • The length of the Ethernet frame to be received is larger than that of the receiving device. ProcedureMTU, cannot receive.

[Xiaocai Network] series of articles first published in the public number [Xiaocai programming], please pay attention to: