Solucionado: NETDEV WATCHDOG

Resumo:
Resolvi o problema do servidor relacionado ao NETDEV WATCHDOG, desmarcando
a opção ENABLE IRQ BALANCING do Kernel SMP.

A algum tempo atrás um problema novo apareceu no servidor. De tempos em tempos a placa de rede começava a apresentar os seguintes erros:

Feb 1 20:34:11 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:26 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:41 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:56 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:11 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:26 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:41 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out

Esses erros não duravam muito tempo, porque muito rapidamente a placa de rede simplesmente parava de responder.

Para ativar a placa novamente, era necessário descarregar e carregar novamente o seu módulo.

Primeiro recompilei o driver da placa de rede alterando o MMIO para PIO.

* Usa as Portas de I/O programadas ao invés da Memória PCI Compartilhada, pode resolver alguns problemas em placas mãe com inconsistência de memória. (Segundo info do kernel)

Por felicidade ou não, o servidor permaneceu dois dias sem apresentar erro, mas no terceiro dia, a mesma história.

Pensei então na opção de RX-Reset (imagem acima), que, segundo info do kernel, contém uma mais rápida sequencia de reset, e se apresentar problema pode ser optado o método antigo.

Recompilado o módulo, modulo descarregado e carregado. Horas depois o mesmo erro, entretanto numa placa de rede diferente, e que utilizava outro driver. Então, pensei, já que o erro mudou de interface, vamos ver as configurações do módulo da maldita placa.

Encontrei então a opção NAPI API, que é um novo driver desenvolvido para reduzir a carga e interrupção do CPU quando recebendo muitos pacotes da placa de rede. Opção recomendada para Carga de RX acima de 10kpps (pacotes por segundo)

Solução também insuficiente, pois a placa apresentava os mesmos erros, agora em interfaces alternadas (o servidor possui 4 placas de rede)

Pesquisando na internet, encontrei o parâmetro pci=noacpi afim de resolver o erro, insiro no append do lilo (append="pci=noacpi") e reinicio o servidor.

Novamente o servidor começa a apresentar erros, começo então a esmiuçar o kernel com a linha de raciocínio que era problemas no barramento PCI ou IRQ, algo do tipo, até que então, encontro na parte "Processor type and features" a opção "Enable kernel irq balancing"

obs. Essa opção só aparece se o servidor estiver sendo compilado para multiprocessadores (SMP)

Desmarco a opção, recompilo o kernel, e reinicio o servidor.

Bom, hoje é dia 9 de fevereiro, desde o último dia 1, o erro não acontece mais.

Pode não estar relacionado, mas após essa alteração até o processamento da máquina diminuiu consideravelmente, agora o servidor fica idle acima de 96%, e antes estava por volta de 84%.

Pesquisando no google, encontrei um tópico em inglês de um usuário que após recompilar o kernel desativando essa opção sentiu uma considerável diferença no seu desktop linux, segundo o mesmo os vídeos que antes travava de tempos em tempos, agora é executado perfeitamente, mesmo ele usando outros aplicativos em background.

Devido ao leitor que solicitou mais detalhes do procedimento adotado, farei aqui resumidademen te.

obs.. Ao estilo Debian(Ubuntu) mas com poucas modificações, funciona em qualquer distribuição.

Preparando os compiladores necessários.

#apt-get install build-essential kernel-package libncurses5-dev

Instalando o kernel (Faça de acordo com seu próprio kernel)

#apt-get install linux-tree-2.6.26-1

Crie o link simbólico para o souce do kernel

# ln -s /usr/src/linux-2.6.26.1 /usr/src/linux

Entre no diretorio do linux

#cd /usr/src/linux

Configure o kernel conforme imagens inseridas nesse artigo, para isso acessamos a configuração via terminal

#make menuconfig

Salve o arquivo de configuração e faça a compilação do kernel conforme:

#make-kpkg --initrd kernel_image

Uma vez compilado, basta instalar o novo kernel

#dpkg -i linux-image-2.6.26.1*

Agora reinicie a máquina para que o novo kernel seja ativado.

Limitando o tráfego P2P com Layer7 e Connlimit

Data de criação: 20/04/2007
Artigo pode sofrer alterações devido novas funcionalidades encontradas.

Trabalho em um provedor de internet, e como todo administrador de redes, controlar efetivamente o tráfego de P2P é um desafio.
Mais do que o tráfego por ele gerado, o número de conexões ativas, assim como o número de pacotes por segundo, pode gerar muitos transtornos devido uma sobrecarga no Access Point.

Pesquisando na internet, encontrei um artigo interessante, sobre o uso de "connlimit no controle de portas¹", mas, em alguns casos não é interessante limitar todas as portas, principalmente se parte de seus clientes são empresas e precisam de acesso full, o que é necessário então é limitar somente o P2P.
A idéia então seria usar um classificador de protocolos, então pensei então em combinar essa idéia com o filtro de protocolo (Layer7)
Existe também o IPP2P, entretanto, como os clientes P2P estão usando técnicas de criptografia, e o IPP2P não é atualizado a quase um ano, prefiro manter no Layer7 que tem atualizações constantes de sua base de protocolos e no core do software.

Referência.
¹- http://under-linux.org/wiki/index.php/Tutoriais/Seguranca/Usando_o_Connlimit

Mãos a obra,
(Levando em consideração que sabe o que faz e tem conhecimento de compilar programas e do próprio kernel)

Requerimentos

Patch Connlimit - ftp://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/patch-o-matic-ng-20070414.tar.bz2
Patch Layer7 - http://ufpr.dl.sourceforge.net/sourceforge/l7-filter/netfilter-layer7-v2.9.tar.gz
Protocolos Layer7 - http://ufpr.dl.sourceforge.net/sourceforge/l7-filter/l7-protocols-2007-01-14.tar.gz
Kernel 2.6.19.7 - http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.19.7.tar.gz
Iptables 1.3.37 - ftp://ftp.netfilter.org/pub/iptables/iptables-1.3.7.tar.bz2

Decompacte o Kernel
#tar xzpvf linux-2.6.19.7.tar.gz

Descompacte o patch do Layer7
#tar xzpvf netfilter-layer7-v2.9.tar.gz

Descompacte o Connlimit
#tar xjpvf patch-o-matic-ng-20070414.tar.bz2

Descompacte o Iptables 1.3.37
#tar xjpvf iptables-1.3.7.tar.bz2

Aplique o patch do Layer7 ao Kernel
#patch -p1 < ../netfilter-layer7-v2.9/kernel-2.6.18-2.6.19-layer7-2.9.patch

Aplique o Patch do Connlimit
#cd patch-o-matic-ng-20070414
#KERNEL_DIR=../linux-2.6.19.7 IPTABLES_DIR=../iptables-1.3.7 ./runme connlimit -download (a opção -download é porque o connlimit não vem no snapshot padrao do patch-o-matic)

Agora que o kernel já está patcheado, vamos ativar os patch's

#cd linux-2.6.19.7
#make menuconfig
Ativar a opção - Connection tracking flow accounting (Requerido pelo Layer7) Networking->network options->network patcket filtering->IP: Netfilter Configuration->Connection tracking->Connection tracking flow accounting

Ativar a opção - Layer 7 match support
Networking->network options->network patcket filtering->IP: Netfilter Configuration->Layer 7 match support

Ativar a opção de Connlimit
networking->network options->network patcket filtering->IP: Netfilter Configuration->Connections/IP limit match support

Agora, configure o kernel a seu gosto, e compile-o.

Em Slackware
#make all
#make install
#lilo

Em Debian
#make-kpkg --initrd kernel_image
#dpkg -i ../linux-image-2.6.19.7_2.6.19.7-10.00.Custom_i386.deb

Agora, ainda falta compilar o iptables com suporte a layer7 e connlimit

Primeiro aplicamos os patch's

#cd iptables-1.3.7

Aplique o patch do filtro Layer7 ao iptables
#patch -p1 < ../netfilter-layer7-v2.9/iptables-layer7-2.9.patch

(O patch-o-matic já aplicou o patch ao iptables, visto que definimos o caminho do source do iptables)

Dê permissões para o iptables compilar suas extensões

#chmod +x extensions/.*

Compile o iptables
#KERNEL_DIR=../linux-2.6.19.7 PREFIX=/usr make

Instale o iptables
#make install

Atualize o cache de bibliotecas
#ldconfig

Reinicie o kernel, para ativar as compilações feitas
# shutdown -r now

Agora, insira em seu arquivo de firewall as seguintes linhas.

Crio uma nova chain na tabela mangle para o limite de conexões (CONNLIMIT)
#iptables -v -t mangle -N CONNLIMIT

Classifico cada protocolo de P2P nessa nova chain
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto edonkey -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto ares -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto gnutella -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto fasttrack -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto imesh -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto directconnect -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto napster -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto soulseek -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto bittorrent -j CONNLIMIT

Aplico o limite de conexões 15 conexões de P2P por IP (O connlimit só é aplicável em pacotes tcp)
#iptables -v -t mangle -A CONNLIMIT -p tcp -m connlimit --connlimit-above 15 --connlimit-mask 32 -j DROP

Como o connlimit só limita as conexões TCP, as regras acima só se aplicam a esse protocolo, se desejar fazer o controle também de UDP terá q ser feito com cbq,htb,hfsq + layer7 ou então dropando qualquer pacote p2p em UDP, conforma abaixo.

#iptables -v -t mangle -A PREROUTING -p UDP -m layer7 --l7proto edonkey -j DROP

Se você deseja um filtro ainda mais competente e ache que o controle de portas pode ser combinado sem complicações, sugiro as seguintes regras.

#iptables -v -t mangle -N CONNLIMIT
#iptables -v -A FORWARD -p TCP -d 0/0 --dport 4300:4672 -j CONNLIMIT
#iptables -v -A FORWARD -p TCP -d 0/0 --sport 4660:4672 -j CONNLIMIT
#iptables -v -A FORWARD -p TCP -d 0/0 --dport 6881:65000 -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto edonkey -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto ares -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto gnutella -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto bittorrent -j CONNLIMIT
#iptables -v -t mangle -A PREROUTING -m layer7 --l7proto fasttrack -j CONNLIMIT
#iptables -v -t mangle -A CONNLIMIT -p tcp -m connlimit --connlimit-above 15 --connlimit-mask 32 -j DROP

Então o iptables aplica o connlimit nas portas conhecidas do emule (source e destination), e nas portas altas de destino, e qualquer P2P que esteja fora desse range de portas, se identificado com o layer7 também entra no connlimit.
Ultimamente nos servidores que possuem controle de banda essas regras estão ativas no controle de p2p em meus servidores, as regras anteriores só com layer7 só as aplico em servidores onde não posso fazer o limite de portas (roteadores por exemplo).

Esteja ciente que alguns protocolos do layer7 são lentos, portanto se o tempo de resposta de sua rede subir, ou apresentar perda de pacotes, tente evitar protocolos lentos como o bittorrent, prefira manter os mais ativos e mais rapidos, como emule e ares.

Espero que seja de alguma ajuda, abraços.
Wagner Assis