Estou tentando corrigir um problema muito estranho remotamente em uma máquina no site do cliente. A máquina é um Dell PowerEdge 1950. A NIC da máquina é uma Ethernet Gigabit Broadcom NetXtreme II BCM5708 de porta dupla, usando o driver bnx2.
A interface primária eth0 funciona perfeitamente , e é de fato como eu sou ssh'd em.
No entanto, a interface secundária eth1 não está transmitindo . Eu posso ver isso na saída ifconfig, por exemplo, onde o campo TX é sempre 0. No entanto, está recebendo, e tcpdump mostra solicitações ARP vindas do gateway do ISP do outro lado.
A interface está fisicamente conectada a um modem Siemens BSTU4, configurado pelo ISP. O link está configurado corretamente para 10MBps e full duplex, sem negociação, como o ISP solicitou. Uma pequena sub-rede /30 está configurada. Por causa do anonimato, digamos que a máquina seja 3.3.3.2/30 e o gateway do ISP .1 . A máquina não tem configurações de firewall.
Mesmo rodando algo como arping -I eth1 3.3.3.1 , e rodando o tcpdump ao lado, mostra nenhum tráfego sendo transmitido na interface. (Mas o outro lado continua enviando pedidos de ARP, e isso é tudo o que pode ser visto.)
O que poderia estar causando isso?
Veja alguns resultados, anonimizados, que podem ajudar:
$ ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: d
Wake-on: d
Link detected: yes
$ ip link show eth1
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:15:c5:xx:xx:xx brd ff:ff:ff:ff:ff:ff
$ ip -4 addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 3.3.3.2/30 brd 3.3.3.3 scope global eth1
$ ip -4 route show match 3.3.3.0/30
3.3.3.0/30 dev eth1 proto kernel scope link src 3.3.3.2
default via 10.0.0.5 dev eth0
A primeira coisa a verificar: Possível problema de hardware. Você está usando um bom cabo conhecido? Verifique isso novamente.
Você tira alguma coisa do RG45 ao conectá-lo a um testador de LAN? O-scope nos cabos TX?
Se houver uma falha de HW, você passará muito tempo procurando por problemas de configuração do SW e não encontrando nada.
Como você desativou a negociação automática e não teria como auto Auto-MDIX como resultado, talvez seja necessário para usar um cabo cruzado como resultado. No entanto, eu pensaria que a transmissão ainda iria subir neste caso.
Você tentou um "traceroute -i eth1 www.google.com"? Talvez haja um problema de roteamento.
Tags networking fedora linux