Desde que você pediu uma solução, apresentarei a que eu mencionei e a que o @SatoKatsura mencionou. Primeiro as coisas, gerar carga de rede aleatória geralmente não é a maneira mais útil de realizar testes de carga. Normalmente você precisa recriar um estado realista de alta carga de trabalho. No entanto, lançar dados aleatórios no canal ainda pode fazer sentido se você estiver apenas tentando encontrar informações relacionadas ao desempenho de outra carga de trabalho sob qualquer tipo de carga concorrente.
A linha mais direta para conseguir o que você quer do que você mencionou é o que eu mencionei nos comentários com nc . Configure o terminal de recebimento para que ele escute em alguma porta aleatória e redirecione a saída para /dev/null :
[root@listeningServerFQDN ~]# nc -l listeningServerFQDN 1023 >/dev/null
Em seguida, em um cliente, use nc novamente para enviar seus dados de /dev/urandom para o terminal remoto:
[root@transmit ~]# dd if=/dev/urandom count=65535 bs=1500 | nc listeningServerFQDN 1023
Depois disso, você pode usar qualquer ferramenta que esteja pensando em usar.
Essa é uma solução possível, outra é a ferramenta iperf @SatoKatsura mencionada. Isso é mais voltado para engenheiros de rede que precisam de algum tipo de carga para rodar pela rede por algum motivo. Por exemplo, se eles quiserem testar as políticas de QoS que estão tentando implementar. Nesse caso, eles não se importam se isso não representa uma carga de trabalho, eles estão apenas testando que a largura de banda é limitada de forma apropriada.
O uso básico de iperf envolve a configuração de um processo do servidor:
[root@listeningServerFQDN ~]# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
Em seguida, execute seu teste no cliente:
[root@transmit ~]# iperf -c listeningServerFQDN -r
bind failed: Address already in use
------------------------------------------------------------
Client connecting to transmit.example.com, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[ 4] local 10.762.40.95 port 54610 connected with 10.762.40.95 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 37.1 GBytes 31.8 Gbits/sec
que é duplicado na instância do servidor que acrescenta o seguinte à minha saída:
[ 4] local 10.762.40.95 port 5001 connected with 10.762.40.95 port 54610
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 37.1 GBytes 31.7 Gbits/sec
------------------------------------------------------------
Client connecting to 10.762.40.95, TCP port 5001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[ 4] local 10.762.40.95 port 54640 connected with 10.762.40.95 port 5001
[ 5] local 10.762.40.95 port 5001 connected with 10.762.40.95 port 54640
[ 4] 0.0-10.0 sec 37.4 GBytes 32.1 Gbits/sec
[ 5] 0.0-10.0 sec 37.4 GBytes 32.1 Gbits/sec
Você pode sair de lá obviamente, mas você tem uma ideia geral e pode ver a página de manual para todo o resto.
Meus dois centavos: Eu realmente ficaria com a solução nc se o seu critério fosse apenas "enviar dados aleatórios pelo canal" nc é uma ferramenta geralmente útil que você pode usar por fazer mais do que apenas uma coisa e suspeitar que o caso de uso para iperf seja bem restrito.
Eu usaria nc (ou quaisquer ferramentas com as quais você se sentir mais confortável) para testes rudimentares e graduar para simular a carga real em vez de ir para iperf , que é outro teste "dados aleatórios no canal".