Placa ativa parando de processar

clicsis
(usa Debian)

Enviado em 28/08/2008 - 07:44h

Bom dia.
Estou com um problema intrigante ocorrendo e já tentei várias soluções sem excito, gostaria de contar com os amigos para vermos se conseguimos desvendar esse segredo:

O problema é:
Tenha 2 placas de rede, ETH0(link) ETH1(cliente), o processamento das duas placas ficam normais por 2 dias as vezes por 3 dias, varia, mas de uma hora pra outra a eth1 responsável por manter os clientes funcionando simplesmente para de processar, embora continue ativa, por exemplo, quando utilizo o comando mii-tool para listar o status, surge o seguinte:
--------------------
eth0: negotiated 100baseTx-FD flow-control, link ok
eth1: negotiated 100baseTx-FD flow-control, link ok
--------------------

Os testes que já fiz sem obter excito:
- Substitui as 2 placas de rede
- Refiz a instalação do Debian
- Alterei as linhas do squid para:
--------------------
cache_dir aufs /home/squidcache 10000 24 256
cache_access_log /var/log/squid/access.log
cache_log /var/log/squid/cache.log
--------------------
- Verifiquei o LOG e nada é mostrado com o comando:
--------------------
grep -i "WARNING:" /var/log/debug
--------------------

Atualmente substitui o micro por um outro totalmente NOVO e com 2 placas 100/1000, fiz a instalação do Debian e dos serviços, iniciando do zero mas o problema persiste.

O que pode está causando essa parada no processamento da placa ETH1?

Desde já, novamente agradeço o apoio dos amigos.

fhferreira
(usa Slackware)

Enviado em 28/08/2008 - 09:11h

Olá,

Você praticamente já esgotou as possibilidades no servidor. Agora tem que continuar a análise para o switch? Essa eth1 vai ligada direto no mesmo switch que os clientes estão ou tem algum cascateamento? Outra possibilidade pode ser conflito de ip? Ou ainda alguma placa de cliente que esteja com defeito físico e esteja inundando a rede com brodcast arp. Já vim isso acontecer com redes estruturadas porque a solicitção em brodcast arp passa normalmente.

Ve se levanta isso aí para nós, por favor, para continuar a análise.

Abraços.

clicsis
(usa Debian)

Enviado em 28/08/2008 - 11:26h

Obrigado: Qual a melhor forma de analisar se haveriam solicitações de broadcast excedentes, repetitivas e/ou problemáticas? Onde ficariam LOGados essas informações.

Outra questão acho que melhor seria: Como saber qual clientes em específico está com solicitações fora do normal?

clicsis
(usa Debian)

Enviado em 28/08/2008 - 11:29h

Há, esqueci de mencionar que também já fiz o teste de substituição do Swhitch, mas também não obtive excito. Vou direcionar agora a questão quanto a uma possível solicitação em EXCESSO ou ERRADA na rede.

Estou aceitando idéias de como melhor analisar essa hipótese.

clicsis
(usa Debian)

Enviado em 14/09/2008 - 09:27h

O erro que está derrubando a ETH1 é:
kernel: NETDEV WATCHDOG: eth1: transmit timed out

Não consegui ainda resolver esse problema ou ao menos identificar o causador do mesmo.

freitasrdf
(usa Ubuntu)

Enviado em 14/09/2008 - 20:59h

já tentou alterar a velocidade das placas, eu tenho uns micros HP que tem uma falha, eles vieram com placas 10/100/1000, o auto-sense sempre tenta otimizar a velocidade da placa causando ás vezes travamento, resolvi colocando a velocidade em 100 default, ela parou de travar, só não lembro agora o fabricante das placas, mas são do micro HP

clicsis
(usa Debian)

Enviado em 15/09/2008 - 09:35h

Obrigado: Qual o arquivo "default" para a configuração da placa de rede no Debian, onde eu especificaria essa velocidade?

freitasrdf
(usa Ubuntu)

Enviado em 18/09/2008 - 14:33h

No gentoo eu faço com o "mii-tool", mas há também o "ethtool"

Como você pode ver, o mii-tool vai mais direto ao ponto, fornecendo a informação em uma única linha, enquanto o ethtool é mais falador.

O "100BaseTx-FD" na saída do mii-tool indica que a placa está operando em modo full-duplex. Caso a placa estivesse trabalhando em modo half-duplex, ela apareceria como "100BaseTx-HD". Note que o "FD" e "HD" são justamente abreviações de full-duplex e half-duplex. Caso você estivesse usando placas antigas (de 10 megabits), seriam usados, respectivamente, os modos "10BaseT-FD" e "10BaseT-HD". Existe ainda um último modo possível, o "100BaseT4", que indica que a placa está utilizando o padrão para cabos cat 3, onde são utilizados os 4 fios do cabo.

No caso do ethtool, a velocidade é indicada na linha "Speed", que pode conter os valores "10", "100", "1000" ou "10000" e o uso do half-duplex ou full-duplex na linha "Duplex", que pode conter os valores "Half" ou "Full".

Como disse, o modo de operação é definido automaticamente, depois de um rápido processo de negociação entre a placa e o hub ou switch. É possível também usar o mii-tool e o ethtool para forçar um determinado modo de operação.

No caso do mii-tool, use o parâmetro "-F", seguido do padrão desejado, como em:

Listando as interfaces
# mii-tool
eth0: negotiated 1000BaseTx-FD, link ok


# mii-tool -F 100BaseTx-FD eth0
ou:
# mii-tool -F 100BaseTx-HD eth0

Voce pode usar também o ethtool

Listando interfaces
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

maos a obra ethtool

# ethtool -s eth0 speed 100 duplex full autoneg off
ou:
# ethtool -s eth0 speed 10 duplex half autoneg off

Note que forçar o modo full-duplex em uma rede onde o hub ou os cabos não suportem este modo de operação, fará com que pacotes passem a ser perdidos, deixando a rede lenta ou mesmo derrubando a conexão do seu micro. Estas opções são destinadas a casos onde a autonegociação falhe, ou onde você queira deliberadamente reduzir a velocidade de operação da rede.