Um alcance de IP tem um desempenho pior do que outros no CentOS 7

0

Eu tenho um servidor, um laptop, um desktop e um roteador doméstico conectado a um switch gigabit. Meu problema é que o servidor tem largura de banda limitada à rede 192.168.1.0/24 . Esse problema não está presente ao usar endereços IPv6 locais de link ou quando um cliente - como o laptop ou a área de trabalho - se conecta ao servidor pela Internet.

Eu descartei a possibilidade de que o problema foi causado por um cliente, pois todos os clientes exibem o mesmo comportamento.

Minha configuração;

  1. tem dois segmentos de rede, 192.168.1.0/24 e a internet
  2. todos os meus dispositivos estão diretamente conectados ao mesmo switch
  3. todos os meus dispositivos têm um IP no intervalo 192.168.1.0/24
  4. a internet pode ser acessada através de um gateway - o roteador em 192.168.1.1 , o NAT obviamente está presente
  5. não há IPv6, além dos locais de link que são configurados automaticamente
  6. não há outros dispositivos, como dispositivos de firewall

Aqui eu demonstro meu problema executando iperf no servidor no modo cliente usando o -c flag.

[user@srv ~]$ iperf3 -c 192.168.1.115
Connecting to host 192.168.1.115, port 5201
[  4] local 192.168.1.40 port 47062 connected to 192.168.1.115 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   853 KBytes  6.98 Mbits/sec    0   59.4 KBytes # Only 6,98 Mbits/sec!
...

[user@srv ~]$ iperf3 -c fe80::[redacted]%eth0
Connecting to host fe80::[redacted]%eth0, port 5201
[  4] local fe80::[redacted] port 36236 connected to fe80::[redacted] port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   111 MBytes   929 Mbits/sec    0    225 KBytes
...
[user@srv ~]$ 

Por favor note;

  1. como a conexão com um cliente (um servidor iperf, neste caso) na rede 192.168.1.0/24 , apresenta uma largura de banda muito ruim.
  2. como o uso de endereços locais de links IPv6 não exibe esse problema.
  3. como nenhum cliente IPv4 conectando-se a partir da Internet enfrenta esse problema.

O servidor iperf, me dá resultados equivalentes. Isso me diz que a limitação de largura de banda é simétrica .

Eu executei iperf entre o laptop e a área de trabalho usando o IPv4, sem problemas. Isso exclui a possibilidade de que o switch, os links ou os dispositivos estejam com defeito.

Tudo aponta para o servidor. Não consigo me lembrar de configurar qualquer modelagem de tráfego.

O servidor roda o CentOS 7, o desktop Windows 10 e o laptop Fedora 26.

Uma coisa notável sobre a rede 192.168.1.0/24 é que o firewall dos servidores é configurado assim:

# firewall-cmd --zone=public --add-interface=eth0
# firewall-cmd --zone=home --add-source=192.168.1.0/24

Eu não acho que uma regra tão simples possa causar um desempenho tão ruim. Eu tentei desativar o firewalld:

# systemctl stop firewalld

Sem sorte. Eu acho que isso exclui a possibilidade de que o problema seja causado pelo iptables.

netstat -i não mostra nada alarmante, os links físicos estão bem.

Eu rodei o libvirt, eu sei que ele tem a capacidade de controlar o iptables. Existem segmentos de rede virtual, como 192.168.122.0/24, que são usados / roteados / dhcp / dnsmasqed por libvirtd. Eu acredito que estes são irrelevantes, pois a tabela de roteamento do servidor está correta. Eu também tentei parar todas as VMs e redes associadas no libvirt. Sem sorte.

Eu executei # iptables -L isso produziu uma lista com 197 linhas, as regras estavam corretas. Para alcançar a zona 'home', um pacote de entrada deve ser comparado com as regras do agaist 12. Então o pacote será comparado com as regras definidas na zona, existem 6 regras na zona 'home'. Não há regras que filtrem a cadeia OUTPUT. Eu descartei o iptables.

Eu não tenho a menor idéia do que devo tentar em seguida?

    
por Axuttaja 27.10.2017 / 21:41

1 resposta

0

Agora resolvi esse problema.

Eu deletei a conexão eth0 no NetworkManager:

# nmcli connection delete id eth0

E, em seguida, criou um substituto equivalente, agora tudo funciona conforme o esperado.

    
por 30.10.2017 / 18:45