Perguntas[linux-networking](server)

Tenho duas conexões WAN alimentando meu roteador Linux homebrew. Ambas são apresentadas como conexões ethernet. Uma usa dhcp, a outra é PPPoE. Configurei ambas usando nmcli.

O próximo passo é usar o roteamento de políticas para sistemas selecionados. Como teste, adicionei uma tabela de roteamento para cada conexão WAN, criei dois novos IPs no lado LAN do roteador e adicionei uma regra de IP para cada um desses IPs para usar uma das tabelas de roteamento. Isso também funciona bem quando configurado manualmente usando comandos iproute2.

O problema surge quando tento configurar esse cenário com nmcli. Chego perto com:

nmcli con mod pppoe ipv4.routes "0.0.0.0/0 onlink=1 table=200"
nmcli con mod pppoe ipv4.routing-rules "priority 999 from 10.87.3.204 lookup 200"
nmcli con up pppoe

nmcli con mod eth2 ipv4.routes "0.0.0.0/0 onlink=1 table=201"
nmcli con mod eth2 ipv4.routing-rules "priority 999 from 10.87.3.59 lookup 201"
nmcli con up eth2

Fiquei agradavelmente surpreso ao descobrir que a conexão PPPoE realmente funcionou, já que deixar a opção nexthop fora da regra faz com que o padrão seja usar o dispositivo para roteamento, que é exatamente o que eu fiz manualmente.

Entretanto, fazer o mesmo para a conexão dhcp não funciona, pois usar 'dev eth2' para a rota está errado... Ele precisa do endereço do próximo salto/gateway, que é dinâmico e o que eu fiz manualmente.

Obviamente, criar um script para atualizar a tabela de roteamento é simples, mas seria melhor fazer o gerenciador de rede fazer isso quando a conexão for criada. Ele obviamente terá essas informações, como a interface ppp é conhecida pela conexão PPPoE.

Existe algum mecanismo para incorporar ip4.gateway na sequência de roteamento? Ou existe outro método para atingir o mesmo objetivo?

Não sou especialista em nmcli, pois nos anos passados ​​sempre o evitei. Estou gostando do desafio de lidar com ele agora, então espero que haja algo muito básico que eu tenha perdido e que não tenha aprendido na minha jornada até agora.

Qualquer ajuda seria apreciada

Gostaria de saber se alguém tem dados para me dar suporte. Estou configurando um lote de mini PCs com placa RTL 8125 2.5 Gb/s e, de fábrica, parece estar funcionando bem usando o driver Ubuntu stock r8169.

No entanto, só consegui testá-lo com um switch de 1000 Mb/s, e pesquisas mostram que há problemas de estabilidade quando a velocidade negociada é, na verdade, 2,5.

Alguém tem experiência usando RTL 8125 em um switch de 2,5 Gb/s via r8169 (fornecido com o Ubuntu 22) e exemplos reais de problemas que podem ocorrer?

Entre os servidores, windows-in-Finland <-> linux-in-Germanyestou enfrentando um upload 100x mais lento que o download ( windows -> linuxé 100x mais lento que windows <- linux).

Detalhes e pesquisas existentes

Inicialmente, observei esse problema com clientes Windows em todo o mundo e percebi que também posso reproduzi-lo em ambientes de data center controlados.

Para reproduzir o problema, estou usando o provedor de datacenter Hetzner, com a Windowsmáquina na Finlândia (servidor dedicado, Windows Server 2019), fazendo upload para ambos:

• Linux Hetzner dedicado Alemanha: lento
• Linux Hetzner Cloud VM Alemanha: rápido

Ambos estão no mesmo parque de datacenter e, portanto, ambos têm 37 ms pingda máquina Windows. Enquanto a conexão entre a Finlândia e a Alemanha geralmente está na rede privada da Hetzner, ela está atualmente sendo redirecionada por meio de rotas públicas de Internet devido à interrupção do cabo submarino C-LION1 2024 do Mar Báltico ( mensagem de status da Hetzner sobre isso ), então a conexão "simula" o uso de rotas e peerings normais de Internet pública.

Estou medindo com iperf3, windows <- linux:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-dedicated.examle.com

Connecting to host linux-germany-dedicated.examle.com, port 5201
[  5] local 192.0.2.1 port 62234 connected to 192.0.2.2 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  15.8 MBytes   132 Mbits/sec
[  5]   1.00-2.00   sec  1.88 MBytes  15.7 Mbits/sec
[  5]   2.00-3.00   sec  1.38 MBytes  11.5 Mbits/sec
[  5]   3.00-4.00   sec  1.75 MBytes  14.7 Mbits/sec
[  5]   4.00-5.00   sec  2.25 MBytes  18.9 Mbits/sec
[  5]   5.00-6.00   sec  2.88 MBytes  24.1 Mbits/sec
[  5]   6.00-7.00   sec  3.25 MBytes  27.3 Mbits/sec
[  5]   7.00-8.00   sec  3.38 MBytes  28.3 Mbits/sec
[  5]   8.00-9.00   sec  2.75 MBytes  23.1 Mbits/sec
[  5]   9.00-10.00  sec  1.25 MBytes  10.5 Mbits/sec

Mais iperf3observações:

• A outra direção (adicionando -R) iperf3é muito mais rápida, a ~900 Mbit/s. (Observe que os lados do Linux estão usando o controle de congestionamento BBR, o que provavelmente ajuda nessa direção.)
• Ao fazer download com 30 conexões ( iperf3com -P 30), a conexão de 1 Gbit/s é atingida no máximo, sugerindo que o problema é a taxa de transferência de upload de uma única conexão de upload TCP .
• Ao substituir a máquina Windows por uma Linux na Finlândia, ambas as direções atingem o máximo de 1 Gbit/s de conexão. Isso me leva a concluir que o envolvimento do Windows é a falha .
• Observe que há um artigo da Microsoft alegando que iperf3é o melhor para medições de alto desempenho no Windows. Isso não é relevante para esta questão porque se aplica apenas a conexões >= ~10 Gbit/s, e o fato de que iperf3 em várias máquinas Windows/Linux no mesmo datacenter prova que a velocidade de 1 Gbit/s é facilmente atingível iperf3em ambas as direções.

Em 2021, o Dropbox lançou um artigo Aumentando a velocidade de upload do Dropbox e melhorando a pilha TCP do Windows , que aponta o tratamento incorreto (incompleto) do Windows de retransmissões TCP; a Microsoft publicou Melhorias algorítmicas aumentam o desempenho do TCP na Internet junto com isso.

Isso parece explicar em grande parte, e o Wireguard lento, mas apenas para upload do Windows, mostra uma solução potencial, ou seja, alterar o número de filas RSS ( Receive Side Scaling ) para 1:

ethtool -L eth0 combined 1

Isso muda de 16(16 threads no meu servidor Linux dedicado) para 1 e aumenta a velocidade de upload do iperf3 convergente de 10.5para 330Mbit/s .

Isso é bom, mas deveria ser 1000 Mbit/s.

Especialmente estranho: Ao testar windows -> linux-Hetzner-Cloudem vez de windows -> Hetzner-dedicated, observo velocidades de upload perfeitas:

C:\Users\Administrator\Downloads\iperf3.17.1_64\iperf3.17.1_64>iperf3.exe -c linux-germany-hcloud.example.com

Connecting to host linux-germany-hcloud.example.com, port 5201
[  5] local 192.0.2.1 port 55615 connected to 192.0.2.3 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   108 MBytes   903 Mbits/sec
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec
...
[  5]   9.00-10.00  sec   112 MBytes   942 Mbits/sec

Isso é estranho, porque a máquina de nuvem tem especificações muito mais baixas. Ela tem 8 núcleos virtuais, mas sua ethtool -lsaída já é padrão Combined: 1porque, sendo uma VM, ela não suporta RSS de forma alguma:

root@linux-germany-hcloud ~ # ethtool -x enp1s0

RX flow hash indirection table for enp1s0 with 1 RX ring(s):
Operation not supported
RSS hash key:
Operation not supported
RSS hash function:
    toeplitz: on
    xor: off
    crc32: off

Então, de alguma forma, a máquina mais fraca não tem o problema. Talvez haja alguma coisa inteligente de hardware NIC acontecendo na máquina dedicada que cria o problema? O que poderia ser?

Eu já tentei desabilitar o TCP Segment Offloading ( ethtool -K eth0 tso off), mas isso não afeta os resultados. O recurso que causou o problema no artigo do Dropbox ( flow-director-atr) não está disponível na minha NIC, então não pode ser isso.

Pergunta

O que pode explicar o gargalo adicional de 3x no upload entre os dois servidores Linux?

Como posso obter uploads rápidos apenas do Windows?

Mais informações sobre o meio ambiente

• Ambas as máquinas Linux usam a mesma versão Linux 6.6.33 x86_64e os mesmos sysctls (garantidos via NixOS), que são:

  net.core.default_qdisc=fq
  net.core.rmem_max=1073741824
  net.core.wmem_max=1073741824
  net.ipv4.conf.all.forwarding=0
  net.ipv4.conf.net0.proxy_arp=0
  net.ipv4.ping_group_range=0 2147483647
  net.ipv4.tcp_congestion_control=bbr
  net.ipv4.tcp_rmem=4096 87380 1073741824
  net.ipv4.tcp_wmem=4096 87380 1073741824
  

• Servidor Windows 2019Version 1809 (OS Build 17763.6293)

Editar 1

Descobri que consigo upload de 950 Mbit/s do Windows para outras máquinas dedicadas da Hetzner. As máquinas dedicadas para as quais o upload é lento têm em comum o fato de terem placas de rede Intel de 10 Gbit/s; de lspci:

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

lsmod | grep ixgbesugere que o ixgbedriver seja usado aqui. ixgbetambém é mencionado no artigo do Dropbox acima . O artigo "Por que o Flow Director causa reordenação de pacotes?" que eles vinculam menciona Intel 82599especificamente. Também encontrei este tópico e1000-devel onde alguém menciona o problema em 2011, mas nenhuma solução é apresentada.

Ao usar o cartão de 1 Gbit Intel Corporation I210 Gigabit Network Connection (rev 03)presente no mesmo modelo de servidor, o problema desaparece e obtenho 950 Mbit/s.

Então parece haver algo específico sobre 82599ES/ ixgbeque causa o problema.

Edição 2: Intel Flow Directore tentar fora da árvoreixgbe

Uma pesquisa no Google intel disable flowdirectorproduz https://access.redhat.com/solutions/528603 mencionando Intel 82599.

Ajuda:

O Intel Flow Director é um recurso de driver e NIC da Intel que fornece direção inteligente e programável de tráfego de rede semelhante (ou seja, um "fluxo") para filas de recebimento específicas.

Por padrão, o Flow Director opera no modo ATR (Application Targeted Receive). Isso executa hash regular no estilo RSS quando tráfego não visto anteriormente é recebido. No entanto, quando o tráfego é transmitido, a tupla (ou "fluxo") desse tráfego é inserida na tabela de hash de recebimento. O tráfego futuro recebido na mesma tupla será recebido no núcleo que o transmitiu. O processo de envio e recebimento pode então ser fixado no mesmo núcleo que a fila de recebimento para melhor afinidade de cache da CPU.

Observe que a pesquisa da comunidade mostrou que o ATR pode causar tráfego TCP Out-of-Order quando processos são migrados entre CPUs . É melhor fixar explicitamente processos em CPUs ao usar o modo ATR.

O FlowDirector é mencionado no artigo do Dropbox, assim como o ATR.

A "pesquisa comunitária" mencionada é o mesmo artigo "Por que o Flow Director causa reordenação de pacotes?" ao qual o Dropbox se refere.

Fazendo o sugerido

ethtool -K net0 ntuple on

melhora a velocidade de 20 Mbit/s para 130 Mbit/s (com o padrão ethtool -L net0 combined 16). Executá-lo por mais tempo ( iperf3 --time 30) faz com que ele caia para 80 Mbit/s após 16 segundos. Usar ntuple onjunto com combined 16não melhora mais.

Portanto, esta não é uma solução completa.

Testando a options ixgbe FdirMode=0abordagem em seguida.

Sobre ram256g-1:

rmmod ixgbe; modprobe ixgbe FdirMode=0; sleep 2; ifconfig net0 94.130.221.7/26 ; ip route add 192.0.2.2 dev net0 proto static scope link ; ip route add default via 192.0.2.2 dev net0 proto static ; echo done

dmesgmostra

ixgbe: unknown parameter 'FdirMode' ignored

Isso apesar de https://www.kernel.org/doc/Documentation/networking/ixgbe.txt documentá-lo:

FdirMode
--------
Valid Range: 0-2 (0=off, 1=ATR, 2=Perfect filter mode)
Default Value: 1

  Flow Director filtering modes.

Então 0=offparece ainda mais desejável que os outros dois, que supostamente são os que ntuple on/offalternam entre eles.

https://access.redhat.com/solutions/330503 diz

A Intel optou por expor algumas configurações como um parâmetro de módulo em seu driver SourceForge, no entanto, o kernel Linux upstream tem uma política de não expor um recurso como uma opção de módulo quando ele pode ser configurado de maneiras já disponíveis, então você só verá alguns parâmetros de módulo em drivers Intel fora da árvore do kernel Linux upstream.

A Red Hat segue os métodos do kernel upstream, então essas opções não estarão na versão RHEL do driver, mas a mesma coisa pode ser feita com ethtool(e sem) uma recarga de módulo.

Isso sugere que isso 0=offnão é realmente possível.

Ou talvez funcione com modprobe.dopções, mas não com o modprobecomando?

Código relevante:

• Kernel antigo com a FdirModeopção:
  • https://github.com/spotify/linux/blob/6eb782fc88d11b9f40f3d1d714531f22c57b39f9/drivers/net/ixgbe/ixgbe_param.c#L285C24-L285C37
  • https://github.com/spotify/linux/blob/6eb782fc88d11b9f40f3d1d714531f22c57b39f9/drivers/net/ixgbe/ixgbe_param.c#L1034-L1040
• Novo kernel sem:
  • https://github.com/torvalds/linux/blob/b86545e02e8c22fb89218f29d381fa8e8b91d815/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c#L648
    • Sugere que o Flow Director só seja habilitado se o comprimento da fila RSS for> 1
    • Então provavelmente definir o comprimento da fila como 1 com ethtool -L(que é --set-channels) já deve resolver isso.

Mas parece que https://github.com/intel/ethernet-linux-ixgbe ainda está sendo desenvolvido ativamente e suporta todas as opções antigas. Também suporta FdirPballoco que nunca existiu em torvalds/linux. Isso é descrito em: https://forum.proxmox.com/threads/pve-kernel-4-10-17-1-wrong-ixgbe-driver.35868/#post-175787 Também relacionado: https://www.phoronix.com/news/Intel-IGB-IXGBE-Firmware-Update Talvez eu deva tentar construir e carregar isso?

Desse driver, FDirModetambém foi removido:

• https://github.com/intel/ethernet-linux-ixgbe/commit/a9a37a529704c584838169b4cc1f877a38442d36
• https://github.com/intel/ethernet-linux-ixgbe/commit/a72af2b2247c8f6bb599d30e1763ff88a1a0a57a

De https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20160919/006629.html :

ethtool -K ethX ntuple on

Isso habilitará o modo "filtro perfeito", mas ainda não há filtros, então os pacotes recebidos retornarão ao RSS.

Testado

ethtool -K net0 ntuple on
ethtool --config-ntuple net0 flow-type tcp4 src-ip 192.0.2.1 action 1

Não melhorou a velocidade.

Também descobri que a velocidade no Linux 6.3.1parece ser de 90 Mbit/s, enquanto no 6.11.3.

Compilando o out-of-tree ethernet-linux-ixgbeno Hetzner Rescue System Linux (old)que tem 6.3.1(ainda não há lançamento para Linux 6.11):

wget https://github.com/intel/ethernet-linux-ixgbe/releases/download/v5.21.5/ixgbe-5.21.5.tar.gz
tar xaf *.tar.gz
cd ixgbe-*/src && make -j

# because disconnecting the ethernet below will hang all commands
# from the Rescue Mode's NFS mount if not already loaded into RAM
ethtool --help
timeout 1 iperf3 -s
dmesg | grep -i fdir

modinfo /root/ixgbe-*/src/ixgbe.ko  # shows all desired options

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

iperf3 -s

Este driver fornece 450 Mbit/s mais sólidos imediatamente.

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko FdirPballoc=3; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

dmesg | grep -i fdir

iperf3 -s

Não traz nenhuma melhoria.

Experimente também:

AtrSampleRate

Um valor de 0 indica que o ATR deve ser desabilitado e nenhuma amostra será coletada.

rmmod ixgbe; insmod /root/ixgbe-*/src/ixgbe.ko AtrSampleRate=0; sleep 2; ifconfig eth1 94.130.221.7/26 ; ip route add 192.0.2.2 dev eth1 scope link ; ip route add default via 192.0.2.2 dev eth1 ; echo done

dmesg | grep -i atrsample

iperf3 -s

Não traz nenhuma melhoria.

ethtool -L net0 combined 1aqui também não traz nenhuma melhoria, e

ethtool -K eth1 ntuple on
ethtool -L eth1 combined 12  # needed, otherwise the out-of-tree ixgbe driver complains with `rmgr: Cannot insert RX class rule: Invalid argument` when `combined 1` is set
ethtool --config-ntuple eth1 flow-type tcp4 src-ip 192.0.2.1 action 1

também não traz nenhuma melhoria.

Edição 3: NIC alterado

Alterei a NIC do servidor Linux de Intel 82599ES para Intel X710, que usa o i40edriver Linux.

O problema persistiu.

Suspeito que seja porque o X710 também suporta o Intel Flow Director.

A mitigação parcial ethtool -L eth0 combined 1tem o mesmo efeito que para o 82599ES.

O comando

ethtool --set-priv-flags eth0 flow-director-atr off

(o que é possível i40e, mas não ixgbe) mencionado pelo Dropbox como solução alternativa só alcançou a mesma aceleração que ethtool -L eth0 combined 1(em torno de 400 Mbit/s).

Curiosamente, Hetzner relatou que as máquinas Hetzner Cloud também são equipadas com Intel X710 , mas não apresentam o problema.

Tive problemas de rede ultimamente (executando Debian, mas não específicos para nenhuma distro, veja abaixo usando manipulação direta de /sys), e descobri que a fonte dos meus problemas era que dois servidores com interfaces de rede vinculadas tinham o mesmo endereço de hardware em suas vinculações. Este endereço MAC NÃO é um dos endereços das interfaces de hardware, embora devesse ser (de acordo com a maioria das documentações, como esta ):

A interface de ligação tem um endereço de hardware de 00:00:00:00:00:00 até que o primeiro escravo seja adicionado. Se a interface VLAN for criada antes da primeira escravização, ela pegaria o endereço de hardware todo em zeros. Uma vez que o primeiro escravo é anexado à ligação, o próprio dispositivo de ligação pegará o endereço de hardware do escravo, que então fica disponível para o dispositivo VLAN.

Além disso, ao contrário do que é declarado nesta documentação, um vínculo "vazio" (sem nenhum escravo) não tem um endereço de hw 00:00:00:00:00:

# modprobe bonding
# echo +bond0 > /sys/class/net/bonding_masters 
# ip link show bond0
3: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether d6:f5:8e:9f:c2:42 brd ff:ff:ff:ff:ff:ff

No entanto, esses endereços de hardware mudam para o endereço de hardware do escravo se e somente se o escravo for adicionado imediatamente ao vínculo e o endereço do vínculo não for verificado. Eu testo com um script muito simples (veja abaixo) para manipular o vínculo.

• Primeiro, ele cria um vínculo vazio sem escravos e exibe seu endereço de hardware (que aparentemente é pseudoaleatório, mas tende a permanecer o mesmo — talvez o udev tenha um papel aqui?).
• Em segundo lugar, ele cria o vínculo, define seu modo e adiciona um escravo: o vínculo pega o endereço de hardware do escravo conforme o esperado.
• Terceiro, ele cria o vínculo, lê seu endereço de hardware , define o modo e adiciona um escravo: o endereço de hardware do vínculo não corresponde ao endereço de hardware do escravo (mas executando o script repetidamente, de vez em quando ele corresponde! Vai entender).
• Quarto, ele cria o vínculo, espera um segundo e então o configura como na etapa 2. O comportamento é basicamente o mesmo da etapa 3: o vínculo tem o mesmo endereço de hardware pseudoaleatório da etapa 1, que sempre difere do endereço de hardware do escravo e é sempre o mesmo.

Não sei exatamente como o endereço de hardware pseudoaleatório do vínculo é configurado, mas ele é relativamente repetitivo em diversas configurações de hardware e software (hardware diferente, versões de kernel diferentes, versões de Debian diferentes).

Às vezes, no passo 3, o endereço MAC do bond muda para diferentes valores pseudoaleatórios, às vezes ele corresponde ao endereço do escravo. Na maioria das vezes, no entanto, ele permanece o mesmo do passo 1. No passo 4, o endereço MAC do bond é sempre o mesmo do passo um.

Aparentemente a configuração do endereço MAC do vínculo é muito sensível ao tempo?

Aqui está o roteiro:

echo "unload / load bonding"
rmmod bonding
sleep 1
modprobe bonding
sleep 1
echo "create bond0"
echo +bond0 > /sys/class/net/bonding_masters
echo "bond0 hw address, no slaves:"
cat /sys/class/net/bond0/address
sleep 3
echo "################"
echo "unload / load bonding"
rmmod bonding
sleep 1
modprobe bonding
sleep 1
echo "create bond0 and configure it without delay"
echo +bond0 > /sys/class/net/bonding_masters
# cat /sys/class/net/bond0/address
echo 6 > /sys/class/net/bond0/bonding/mode
echo +enp1s0  > /sys/class/net/bond0/bonding/slaves
echo "Bond0 hw address:"
cat /sys/class/net/bond0/address
echo "enp1s0 hw address:"
ethtool -P enp1s0

echo "################"
sleep 3
echo "unload / load bonding"
rmmod bonding
sleep 1
modprobe bonding
sleep 1
echo "create bond0 and configure it, read its hw address first"
echo +bond0 > /sys/class/net/bonding_masters
cat /sys/class/net/bond0/address
echo 6 > /sys/class/net/bond0/bonding/mode
echo +enp1s0  > /sys/class/net/bond0/bonding/slaves
echo "Bond0 hw address:"
cat /sys/class/net/bond0/address
echo "enp1s0 hw address:"
ethtool -P enp1s0

echo "################"
sleep 3
echo "unload / load bonding"
rmmod bonding
sleep 1
modprobe bonding
sleep 1
echo "create bond0 and configure it after 1 second delay"
echo +bond0 > /sys/class/net/bonding_masters
# cat /sys/class/net/bond0/address
echo 6 > /sys/class/net/bond0/bonding/mode
sleep 1
echo +enp1s0  > /sys/class/net/bond0/bonding/slaves
echo "Bond0 hw address:"
cat /sys/class/net/bond0/address
echo "enp1s0 hw address:"
ethtool -P enp1s0

E aqui está a saída:

unload / load bonding
create bond0
bond0 hw address, no slaves:
ea:dc:34:e6:7c:8d
################
unload / load bonding
create bond0 and configure it without delay
Bond0 hw address:
52:54:00:c8:76:09
enp1s0 hw address:
Permanent address: 52:54:00:c8:76:09
################
unload / load bonding
create bond0 and configure it, read its hw address first
d6:f5:8e:9f:c2:42
Bond0 hw address:
d6:f5:8e:9f:c2:42
enp1s0 hw address:
Permanent address: 52:54:00:c8:76:09
################
unload / load bonding
create bond0 and configure it after 1 second delay
Bond0 hw address:
d6:f5:8e:9f:c2:42
enp1s0 hw address:
Permanent address: 52:54:00:c8:76:09

De tempos em tempos, o endereço hw do bond muda para algum outro valor. No entanto, na maioria das vezes ele volta para o mesmo (aqui 'd6:f5:8e:9f:c2:42') e parece circular por um número limitado de endereços MAC entre reinicializações.

No entanto, o problema muito sério é que máquinas diferentes acabam com o mesmo endereço de hardware pseudoaleatório; quando estão conectadas ao mesmo switch de rede, o caos se instala. Na verdade, verificando em várias máquinas diferentes conectadas a redes diferentes, pelo menos 4 compartilham o mesmo endereço MAC de ligação (embora, desde que não estejam conectadas juntas ao mesmo switch, é basicamente inofensivo).

Observe que naquele exemplo em particular eu configurei o bond no modo 6, mas tive o problema na máquina rodando no modo 4 (802.3ad) e outros modos. Isso não parece relacionado ao modo de bonding de forma alguma -- mudar o mais para 1 ou 2 ou 4 não muda o endereço MAC.

É claro que eu poderia forçar o endereço MAC do vínculo para algum valor significativo usando um script if-up.d ou algo semelhante, mas prefiro ter algo que funcione imediatamente :)

Recebi 4 endereços IP estáticos do meu ISP em um plano de negócios que devem ser usados ​​em um roteador com Linux e configurados por meio do ipcomando. Meu ISP anterior me deu 4/32 endereços IP que simplesmente exigiam serem adicionados à interface WAN e funcionariam independentemente um do outro; no entanto, meu novo ISP me deu um bloco /30 "roteado" de 4 endereços IP.

Não consegui descobrir como adicionar esses endereços IP quando recebo error: nexthop has invalid gatewayou os endereços IP são adicionados, mas não consigo resolver nenhum endereço IP externo ou host de destino.

A configuração de rede do meu novo ISP é a seguinte:

• WAN: 1.1.1.2/30
• Portal: 1.1.1.1/30
• Roteado: 1.1.1.4/30

Meu ISP afirma que o endereço do gateway pode não ser necessário e usar o endereço WAN como upstream. Meu roteador possui 2 NICs; 1 para LAN e 1 para WAN. Também estou usando iptablespara configurar o firewall.

Como esta configuração é configurada corretamente em um sistema Linux por meio do ipcomando?

Quero que uma determinada placa de rede se comporte como se fosse uma placa de rede mais lenta. Como se a interface 1G do meu laptop fosse na verdade uma interface de 100M ou 10M. Uma maneira de fazer isso é desenterrar meu antigo hub de 10 bits e usá-lo para essa finalidade.

Tenho certeza de que existe uma "solução de software" para isso. E, de fato, parece que o tccomando e o tbfrecurso são capazes de fazer isso.

Infelizmente, não compreendo totalmente o conceito para alcançar o que escrevi acima. Parece que há alguma matemática envolvida para levar em consideração a velocidade do link assumida /sys/class/net/*/speed, provavelmente o MTU de /sys/class/net/*/mtue a taxa de tick do sistema. Não tenho certeza se o último ainda é necessário atualmente com os kernels de distribuição "atuais" (eu tenho CONFIG_NO_HZ=ye CONFIG_HZ_300=ypor exemplo).

Como seria um script de shell para tornar esse recurso mais genérico? Comobash link-bandhwidth.sh <interface> 10m|100m|1G|2.5G|10G

Editar:

Conforme sugerido por @vidarlo, alterar a velocidade do link realmente funciona. Consegui alterar a lista de velocidades anunciadas para portas individuais no switch. Tive resultados mistos com o uso do ethtool, mesmo em placas mlx5 que ofereciam várias velocidades diferentes.

Eu também tenho uma placa mlx4 que suporta apenas uma velocidade. Aqui tentei o nccomando sugerido, mas incompleto. Daí a questão de como gerar programaticamente os valores ideais. Esta parte permanece sem resposta, até agora. Para mim, um comando como este funcionou em um link 10G de velocidade fixa:

tc qdisc add dev $interface root tbf rate 2000mbit latency 1ms burst 2000mbit

Isso se comporta como uma placa 2G hipotética, mas provavelmente os valores de latência e burst têm espaço para melhorias. Também tentei 1000mbite 100mbitcom os resultados esperados.

Sou novo no conceito de construção de seu servidor e estava lendo sobre hipervisores. Aprendi que o KVM é um hipervisor tipo 1 e pode ser instalado diretamente no servidor sem sistema operacional. Mas o que me confundiu é que para instalar o módulo KVM você precisa do kernel Linux. Então, como você cria uma unidade inicializável com hipervisor e KVM instalados e sem necessidade de instalar uma distribuição Linux primeiro. Não foi possível encontrar nenhum artigo que explique esse conceito ou talvez meu entendimento não esteja correto.

Eu tenho um manual do Ansible que uso para configurar novas VMs Linux. Recentemente, estava construindo uma nova VM com Ubuntu 22.04. O manual escreverá alguns arquivos de configuração relacionados à rede e outros enfeites, e então a etapa final do processo é usar o Ansibles ansible.builtin.packagepara instalar todas as atualizações de pacotes.

- name: "Install updates"
  become: true
  ansible.builtin.package:
    upgrade: "dist"
  register: res_pkg_updates
  notify: "reboot system"
  tags: [ never, updates ]

Minha VM foi criada a partir de um modelo que fiz há alguns meses, então o sistema operacional Ubuntu tinha alguns pacotes desatualizados, o que não é inesperado. O problema é que um dos pacotes deve suportar ou fornecer funcionalidade de rede. Portanto, quando os packagemódulos iniciam a VM no caminho de instalação das atualizações, o daemon de rede é reiniciado e a VM obtém o novo IP que foi configurado anteriormente em meu manual. Isso faz com que a tarefa do Ansible seja interrompida, aguardando uma reconexão com uma máquina que agora está em um IP diferente.

Quero saber como configurar minha ansible.builtin.packagetarefa para instalar atualizações de pacotes, mas não reiniciar nenhum serviço, especialmente rede.

Estou tentando inicializar um túnel IPsec entre uma VM Ubuntu no Google Cloud e um site remoto.

A conexão foi estabelecida corretamente, mas na máquina Ubuntu no Google Cloud não consigo acessar um host na rede remota (172.17.20.25).

Gcloud:

IP público: 50.50.50.50

IP privado: 10.132.0.63/32

Local remoto:

IP público: 100.100.100.100

Rede privada remota: 172.17.20.0/16

ipsec.conf

config setup
        charondebug="all"
        uniqueids=yes
conn intacloud-to-tper
        type=tunnel
        auto=start
        keyexchange=ikev2
        authby=secret
        leftid=50.50.50.50
        leftsubnet=10.132.0.62/32
        right=100.100.100.100
        rightsubnet=172.17.20.0/16 
        ike=aes-sha1-modp2048
        esp=aes-sha1
        aggressive=no
        keyingtries=%forever
        ikelifetime=28800s
        lifetime=3600s
        dpddelay=30s
        dpdtimeout=120s
        dpdaction=restart

tabela de exibição de rota ip 220

172.17.0.0/16 via 10.132.0.1 dev ens4 proto static src 10.132.0.62

status ipsec tudo

    Status of IKE charon daemon (strongSwan 5.9.5, Linux 6.2.0-1019-gcp, x86_64):
  uptime: 2 hours, since Jan 24 17:36:07 2024
  malloc: sbrk 3100672, mmap 0, used 1403424, free 1697248
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Listening IP addresses:
  10.132.0.62
Connections:
site-to-site:  %any...100.100.100.100  IKEv2, dpddelay=30s
site-to-site:   local:  [50.50.50.50] uses pre-shared key authentication
site-to-site:   remote: [100.100.100.100] uses pre-shared key authentication
site-to-site:   child:  10.132.0.62/32 === 172.17.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
site-to-site[1]: ESTABLISHED 2 hours ago, 10.132.0.62[50.50.50.50]...100.100.100.100[100.100.100.100]
site-to-site[1]: IKEv2 SPIs: -, pre-shared key reauthentication in 5 hours
site-to-site[1]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
site-to-site{4}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cb5b6fdd_i 932ca574_o
site-to-site{4}:  AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 27 minutes
site-to-site{4}:   10.132.0.62/32 === 172.17.0.0/16

política ip xfrm

src 10.132.0.63/32 dst 172.17.0.0/16 
    dir out priority 375423 ptype main 
    tmpl src 10.132.0.63 dst 100.100.100.100
        proto esp spi 0xbb44a532 reqid 1 mode tunnel
src 172.17.0.0/16 dst 10.132.0.63/32 
    dir fwd priority 375423 ptype main 
    tmpl src 100.100.100.100 dst 10.132.0.63
        proto esp reqid 1 mode tunnel

Não consigo entender se pode haver um problema de configuração ou se o problema pode estar na configuração do site remoto

Estou tentando aprender a configurar o Wireguard corretamente (não apenas copiando e colando). Encontrei esta linha na página de início rápido :

ip address add dev wg0 192.168.2.1/24

Lendo a página de manual do ip, parece que address addatribui o endereço fornecido ao dispositivo fornecido. Isso faz sentido, exceto que o endereço de exemplo inclui uma máscara CIDR. Estou lutando para entender o que isso significa e meu google-fu está falhando.

Estamos dizendo que queremos que o endereço seja 192.168.2.0, ou... nem sei. O que mais isso poderia significar?

EDIT: Espere, acabei de perceber que esta poderia ser uma forma de especificar a sub-rede. Talvez isso seja óbvio para o pessoal do Linux, mas eu sou um cara do Windows e na GUI do Windows você especifica a máscara de sub-rede separadamente para o IP. Vou deixar essa pergunta aqui caso eu esteja errado.