Я пытаюсь удаленно устранить очень странную проблему на компьютере у клиента. Это машина Dell PowerEdge 1950. Сетевая карта машины представляет собой двухпортовый встроенный Broadcom NetXtreme II BCM5708 Gigabit Ethernet, использующий драйвер bnx2.
Основной интерфейс eth0 отлично работает, и на самом деле это то, как я нахожусь в ssh'd.
Однако вторичный интерфейс eth1 не передача. Я могу видеть это в выводе ifconfig, например, где поле TX всегда равно 0. Однако является получение, а tcpdump показывает запросы ARP, поступающие от шлюза интернет-провайдера на другой стороне.
Интерфейс физически подключен к модему Siemens BSTU4, настроенному провайдером. Канал правильно настроен на 10 Мбит / с и полнодуплексный режим, без согласования, как запрашивал провайдер. Маленький /30
подсеть настроена. Ради анонимности предположим, что машина 3.3.3.2/30
, и шлюз провайдера .1
. На машине вообще нет настроек брандмауэра.
Даже работает что-то вроде arping -I eth1 3.3.3.1
, и запустив tcpdump рядом, показывает нет любой трафик, передаваемый по интерфейсу. (Но другая сторона постоянно отправляет запросы ARP, и это все, что можно увидеть.)
Что может быть причиной этого?
Вот некоторые анонимные результаты, которые, надеюсь, могут помочь:
$ 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
Первое, что нужно проверить: возможная проблема с оборудованием. Вы используете заведомо исправный кабель? Проверьте это еще раз.
Вы получаете что-нибудь от RG45, когда подключаете его к тестеру LAN? O-scope на выводах TX?
Если есть ошибка HW, вы потратите много времени на поиск проблем конфигурации SW и ничего не найдете.
Поскольку вы отключили автосогласование, и у вас не будет автоматического Авто-MDIX в результате вам может потребоваться использовать перекрестный кабель. Однако я думаю, что в этом случае передача все равно будет увеличиваться.
Вы пробовали "traceroute -i eth1 www.google.com"? Может проблема с маршрутизацией.