Usando tc (porque é o mais atual, e eu sou o mais familiarizado com ele), você deve ser capaz de diminuir o tráfego sem problemas.
Eu tenho um servidor atuando como o firewall (chamado de 'firewall' - muito criativo) e depois um segundo servidor (chamado 'mil102'). sem nenhum comando tc, scp'ando um arquivo de mil102 para movimentos de firewall a toda velocidade:
root@firewall:/data#scp mil102:/root/test.tgz test.tgz
test.tgz 100% 712MB 71.2MB/s 00:10
Adicionando os seguintes comandos ao mil102 (é mais fácil moldar o tráfego de envio):
#!/bin/sh
DEV=eth0
tc qdisc del dev $DEV root
tc qdisc add dev $DEV handle 1: root htb default 11
tc class add dev $DEV parent 1: classid 1:1 htb rate 4Mbps
tc class add dev $DEV parent 1:1 classid 1:11 htb rate 4Mbit
tc qdisc add dev $DEV parent 1:11 handle 11: sfq perturb 10
Agora, o mesmo comando desacelera para 4Mb:
root@firewall:/data#scp mil102:/root/test.tgz test.tgz
test.tgz 0% 6064KB 467.0KB/s 25:48 ETA
Parei a transferência - demoraria muito tempo. A velocidade listada no scp é em bytes, especificada em tc em bits, então 467KB * 9 = 4203Kb, perto do meu limite de 4096Kb (pensei que seria * 8, mas eu acho que há um bit de paridade?).
Eu tentei mudar para 10Mbit e meu scp mostrou que eu estava movendo dados a 1.1MB por segundo (1.1 * 9 = 9.9).
A última linha com a diretiva 'sfq perturb 10' foi adicionada para nivelar o fluxo de tráfego em uma conexão carregada. Ele direciona a fila para receber pacotes de cada conversa com base em um hash round-robin.
Você pode testar com e sem - ssh para uma máquina carregada sem entrar em rajadas, com será muito mais suave (muito importante para VOIP). A 'perturbação 10' diz para recalcular o algoritmo de hash a cada 10 segundos para torná-lo aleatório.