Tenho um servidor Ubuntu 22.04, um switch MikroTik CRS328-24P-4S+RM e câmeras conectadas à Ethernet. Eu queria aumentar o MTU em todos os sistemas para que os quadros jumbo fossem transferidos, para reduzir a carga da CPU no servidor ao receber fluxos HD de muitas câmeras, no entanto, notei que mesmo com as configurações de MTU padrão (1500 bytes), as câmeras já enviam quadros jumbo.
Em mais detalhes:
- no servidor
ip l
mostra para a interface de rede:2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
; ou seja, MTU 1500. - na interface web de gerenciamento do switch, verifiquei o MTU para a interface em direção ao servidor e para as interfaces em direção às câmeras. Eles estão definidos como MTU = 1500 e L2 MTU = 1592.
- as câmeras não sei como verificar o MTU (elas são uma caixa-preta para mim).
Verifiquei o tamanho dos pacotes transferidos:
no servidor, olhei os pacotes com tcpdump.
tcpdump -i eno2 -s 100 -e | less
mostra pacotes como este:16:25:06.315612 <MAC redacted> (oui Unknown) > <MAC redacted> (oui Unknown), ethertype IPv4 (0x0800), length 9014: camera1.3957 > server.46179: UDP, length 8972
. Os pacotes ethernet têm um tamanho de 9014 bytes.Desativei o "offloading" no servidor, conforme
ethtool --offload eno2 rx off tx off
descrito em https://wiki.wireshark.org/CaptureSetup/Offloading .no switch, posso ver que a interface para uma câmera tem uma taxa RX de ~500 Mbps e uma taxa de pacote RX de ~7000 p/s. Isso resulta em
((500/8)*1024*1024)/7000
= ~9362 bytes/pacote.
Questões:
cometi algum erro na minha análise acima?
É possível que dispositivos de rede enviem pacotes UDP maiores que a MTU configurada de dispositivos intermediários?
Apêndice:
Resultados de ethtool --show-offload eno2
:
Features for eno2:
rx-checksumming: off
tx-checksumming: off
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: off
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off [requested on]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: on
receive-hashing: on
highdma: off [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: on
tx-tunnel-remcsum-segmentation: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: on
tx-gso-list: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: on
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]
rx-gro-list: off
macsec-hw-offload: off [fixed]
rx-udp-gro-forwarding: off
hsr-tag-ins-offload: off [fixed]
hsr-tag-rm-offload: off [fixed]
hsr-fwd-offload: off [fixed]
hsr-dup-offload: off [fixed]
Ainda havia uma interface no switch que tinha uma MTU grande configurada. Após alterar essa MTU para o tamanho normal (MTU=1500 e L2MTU para 1592), nenhuma das câmeras envia mais quadros jumbo, mas apenas quadros de tamanho normal.
Então minha conclusão é: aumentar o L2 MTU em qualquer interface deste switch (mesmo uma não utilizada) torna possível enviar quadros jumbo entre quaisquer interfaces.
Além disso, a MTU no servidor receptor não influenciou esse comportamento. Ela ainda está configurada em 1500, mas o servidor recebe jumbo frames com sucesso. Isso corresponde à sugestão de Tom Yan :
Como as câmeras se comunicam via UDP, essa ideia parece realista.