Como definir limite de upload quando se dispõe de 2 link no servidor?

Ainda nem pude fazer experimentações com o tc+htb aplicando as regras propostas anteriormente aqui e já estou com a cabeça fervendo com as dificuldades que enfrentarei para fazer QoS de upload quando eu tiver 2 links a disposição.Não enfrentarei este mesmo problema para download, pois o tráfego para o cliente vai ser entregue pelo meu roteador QoS.
O "problema" que destaco é porque o upload do cliente ser daria por duas interfaces distintas, uma de cada link, por exemplo, uma com 2mb/s e outra com 1mb/s, enquanto que, voltando ao download, este se dá através de uma única interface de saída.
Digamos que eu queira oferecer ao cliente 256kb/s de download e 128bk/s de upload, estes 256kb/s pode ser uma somatória do que estiver vindo por um ou outro link, mas será sempre entregue por uma única interface de rede do QoS ligada aos clientes. Eu poderia fazer controle de upload em cada uma das interfaces de saída, ou seja, definir 44kb/s de upload pelo link de 1mb/s e 84kb/s de upload pelo link de 2mb, acho que seria um bom cenário, mas recaio no problema de não poder controlar upload desta forma fazendo NAT, pois não poderia identificar o cliente no momento do upload, devido ao tc que trabalharia sobre o IP do roteador NAT que já haveria feito o mascaramento, por exemplo:

+-----+  +-----+
|Link1|  |Link2|
+--+--+  +--+--+
   |        |
+--+--------+--+
|     NAT      |
+------+-------+
       |
       | clientes

Então pensei em um cenário, que ainda não saberia dizer se operaria a contento, ainda vai demandar testes que seria:

+-----+  +-----+
|Link1|  |Link2|
+--+--+  +--+--+
   |        |
+--+--------+--+
|     NAT      |
|    Squid     |
+------+-------+
       |
+------+-------+
|     QoS      |
+------+-------+
       |
       | clientes

No roteador NAT/Squid faria o balanceamento de carga ou mesmo somente o direcionamento de tráfegos, ou seja, http e voip para o link 1 e o resto para o link 2, ou qualquer outra definição mais apropriada.
Tenho um sentimento que esta solução para upload não ofereceria a mesma qualidade no oferecimento de link aos clientes do que o upload, ambos feitos pelo QoS, mas é apenas uma impressão e ainda teria que raciocinar mais.

Um grande abraço a todos.

Usando htb para controle de tráfego por ip priorizando certos serviços

Sempre fui fiel usuário do htb-tools para controle de tráfego do meu roteador de internet na prefeitura de Terra de Areia. É claro que o uso do htb-tools dá-se principalmente pela minha completa falta de competência em saber lidar com o comando tc "na unha".
Minha estrutura é simples, por isto mantenho o squid nesta mesma máquina fazendo nat, o que sempre me trouxe o problema do controle preciso de upload, pois com nat e squid, definitivamente não dá pra fazer controle de upload da mesma forma "simples" que download.
Estes dias passei a estudar traffic control para linux e htb no intuito de preparar um novo roteador que me permitisse controle preciso de download e upload e para isto é lógico que precisava separar o nat e o squid para outra máquina a fim de manter de forma simples estes controles.
Até estava pensando em continuar usando htb-tools, afinal sempre fez muito bem seu trabalho, mas um htb generate eth0 (por exemplo) gerou uma infinidade de regras totalmente incompreensíveis para mim e decidi que queria saber como funcionam as suas entranhas.
A princípio sempre soube que o controle de tráfego é sempre feito no fluxo (interface) de saída e como faço controle de upload com htb-tools ele muda esta política e passa a controlar pelo fluxo de entrada (ingress, pelo menos eu acho).
Ainda estou totalmente cru com todos os conceitos envolvidos em controle de tráfego e com a forma de aplicá-los com o comando tc, por isto resolvi escrever minhas memórias como forma de documentação do meu aprendizado e para que as bondosas almas possam indicar-me minhas falhas.
Sem dúvida o fórum underlinux é minha principal fonte de aprendizado e busca por respostas, mas não posso deixar de citar o manual traduzido do htb e QosLinux.ppt.
Como resultado final deste trabalho pretendo desenvolver uma aplicação em ruby, java, php ou qualquer outra linguagem para que a partir de um arquivo com os ips e taxas de download e upload sejam geradas um conjunto de regras para estes controles.
Ainda não tenho a mínima idéia de como fazer, mas "em cima" do controle de tráfego de cada computador da rede quero fazer também priorização, ou seja, dar prioridade maior para pacotes de voip do que ftp, independente de quem está fazendo download, assim não precisaria prioriza individualmente.
Para começar quero registrar como faria para controlar o tráfego de dowload de um link de 512k entre 4 computadores. A interface da lan (ou saída do tráfego do roteador de internet para a lan) será a eth0, assim as regras para definir taxa garantida de 128k e limite de 512k ficariam assim:
tc qdisc add dev eth0 root handle 1:0 htb default 9
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 512kbit
tc class add dev eth0 parent 1:1 classid 1:9 htb rate 8k
tc class add dev eth0 parent 1:1 classid 1:101 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:102 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:103 htb rate 128k ceil 512k
tc class add dev eth0 parent 1:1 classid 1:104 htb rate 128k ceil 512k
tc qdisc add dev eth0 parent 1:9 handle 90: sfq perturb 10
tc qdisc add dev eth0 parent 1:101 handle 1010: sfq perturb 10
tc qdisc add dev eth0 parent 1:102 handle 1020: sfq perturb 10
tc qdisc add dev eth0 parent 1:103 handle 1030: sfq perturb 10
tc qdisc add dev eth0 parent 1:104 handle 1040: sfq perturb 10
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.101/32 flowid 1:101
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.102/32 flowid 1:102
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.103/32 flowid 1:103
tc filter add dev eth0 protocol ip parent 1:1 u32 match ip dst 192.168.10.104/32 flowid 1:104

Temos assim, a definição do htb como qdisc, a classe que estabelece a capacidade do link em 512k, as classes que definem as taxas para cada ip, as qdisc para cada uma destas classes e os filtros para direcionamento dos tráfegos de saída.
Acredito que seja simplesmente isto para fazer o controle básico de download embora ainda não tenha posto isto em prática. Num futuro gostaria de poder contar com as possíveis vantagens da utilização dos parâmetros quantum, burst e cburst (entre outros).
Por enquanto era isto, assim que conseguir testá-los vou usar basicamente estas mesmas regras com a interface de saída do roteador para o roteador de internet (eth1) para controle de upload, lembrando que não vou fazer nat e nem ter squid neste roteador.