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.

A saga do Oracle com Windows 2003 64bits e o Mono para experimentações

A situação ainda era triste (bom, ainda é), o desenvolvimento do sistema precisava e estava sendo realizado com o Visual Web Developer 2008 Express Edition (VWD), a única coisa com licença para desenvolver asp.net aqui na empresa.
Tudo ocorria tranquilo em minha máquina de desenvolvimento, uma estação windows xp 32bits. Para acesso ao servidor Oracle resolvi utilizar ODP.NET em meus DAOs e o sistema corria bem no servidor embutido do VWD.
Quando resolvi por o sistema em produção em um servidor Windows 2003 64bits com IIS 6, qual não foi a ingrata surpresa de saber que o deploy não ocorerria assim tão fácil, pois de cara, este servidor não tinha suporte a asp.net 2.0. Pois bem, instalamos o abençoado .net 3.5 neste servidor, acreditando que meus problemas estaria acabados, mas não mudou em nada o ambiente. Pesquisando descobri que deveria rodar o aspreg_iis.exe -i para "registrar" o asp.net 2.0 no IIS6.
Legal! Estava registrado e a aplicação agora rodava mas de pronto já berrava exceções referente a impossibilidade de conseguir carregar dll referente ao Oracle. Aí sim que a batalha foi terrível. Como o servidor é 64 bits achamos que o .net deveria ser de 64bits também, mas em lugar algum diz que o .net 3.5 é 32 e 64 bits, então removemos e instalamos o .net 2.0 64bits, afinal o asp.net do .net 3.5 ainda é 2.0.
De nada adiantou as exceções agora só eram diferentes e não permitiam saber exatamente o que estava ocorrendo a não ser pela indicação BadFormatException.
Certamente, então, deveria ser o ODP.NET instalado que não era de 64bits, corremos e instalamos a versão 64bits destes componentes, como podem imaginar, nada de diferente exceções e exceções. Alguns comentários pela web a fora sugeriam que o sistema deveria ser compilado forçadamente como 32 bits e para isto o VWD não servia, pois não dá a opções de escolher o target 32 bits.
A esta altura já estava quase desistindo de utilizar o IIS6 do Windows 2003 64bits para rodar a aplicação. Como tenho meu amado e idolatrado Debian rodando virtualizado com VirtualBox baixei e compilei o mono 2.0 e depois instalei o cliente Oracle. Foi mais fácil executar a aplicação no mono com apache do que no .net com IIS, mas era certo que as exceções referentes ao Oracle continuariam a ocorrer, ou então outras distintas pois até o momento em que pesquisava não encontrara o ODP.NET para mono.
Resolvi mudar meus DAOs e não mais utilizar ODP, passei a utilizar o provider embutido no .net. Já que assim estava, atirei a aplicação no servidor Windows para experimentar, mas não teve jeito, aí passaram a ocorrer outras exceções distintas referente à falta de suporte ao cliente Oracle que fosse inferior a versão 8 ponto alguma coisa.
Atirei a aplicação no mono e bala, rodou tranquilo, pelo menos a princípio, algumas vezes ocorriam algumas exceções estranhas referente à acesso aos dados.
Mas eu ainda estava com gana de colocar o sistema a rodar no Windows 2003, pois afinal é nosso ambiente oficial de execução e eu certamente não teria autorização para alocar a aplicação em um servidor de aplicação linux com mono que nem existe na empresa.
Bom, neste momento a coisa foi uma doidura só experimentamos diversas configurações e versões de ODP.NET de 32 e 64 bits, .net em 32 e 64bits. Nesta altura já tinha voltado meus dados para utilizar ODP.NET.
Em alguma momento conseguimos descobrir que o famigerado IIS 6 roda em 32 bits. Esta "descoberta" foi para alimentar a escalada final da decepção com este servidor. Não dava pra acreditar que o servidor web oficial e nativo do servidor Windows 64bits rodava em 32bits!
Finalmente deixamos tudo em 32 bits, .net e odp.net e conseguimos correr a aplicação tranquilamente.