Como otimizar a taxa de transferência em um NAT / roteador linux?

2

Estou tentando usar um velho Fujitsi RX300S2, com um processador Intel Xeon quad core a 2.80 GHz como um roteador NAT Gitabit, ele tem uma placa de rede dual gigabit a bordo sobre PCI-X.

O roteador também encaminhará o tráfego multicast da interface externa para a rede interna. O roteamento multicast é tratado pelo roteador Cisco a montante, de forma que o roteador NAT precisa apenas "vazar" o tráfego multicast entre eth1 (upstream) e eth0 (internal).

Isso foi configurado corretamente usando o igmpproxy, o que basicamente faz o roteador L3 agir como uma ponte L2 de acordo com o tráfego multicast.

Ao testar o throughput, não tenho problema em receber ~ 850-900Mbit de tráfego multicast em 200 grupos / fluxos (aproximadamente 80.000 p / s) para um processo local no userspace, que também analisa os 200 fluxos em tempo real sem pacote perda. O processo local atinge um núcleo em 100%.

Os fluxos consistem em fluxos de transporte MPEG IPTV encapsulados em pacotes IP UDP. 7x188 = 1316 bytes de carga útil.

Mas ao testar o throughput no modo de encaminhamento, por exemplo, o tráfego multicast entra na eth1 e é roteado no nível do kernel para eth0 e enviado para a rede local, o roteador NAT não pode encaminhar todo o tráfego recebido.

A interface externa eth1 recebe todo o tráfego multicast ~ 900Mbit, mas a interface de saída transmite apenas ~ 600Mbit e todos os fluxos sofrem perda de pacotes de acordo com a máquina de teste de recepção anexada à eth0.

Ao analisar a carga, o ksoftirqd / 3 atinge o máximo de 100% da CPU, mas os outros 3 núcleos estão abaixo de 10%, então parece que nem todos os 4 núcleos participam da carga.

As interrupções / proc / também mostram que eth0 e eth1 compartilham irq16:

    CPU0 CPU1  CPU2       CPU3
16:    0    0 92155  208280892   IO-APIC   16-fasteoi uhci_hcd:usb2, uhci_hcd:usb5, eth1, eth0

Como pode ser visto, a CPU3 lida com uma quantidade desproporcional de interrupções.

Eu tenho lido vários textos sobre cpu_affinity e tentando fixar núcleos de CPU em filas de rede. Infelizmente, essa NIC tg3 da Broadcom não suporta várias filas, mas ainda assim, deve ser possível compartilhar a carga entre mais núcleos neste sistema quad core.

Ou é o barramento PCI-X que é o gargalo, mas se for o caso, o throughput deve ser reduzido tanto na eth1 de entrada quanto na eth0 de saída e os pacotes devem ser eliminados por eth1, mas parece que os pacotes estão perdidos entre eth1 e eth0. Não é verdade, desde quando os pacotes são perdidos no roteador, / sys / class / net / eth1 / statistics / rx_missed_errors é incrementado muito (cerca de 1000 p / s).

Quando apenas 100 canais e aproximadamente 500 Mbits são encaminhados, a perda de pacotes não acontece e o ksoftirqd / 3 consome apenas cerca de 5-6% da CPU. Mas quando o 600Mbit é encaminhado, o ksoftirqd / 3 consome 100%, então parece que algum gargalo fora da CPU é atingido.

É fora de questão que um servidor antigo como este é capaz de encaminhar 1Gbit de tráfego UDP em uma direção apenas entre dois construídos em NICs? Mesmo que os pacotes sejam grandes, 1316 bytes de carga, o que dá uma média de 80..90kp / s em 1Gbit?

    
por ernelli 21.04.2016 / 22:17

1 resposta

2

Nós abandonamos o servidor, especificando que as duas interfaces de rede integradas não deveriam direcionar o tráfego total de gigabit. A segunda interface foi recuada para ser usada para gerenciamento.

Um núcleo de mesa padrão i5 com PCIe e dois adaptadores gigabit Intel i210 conseguiram encaminhar o tráfego UDP multicast de 1 Gbit sem problemas.

Embora, seja necessário ajustar os buffers RX e TX (ethtool -G) devido à intermitência no tráfego. Um PCIe 2x ou 4x provavelmente ajudaria a reduzir o risco de pacotes perdidos devido ao congestionamento do barramento PCIe.

    
por 27.04.2016 / 09:16