Arquivos históricos do BR-Linux.org apresenta:

Manual traduzido do controle de banda com o HTB

O Carlos Virgílio Beltrão Lessa (lessacarlos@ig.com.br) mandou para publicação a sua tradução do manual do HTB para Linux, de autoria do Martin Devera (devik@cdi.cz). Já mencionamos o HTB neste espaço recentemente, e como a necessidade de priorização de tráfego e controle de banda é cada vez mais frequente, acredito que esta tradução vá ser uma importante adição ao nosso conjunto de tutoriais.

Manual de regras de enfileiramento HTB Linux - guia do usuário.

Martin Devera aka devik (devik@cdi.cz)
Manual: devik and Don Cohen
Last updated: 5.5.2002
Tradução: Carlos Virgílio Beltrão Lessa (lessacarlos@ig.com.br) em 03/11/2003
Texto novo está em cor vermelha. Após três meses de publicação este destaque é removido. Atualmente representam as modificações HTB3.

1. Introdução

HTB propõe-se ser um substituto mais compreensível, intuitivo e rápido para o CBQ qdisc no Linux. Tanto o CBQ quanto o HTB ajudam você a controlar o uso da largura de banda no tráfego de saída em um link. Ambos permitem você usar um link físico para simular vários links lentos e enviar diferentes tipos de tráfego em diferentes links virtuais. Em ambos casos, voce tem de especificar como dividir o link fisico em links simulados e decidir como cada pacote será enviado em cada link virtual.

Este documento mostra a você como usar o HTB. Muitas seções tem exemplos, gráficos (com avaliação de dados) e discussão sobre problemas específicos.

Esta versão do HTB dispõe-se a ser também muito mais escalável. Veja comparação na home page do HTB.

Por favor leia: a ferramenta tc (não apenas HTB) utiliza atalhos para designar taxa de envio. kbps refere-se a kilobytes e kbit refere-se a kilobits! Este é o maior FAQ sobre o tc no linux.

2. Compartilhamento de link

Problema: Nós temos dois clientes, A e B, ambos conectados à Internet via eth0. Nós queremos alocar 60 kbps para B e 40 kbps para A. Em seguida nós desejamos subdividir a largura de banda de A em 30 kbps para WWW e 10 kbps para quaisquer outros serviços. Qualquer largura de banda não utilizada pode ser utilizada por qualquer classe que necessitar (proporcionalmente à quota destinada a cada classe).

HTB garante que o total de serviço provido para cada classe é no mínimo o total requerido por esta e conforme o que foi designado para cada classe. Quando uma classe requisita menos que o total a ela reservado, a largura de banda remanescente é destribuída para outras classes que requisitaram serviços.

Veja também documento sobre o funcionamento interno do HTB - nele é descrito o objetivo acima mencionado em maiores detalhes.

Nota: Na literatura, usar a largura de banda excedente é denominado de "borrowing" - tomar emprestado. Nós usaremos este termo neste documento em conformidade com a literatura. Entretanto parece-nos ser um termo não muito adequado por não existir nenhuma obrigação de devolver o recurso "tomado emprestado" anteriormente.

Os diferentes tipos de tráfego acima mencionados são representados por classes em HTB. Uma simples representação é exibida na figura acima.
Vamos ver quais comandos usaremos:

tc qdisc add dev eth0 root handle 1: htb default 12
Este comando vincula a regra de enfileiramento HTB para a interface de rede eth0 e aplica a esta o "handle" (manipulador) 1:. Isto é apenas um nome ou identificador que será referenciado abaixo. O default 12 define que qualquer tráfego que não estiver classificado de outra forma será inputado a classe 1:12.

Nota: Em geral (não apenas para HTB, mas para todos qdiscs e classes em tc), manipuladores são escritos em x:y onde x é um inteiro identificando um qdisc e y é um inteiro identificando uma classe pertencente ao qdisc. O manipulador para um qdisc necessita ter zero para seu valor y e o manipulador para uma classe necessita ter um valor diferente de zero para seu valor y. O "1:" acima é considerado como "1:0".

tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps 
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

A primeira linha cria uma classe "raiz", 1:1 embaixo do qdisc 1:. A definição de uma classe raiz é uma que tem o qdisc htb como seu pai. Uma classe raiz, tal como outras classes sob um qdisc htb permite suas filhas tomarem emprestado uma das outras, porém uma classe raiz não pode emprestar de outra. Nós poderíamos ter criado as outras três classes diretamente abaixo do qdisc htb, contudo a largura de banda execedente de uma não estaria disponível para as outras. Neste caso nós queremos permitir o "borrowing", então nós temos de criar uma classe extra para servir como a raiz e colocar as classes que irão realmente trasportar os dados sob aquela. Isto foi definido pelas três linhas subsequentes. O parâmetro ceil será descrito adiante.

Nota: Algumas pessoas vem me perguntando porque elas tem de repetir dev eth0 quando já utilizaram handle ou parent. A razão é que estes manipuladores são alocados para uma interface, ex., eth0 e eth1 podem ter, ambas, uma classe identificada como 1:1.

Nós também temos de definir quais pacotes pertencerão a qual classe. Isto não é realmente relacionado ao HTB qdisc. Veja a documentação do "tc filter" para detalhes. Os comandos serão algo semelhante a isto:

tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
   match ip src 1.2.3.4 match ip dport 80 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
   match ip src 1.2.3.4 flowid 1:11
(Nós identificamos A por este endereço IP o qual nós aqui imaginamos ser 1.2.3.4.)

Nota: O classificador U32 tem um bug de projeto não documentado que provoca entradas duplicadas que podem ser listadas por "tc filter show" quando voce usar classificadores U32 com valores "prio" diferentes.

Você pode observar que nós não criamos um filtro para a classe 1:12. Se tivéssemos feito isto o exemplo poderia ser mais claro, porém desta forma ilustramos a utilização do padrão (default). Qualquer pacote não classificado pelas duas regras acima (qualquer pacote enviado que não seja oriundo do endereço 1.2.3.4) será controlado pela classe 1:12.

Agora nós podemos opcionalmente anexar regras de enfileiramento para as classes folha. Se nada for especificado o padrão é pfifo.

tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10
Estes são todos os comandos que precisamos. Vamos ver o que acontece se nós enviarmos pacotes de cada classe a 90kbps e depois de algum tempo pararmos de enviar pacote em uma das classes. Ao longo da parte inferior do gráfico existem anotações como "0:90k". A posição horizontal no centro do rótulo (neste caso próximo ao 9, também assinalado com um "1" vermelho) indica o tempo no qual a taxa de alguma classe foi modificada. À frente do sinal dois pontos está um identificador para a classe (0 para a classe 1:10, 1 para a classe 1:11 e 2 para a classe 1:12) e após o sinal de dois pontos está a nova taxa no momento onde a anotação aparece. Por exemplo, a taxa da classe 0 é modificada para 90k no tempo 0, 0 (= 0k) no tempo 3, e volta para 90k no tempo 6.

Inicialmente todas classes geram 90k. Considerando que isto é maior que qualquer uma das taxas especificadas, cada classe é limitada a sua taxa definida. No tempo 3 quando nós paramos de enviar pacotes da classe 0, a taxa alocada a esta classe é realocada para as outras duas classes porporcionalmente a suas taxas definidas, uma parte para a classe 1 e seis partes para a classe 2. (O crescimento na classe 1 é difícil de ver porque é de apenas 4 kbps.) Similarmente ao tempo 9 quando o tráfego da classe 1 é interrompido e sua largura de banda é realocada para as outras duas (e o incremento na classe 0 é semelhantemente ruim de ver.) No tempo 15 é fácil visualizar a redistribuição da classe 2 em três partes para a classe 0 e em uma parte para a classe 1. No tempo 18 ambas classes 1 e 2 são paradas então a classe 0 consegue todo tráfego de 90kbps que requisitou.

Agora chegou o momento de tocarmos no conceito de quantums (cotas). Quando muitas classes querem tomar emprestado largura de banda a classe pai fornece a cada uma delas um determinado número de bytes antes de servir as outras classes concorrentes. Este número é denominado cota. Você deveria observar que, quando diversas classes estiverem disputando pela largura de banda de seus pais a obterão proporcionalmente a suas cotas. É importante saber que para operações precisas as cotas necessitam ser o menor possível e maior que o MTU.
A via de regra você não precisa especificar cotas manualmente porque HTB escolhe valores precomputados. Ele calcula a cota da classe (quando você a adiciona ou a modifica) baseado na taxa desta dividida pelo parâmetro global r2q. Seu valor padrão é 10 e este valor é bom para taxas de 15kBps (120 kbit) por que o MTU típico é de 1500. Para taxas muito baixas especificar o r2k 1 quando o qdisc for criado - isto é bom para 12 kbit que deve ser suficiente. Se você precisar você pode especificar a cota manualmente quando acrescentar ou modificar uma classe. Você pode desprezar avisos no log se o valor precomputado vier parecer ruim. Quando você especificar a cota na linha de comando o r2q é ingnorado para aquela classe.

Esta pode ser uma boa solução se A e B não forem clientes diferentes. Por outro lado, se A está pagando por 40kbps então ele muito provavelmente prefere que sua largura de banda WWW não utilizada seja destinada a qualquer outro serviço dele do que seja destinada a B. Este requirimento é representado em HTB por hierarquia de classes.

3. Hierarquia compartilhada

O problema do capítulo anterior é resolvido pela hierarquia de classe nesta figura. O cliente A é agora explicitamente representado por sua classe. Relembrando o que foi dito acima, o total de serviço provido para cada classe é no mínimo o total requerido por esta e conforme o que foi designado para cada classe. Isto se aplica a classes htb que não são pais de outras classes htb. Nós chamamos estas de classes folha. Para classes htb que são pais de outras classes htb, as quais denominamos de classes internas, a regra é a seguinte: o total de serviço provido para cada classe é no mínimo o total requerido por esta e conforme o que foi designado para cada classe e a soma do total requerido por seus filhos. Neste caso nós concedemos 40kbps para o cliente A. Desta maneira se A requisitar menos que a taxa alocada para WWW, o excedente será utilizado por outro tráfego de A (se houver demanda para ele), pelo menos até o total de 40kbps.

Notas: Regras de classificação de pacotes podem ser aplicadas para nós internos também. Então você tem que vincular outra lista de filtros para o nó interno. Finalmente você poderá alcançar classe folha ou especial 1:0. A taxa fornecida para uma classe pai será a soma das taxas de suas classes filhas.

Os comandos agora são os seguintes:

tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 40kbps ceil 100kbps
tc class add dev eth0 parent 1:2 classid 1:10 htb rate 30kbps ceil 100kbps
tc class add dev eth0 parent 1:2 classid 1:11 htb rate 10kbps ceil 100kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps

Agora voltamos ao gráfico demonstrando os resultados da solução hierárquica. Quando o tráfego WWW de A é interrompido, sua largura de banda é realocada para outro tráfego de A, desta forma a largura de banda total de A mantém-se nos 40kbps concedidos. Se A requisitar menos que 40kbs no total é que o execedente poderá ser cedido a B.

4. Taxa limite

O argumento ceil (limite superior) define a largura de banda máxima que uma classe pode usar. Este argumento limita quanto uma classe pode tomar emprestado. O limite superior padrão é igual a taxa. (Este é o motivo porque nós tivemos de especificar isto nos exemplos acima para demonstrar empréstimo de banda). Agora nós modificamos o limite superior que era de 100kbps das classes 1:2 (A) e 1:11 (outros de A) para 60kbps e 20kbps respectivamente.

O gráfico abaixo difere do anterior porque no tempo 3 (quando o tráfego WWW para) os outros de A são limitados a 20kbps. Consequentemente o cliente A consegue apenas 20kbps no total e os 20kbps não utilizados são alocados a B. A segunda diferença é quando o tráfego de B é interrompido no tempo 15. Sem o limite superior, toda a largura de banda de B seria destinada a A, mas agora só é permitido apenas 60kbps e os 40kbps restantes permanecem sem uso.

Esta característica pode ser útil para ISPs (provedores de serviço internet) porque eles provavelmente desejam limitar o total de serviços fornecidos a seus clientes quando outros clientes não estão utlizando suas respectivas cotas. (ISPs provalvemente querem que seus clientes paguem mais por serviços melhores.) Lembre-se que as classes raiz não tem permissão de tomar emprestado, então não é realmente essencial especificar limite para elas.

Notas: O limite para uma classe deve sempre ser no mínimo igual a taxa. Este limite também deve ser sempre, no mínimo, igual ao de seu filho que tiver o maior limite.

5. Rajada (burst)

Hardware de rede pode apenas enviar um pacote em um momento e apenas na taxa limitada ao hardware. Software de compartilhamento de link pode apenas usar esta característica para aproximar-se do efeito de múltiplos links a diferentes (baixas) velocidades. Por esta razão a taxa e o limite superior não são realmente medidos instantaneamente e sim médias sobre o tempo onde já foram enviados muitos pacotes. O que realmente acontece é que o tráfego de uma classe envia alguns pacotes em um tempo na máxima velocidade e em seguida outra classe é servida por um tempo. Os parâmetros burst e cburst controlam a quantidade de dados que podem ser enviados para uma classe na velocidade máxima (hardware) sem tentar servir a outra.

Se o cburst é pequeno (idealmente no tamanho de um pacote) ele forma rajadas para não execeder o ceil (taxa limite) da mesma maneira como peakrate do TBF faz (TBF é outro qdisc e peakrate um de seus parâmetros).

Quando você regula o burst para uma classe pai menor que para alguns filhos então você deveria esperar que a classe pai venha ficar impedida de prosseguir ocasionalmente (porque os filhos requisitam mais do que a classe pai pode manipular). HTB irá lembrar destes bursts negativos em até um minuto.

Você pode se questionar porque precisa de bursts. Bem, ele é o modo fácil e simples de melhorar tempos de resposta em links congestionados. Por exemplo o tráfego WWW é bursty (de rajada). Você solicita uma página, a recebe e então a lê. Durante o tempo de inatividade o burst "carregará" novamente.

Nota: Tanto o burst quanto o cburst de uma classe deve sempre ser, no mínimo, igual ao de seu filho que os tiver maiores.

No gráfico você pode ver o caso do capítulo anterior onde eu modifiquei o burst das classes vermelha e amarela (agência A) para 20kb porém cburst permaneceu padrão (cca 2 kb).
O pico verde no tempo 13 é devido ao burst configurado na classe SMTP. Classe A. Esta manteve-se abaixo do limite desde o tempo 9 e acumulado 20 kb de burst. O pico é até 20kbps (limitado pelo ceil porque ela tem cburst próximo ao tamanho do pacote).
O leitor atento pode questionar porque não há picos no vermelho e no amarelo no tempo 7. Isto acontece porque o amarelo ja está no limite superior e ele não tem mais espaço para rajadas.
Existe pelo menos um resultado indesejável - a cratera lilás no tempo 4. Isto é porque eu intencionamente "esqueci" de adicionar burst para o link da classe raiz (1:1). Ela recordou do pico do tempo 1 e quando no tempo 4 a classe azul necessitou tomar emprestado taxa da amarela ela negou e compensou ela mesma (a classe raiz).

Limitação: quando você opera com taxas altas em computador com temporizador de baixa resolução você precisa configurar burst e cburst mínimos para todas classes. A resolução do temporizador em sistemas i386 é de 10ms e em Alphas é de 1ms. O burst mínimo pode ser calculado como max_rate*timer_resolution. Então para 10Mbit em um modesto i386 você precisa de burst de 12kb.

Se você configurar o burst muito pequeno você obterá taxa abaixo de que definiu. As versões mais recentes da ferramenta tc calculará e configurará o menor burst possível se ele não for especificado.

6. Priorizando a largura de banda compartilhada

Priorizar tráfego apresenta dois aspectos.O primeiro afeta como o excedente de largura de banda é distribuído entre irmãos. Até agora nós temos visto que a largura de banda excedente foi distribuída proporcionalmente a taxa. Agora eu usei a configuração básica do capítulo 3 (hierarquia sem limite superior e rajadas) e modifiquei a prioridade de todas as classes para 1 exceto SMTP (verde) a qual configurei para 0 (maior).
Sob a visão do compartilhamento você pode ver que esta última classe consegue todo excedente de largura de banda. A regra é que para a classe com a prioridade maior será oferecido primeiro o excedente de largura de banda. Porém as regras sobre a respeito de taxa e limite superior contunuam mantidas.

Existe também o segundo aspecto do problema. É o atraso total do pacote. Este é relativamente difícil de medir em ethernet por ser muito rápida (o atraso é insignificante). Porém existe uma fácil solução. Nós podemos adicionar uma classe HTB simples com a taxa limitada a menos de 100 kbps e uma segunda classe HTB (a que nós mediremos) como filho. Então nós podemos simular um link lento com grandes atrasos.
Com o objetivo de simplificar usei um simples cenário com duas classes:

# qdisc para simulação de atraso
tc qdisc add dev eth0 root handle 100: htb
tc class add dev eth0 parent 100: classid 100:1 htb rate 90kbps

# qdisc realmente medido
tc qdisc add dev eth0 parent 100:1 handle 1: htb
AC="tc class add dev eth0 parent"
$AC 1: classid 1:1 htb rate 100kbps
$AC 1:2 classid 1:10 htb rate 50kbps ceil 100kbps prio 1
$AC 1:2 classid 1:11 htb rate 50kbps ceil 100kbps prio 1
tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 2
tc qdisc add dev eth0 parent 1:11 handle 21: pfifo limit 2
Nota: HTB como flho de outro HTB NÃO é o mesmo coisa que classe abaixo de outra classe dentro do mesmo HTB. Isto é porque quando uma classe em HTB pode enviar ela o fará imediatamente quando o dispositivo de hardware permitir. Então o atraso de uma classe sem limites é apenas dependente do equipamento e não das classes ascendentes. No caso de HTB sob HTB, o HTB externo simula um novo dispositivo de hardware com todas consequências (grande retardo).

O simulador é configurado para gerar 50 kbps para ambas classes executando no tempo 3s o comando:

tc class change dev eth0 parent 1:2 classid 1:10 htb \
 rate 50kbps ceil 100kbps burst 2k prio 0
Como você pode ver o retardo da classe WWW cai para aproximadamente zero enquanto o retardo do SMTP é ampliado. Quando você prioriza para que uma classe tenha um retardo melhor sempre fará outra classe ter um retardo pior.
Depois (tempo 7s) o simulador começa a gerar WWW a 60 kbps e SMTP a 40 kbps. Lá você pode observar o próximo comportamento interessante. Quando uma classe está acima do limite (WWW) HTB prioriza primeiro a que estiver abaixo do limite da largura de banda.

Que classe você deveria priorizar? Geralmente as classes onde você realmente precisa de retardos pequenos. O exemplo pode ser o tráfego de vídeo ou áudio (e você precisará realmente usar a taxa correta aqui para prevenir que estes tráfegos venha matar outros) ou tráfego interativo (telnet, SSH) que são naturalmente de rajadas e não irão afetar negativamente outros fluxos.
Um truque comum é priorizar ICMP para obter excelentes retardos de ping mesmo em links completamente utilizados (porém sob o ponto de vista técnico não é isto o que você quer quando avalia conectividade).

7. Entendendo estatísticas

A ferramenta tc permite você obter estatísticas sobre regras de enfileiramento no Linux. Infelizmente os resultados estatísticos não são explicados pelos autores e frequentemente você não pode utilizá-los. Aqui vou tentar ajudá-lo a compreender estatísticas HTB.
Primeiro a estatística HTB completa. O fragmento abaixo foi obtido durante a simulação no capítulo 3.
# tc -s -d qdisc show dev eth0
 qdisc pfifo 22: limit 5p
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) 

 qdisc pfifo 21: limit 5p
 Sent 2891500 bytes 5783 pkts (dropped 820, overlimits 0) 

 qdisc pfifo 20: limit 5p
 Sent 1760000 bytes 3520 pkts (dropped 3320, overlimits 0) 

 qdisc htb 1: r2q 10 default 1 direct_packets_stat 0
 Sent 4651500 bytes 9303 pkts (dropped 4140, overlimits 34251) 
As três primeiras regras são filhos de HTB. Vamos ignorar as estatísticas PFIFO por serem auto explicativas.
overlimits diz a você quantos vezes a regra atrasou um pacote. direct_packets_stat diz a você quantos pacotes foram enviados por intermédio de fila direta. Outras estatísticas são auto explicativas. Vamos olhar as estatísticas de classe:
tc -s -d class show dev eth0
class htb 1:1 root prio 0 rate 800Kbit ceil 800Kbit burst 2Kb/8 mpu 0b 
    cburst 2Kb/8 mpu 0b quantum 10240 level 3 
 Sent 5914000 bytes 11828 pkts (dropped 0, overlimits 0) 
 rate 70196bps 141pps 
 lended: 6872 borrowed: 0 giants: 0

class htb 1:2 parent 1:1 prio 0 rate 320Kbit ceil 4000Kbit burst 2Kb/8 mpu 0b 
    cburst 2Kb/8 mpu 0b quantum 4096 level 2 
 Sent 5914000 bytes 11828 pkts (dropped 0, overlimits 0) 
 rate 70196bps 141pps 
 lended: 1017 borrowed: 6872 giants: 0

class htb 1:10 parent 1:2 leaf 20: prio 1 rate 224Kbit ceil 800Kbit burst 2Kb/8 mpu 0b 
    cburst 2Kb/8 mpu 0b quantum 2867 level 0 
 Sent 2269000 bytes 4538 pkts (dropped 4400, overlimits 36358) 
 rate 14635bps 29pps 
 lended: 2939 borrowed: 1599 giants: 0
Deletei as classes 1:11 e 1:12 para representar um resultado menor. Como você vê existem os parâmetros que configuramos. Também existem informações de level e quantum DRR.
overlimits mostra quantas vezes a classe solicitou enviar pacote mas ele não pode ser enviado por restrições de taxa/limite superior (rate/ceil) (atualmente computada apenas nas classes folha).
rate, pps mostram a taxa atual (média 10 seg) da classe. Esta é a mesma taxa usada pela passagem.
lended é o número de pacotes doados por esta classe (de sua taxa) e borrowed são pacotes que tomaram emprestado da classe pai. Lends (empréstimos concedidos) são sempre computados classe-local enquanto borrows (empréstimos tomados) são transitivos (quando 1:10 toma emprestado de 1:2 que por seu turno toma emprestado de 1:1 ambos contadores borrow de 1:10 e de 1:2 são incrementados).
giants (gigantes) é o número de pacotes maiores que mtu configurado no comando tc. HTB irá trabalhar com estes pacotes mas as taxas não serão exatas em todos. Adicione mtu em seu tc (padrão em 1600 bytes).

8. Compilando, encontrando bugs e enviando relatórios de erros

Se você tiver o kernel 2.4.20 ou mais recente você não precisa aplicar o patch nele - tudo está no pacote padrão. A única coisa que você precisa é a ferramenta tc. Baixe o pacote HTB 3.6 e utilize o tc nele incluso.

Para trabalhar com kernels mais antigos é necessário aplicar o patch e recompilá-los. Baixe os fontes do kernel e execute patch -p1 -i htb3_2.X.X.diff para aplicar o patch. Então execute make menuconfig;make bzImage como antes. Não esqueça de habilitar QOS e HTB.
Você também tem de utilizar a ferramenta tc com patch. O patch também está em downloads ou você pode baixar o binário precompilado.

Se você julga ter encontrado um erro eu irei avaliar o relatório de erro. Para oopses eu preciso da saída do ksysmoops. Para comportamentos estranhos do qdisc adicione o parâmetro debug 3333333 no seu tc qdisc add .... htb. Ele irá registrar muitos megabytes para o recurso do syslog kern level debug. Voce provavelmente desejará adicionar uma linha como:
kern.debug -/var/log/debug
no seu /etc/syslog.conf. Então compacte o log com o bzip e envie-o para mim por e-mail (até 10MB após o bzip) conjuntamente com a descrição do problema e o momento em que este ocorreu.

Martin Devera aka devik (devik@cdi.cz)
Manual: devik and Don Cohen
Last updated: 5.5.2002
Tradução: Carlos Virgílio Beltrão Lessa (lessacarlos@ig.com.br) em 03/11/2003

Postado por brain em fevereiro 8, 2004 10:08 AM

Comentários para "Manual traduzido do controle de banda com o HTB"

» Postado por: Adriano Frare em fevereiro 25, 2004 12:18 PM, 200.204.123:

 

» Postado por: Adriano Frare em fevereiro 25, 2004 12:18 PM, 200.204.123:

 

» Postado por: Wnehgme em fevereiro 26, 2004 01:54 PM, 200.138.224:

 

» Postado por: romulo em fevereiro 27, 2004 06:03 PM, 200.96.127.:

 

» Postado por: Daniel em março 18, 2004 02:54 PM, 200.162.74.:

 

» Postado por: Helio em março 20, 2004 09:04 AM, 200.210.229:

 

» Postado por: Elisângela em junho 12, 2004 03:34 PM, 200.223.24.:

 

» Postado por: Elisângela em junho 12, 2004 03:34 PM, 200.223.24.:

 

» Postado por: Elisângela em junho 12, 2004 03:34 PM, 200.223.24.:

 

» Postado por: abuse-animal em julho 20, 2004 10:24 AM, 66.98.226.5:

 

» Postado por: Twink em setembro 23, 2004 04:29 PM, 69.193.101.:

 

» Postado por: pamela andersen sex em novembro 2, 2004 06:37 AM, 69.193.88.3:

 

Antes de comentar...

- Preserve a qualidade desta discussão
- Leia os Termos de Uso.
- Este formulário deve ser usado para comentários sobre a notícia. Se você tem dúvidas ou precisa de ajuda, use o Fórum.
- Mantenha o foco nos argumentos e no assunto
- Não faça ataques pessoais.
- Pense 5 vezes antes de entrar em discussões inúteis, como "qual é a melhor distribuição/ambiente gráfico/linguagem de programação/etc.", mesmo se alguém já tiver provocado - um erro não justifica o outro
- Não seja um e-mala ;-)


O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.