Непонятная проблема с сеткой

посмотреть соответствие скорости/дуплекса на карте и на порту свитча, посмотреть счетчики ошибок на порту свитча

проблема в свитчах 90%

> посмотреть соответствие скорости/дуплекса на карте и на порту свитча, > посмотреть счетчики ошибок на порту свитча
switch неуправляемый, поэтому autodetect

Вероятность возникновения ошибок напрямую зависит от нагрузки.
То есть, в выходные, в обед и вечером/ночью потерь не наблюдается.

Более того, при примерно равной нагрузке в течение недели,
потери наблюдаются не каждый день.

тогда что ты от нас хочешь? :)

поставь нормальное сетевое железо, это же очевидно.

> проблема в свитчах 90%
тоже так думаю, но 'терзают смутные сомнения' (c) :)

Switch: D-Link DGS-1024D

И мой компьютер и сервер включены в один switch.

> поставь нормальное сетевое железо, это же очевидно.
Соответствующие службы занимаются этим вопросом,
но очень медленно. :(

Понятно, спасибо за ответы.

=)

а у твоего компа с этим сервером тоже такие проблемы ?

> а у твоего компа с этим сервером тоже такие проблемы ?
Ну да.
Какая-то странная ситуация. Уже пускал ping'и вдоль
и поперёк - несимметричные потери.
Я же говорю: с моего компа на сервер - ping с потерями,
одновременно с сервера на мой комп - ping без потерь.
'Парадокс!' (c)

Попробуй netstat -s у себя и на сервере.

> Попробуй netstat -s у себя и на сервере
Может что-то упустил? Вот вывод с сервера:

ArchY[~]$ netstat -s
Ip:
    350997669 total packets received
    0 forwarded
    0 incoming packets discarded
    343772836 incoming packets delivered
    464639152 requests sent out
    1 fragments dropped after timeout
    1343 reassemblies required
    61 packets reassembled ok
    1 packet reassembles failed
    1342 fragments created
Icmp:
    846670 ICMP messages received
    239 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 3479
        timeout in transit: 2891
        source quenches: 235
        redirects: 625312
        echo requests: 198009
        echo replies: 16544
    205632 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 7623
        echo replies: 198009
Tcp:
    691914 active connections openings
    1209203 passive connection openings
    2 failed connection attempts
    13885 connection resets received
    16 connections established
    334407442 segments received
    464310130 segments send out
    331393 segments retransmited
    420 bad segments received.
    113241 resets sent
Udp:
    105047 packets received
    6087 packets to unknown port received.
    0 packet receive errors
    105215 packets sent
TcpExt:
    163 resets received for embryonic SYN_RECV sockets
    18372 packets pruned from receive queue because of socket buffer overrun
    596 ICMP packets dropped because they were out-of-window
    ArpFilter: 0
    1110787 TCP sockets finished time wait in fast timer
    18863000 delayed acks sent
    4549 delayed acks further delayed because of locked socket
    Quick ack mode was activated 261315 times
    18633598 packets directly queued to recvmsg prequeue.
    78924254 packets directly received from backlog
    2408876543 packets directly received from prequeue
    71349313 packets header predicted
    17272599 packets header predicted and directly queued to user
    TCPPureAcks: 36787483
    TCPHPAcks: 128752872
    TCPRenoRecovery: 1868
    TCPSackRecovery: 47429
    TCPSACKReneging: 0
    TCPFACKReorder: 59
    TCPSACKReorder: 13
    TCPRenoReorder: 2
    TCPTSReorder: 360
    TCPFullUndo: 99
    TCPPartialUndo: 1127
    TCPDSACKUndo: 41
    TCPLossUndo: 84
    TCPLoss: 30352
    TCPLostRetransmit: 5
    TCPRenoFailures: 6244
    TCPSackFailures: 45981
    TCPLossFailures: 3589
    TCPFastRetrans: 52235
    TCPForwardRetrans: 4890
    TCPSlowStartRetrans: 23230
    TCPTimeouts: 163083
    TCPRenoRecoveryFail: 74
    TCPSackRecoveryFail: 3081
    TCPSchedulerFailed: 52
    TCPRcvCollapsed: 810575
    TCPDSACKOldSent: 404087
    TCPDSACKOfoSent: 99891
    TCPDSACKRecv: 441
    TCPDSACKOfoRecv: 0
    TCPAbortOnSyn: 3
    TCPAbortOnData: 381
    TCPAbortOnClose: 18
    TCPAbortOnMemory: 0
    TCPAbortOnTimeout: 1095
    TCPAbortOnLinger: 0
    TCPAbortFailed: 0
    TCPMemoryPressures: 0

Поскольку потери наблюдаются только в одну сторону, возможен случай с конфликтом IP-адресов. Проверь на всякий случай, какой MAC-адрес для IP-шника сервера фигурирует в таблице ARP на твоей машине при нормальной работе и в момент пропадания пингов.

Еще, как вариант - проверить сеть на наличие петель.

> Поскольку потери наблюдаются только в одну сторону, возможен случай
> конфликтом IP-адресов. Проверь на всякий случай, какой MAC-адрес для
> IP-шника сервера фигурирует в таблице ARP на твоей машине при
> нормальной работе и в момент пропадания пингов.
Проверил - конфликта адресов нет.
MAC всё время один и тот же.

> Еще, как вариант - проверить сеть на наличие петель.
Да, с нашими "сетевиками" это вариант :)
Раньше уже находили петли.

Спасибо, будем искать.
(странно, что проблема с одним сервером, но у него, правда,
приличная нагрузка по сети, 100-150 пользователей по SSH)

вообше-то как показывает практика такие вот потери в одну сторону почти наверняка говорят о duplex mismatch , грубо говоря на сетевухе autonegotiation установило 100FD , а на порту свитча - 100HD. кстати, mii-tool -v на сервере что говорит. и вообще- поменяй свитч на управляемый, хотя бы на время - сразу станет ясно где собака порылась.

lspci, ethtool, netstat -rn

>Может что-то упустил? Вот вывод с сервера:

>ICMP input histogram: >... >timeout in transit: 2891 >source quenches: 235 >redirects: 625312 >...

Очень интересные строчки.

> mii-tool -v на сервере что говорит
mii-tool -v eth0 говорит:
SIOCGMIIPHY on 'eth0' failed: Operation not supported
no MII interfaces found

ethtool eth0 говорит:
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
        Link detected: yes

Проблема "плавающая": иногда потерь много, иногда мало,
иногда - вообще нет.

ага, так там еще и гигабит... тогда даже немного "корявый" патчкорд/линия на пути от свитча до сервера может давать подобную муть при возрастании траффика. в-общем, еще раз повторю - без умного свитча не обойтись, если хотите радикально решить проблему. часто бывает, что на стороне хоста ошибки по нулям, а глянешь на порт - и видишь, что все вовсе не так пушисто. да и тип ошибок (сrc/frame/etc...) может о многом сказать.

> ага, так там еще и гигабит... тогда даже немного "корявый"
> патчкорд/линия на пути от свитча до сервера может давать подобную
> муть при возрастании траффика
О, точно! Про это как-то не подумал.
Сейчас брошу прямой кабель, минуя патч-панели.

Спасибо за помощь! :-)

Довольно интересно получается: один и тот же путь то прямой, то кривой.

>часто бывает, что на стороне хоста ошибки по нулям

У него как раз не по нулям.

я вижу - высказывание было чисто теоретическим. а что до "один путь и прямой и кривой" - да, и такое бывает, и я сие неоднократно видел. да и потом, если уж точно говорить, это не один путь ;)

Switch: D-Link DGS-1024D

И мой компьютер и сервер включены в один switch.

lonki-lomki (*) (21.08.2007 17:24:19)

>да и потом, если уж точно говорить, это не один путь ;)

Не просветишь коротко. Кстати у этого свитча вот такая штука заявлена: Функции->Функция диагностики кабеля.

>я вижу - высказывание было чисто теоретическим.

Какое именно?

коротко могу ;) классический full duplex предполагает прием и передачу данных по физически разным каналам типа "точка-точка". про свитч - не видел я таких, да и потом есть кабельные тестеры/сканеры - ну и что ? чисто теоретическим было высказывание о возмоожности ситуации, когда счетчик ошибок будет нулевым на одной стороне (причем и RX errors, и TX errors) и ненулевым на другой.

Вероятность возникновения ошибок напрямую зависит от нагрузки. То есть, в выходные, в обед и вечером/ночью потерь не наблюдается.

Более того, при примерно равной нагрузке в течение недели, потери наблюдаются не каждый день.

lonki-lomki (*) (21.08.2007 17:15:55)

ethtool eth0 говорит: Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: umbg Wake-on: g Current message level: 0x00000007 (7) Link detected: yes

Проблема "плавающая": иногда потерь много, иногда мало, иногда - вообще нет.

lonki-lomki (*) (22.08.2007 13:07:15)

------------------------------------------------------------

Он несколько раз повторяет, что появление этой ситуации зависит от нагрузки. Вывод ethtool смущает? Меня нет. Жалко он не показал вывода команд со своей стороны.

>счетчик ошибок будет нулевым на одной стороне (причем и RX errors, и TX errors) и ненулевым на другой.

Он может быть не единственным клиентом у сервера.

под "одной стороной" я подразумеваю собственно сетевуху в сервере, а под другой - порт в свитче - неужто не ясно. сколько там клиентов - вопрос пятый. вывод ethtool мнея смущает - с чего это ты взял ??? и вообще, давай наверное завязывать с дискуссией - а то мы в такие дебри залезем ;) подождем лучше что автор про свой эксперимент с прямым линком на свитч напишет.

> подождем лучше что автор про свой эксперимент с прямым линком
> на свитч напишет
Рассказываю:
бросил прямой кабель между сервером и switch'ем - без
изменений, та же несимметричная потеря пакетов.

Далее: тем же кабелем переключили сервер на управляемый switch
(HP Procurve 2626).
Проверили линк: с обеих сторон 100FD.
2 часа работало без потерь, потом опять появились
потери. Но теперь уже симметричные (мой комп остался
на старом switch'е).

Ошибок по "физике" на switch'е нет.

Сними статистику на сервере и у себя ( netstat -s секция icmp ).

С сервера сделай ping на себя, на сервере сними статистику.

Потом со своего компьютера ping на сервер, сними статистику на своем компьютере.

Хотелось бы посмотреть, что получится.

Неплохо было бы увидеть ifconfig, netstat -rn, lspci, ethtool сервера и твоего компьютера.

Сервер:
ifconfig:
eth0      Link encap:Ethernet  HWaddr 00:30:48:71:2D:D9  
          inet addr:10.30.10.7  Bcast:10.30.10.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:227731251 errors:0 dropped:0 overruns:0 frame:0
          TX packets:207133186 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2599861854 (2479.4 Mb)  TX bytes:3745318158 (3571.8 Mb)
          Base address:0xd800 Memory:fd8e0000-fd900000

netstat -rn:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.30.10.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         10.30.10.1      0.0.0.0         UG        0 0          0 eth0

lspci:
03:02.0 Ethernet controller: Intel Corp.: Unknown device 1013
        Subsystem: Intel Corp.: Unknown device 1213
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 29
        Memory at fd8e0000 (32-bit, non-prefetchable) [size=128K]
        I/O ports at d800 [size=64]
        Capabilities: [dc] Power Management version 2
        Capabilities: [e4] PCI-X non-bridge device.

ethtool:
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
        Link detected: yes

Мой компьютер:
ifconfig:
eth0      Link encap:Ethernet  HWaddr 00:50:8D:51:33:F8  
          inet addr:10.30.3.123  Bcast:10.30.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:701396 errors:0 dropped:0 overruns:0 frame:0
          TX packets:473517 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:140796786 (134.2 Mb)  TX bytes:97767072 (93.2 Mb)
          Interrupt:10 Base address:0xe000

netstat -rn:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.30.10.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         10.30.10.1      0.0.0.0         UG        0 0          0 eth0

lspci:
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet Controller (rev a1)
        Subsystem: ABIT Computer Corp.: Unknown device 1c02
        Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 10
        Memory at ea001000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at d400 [size=8]
        Capabilities: [44] Power Management version 2

ethtool:
Settings for eth0:
        Supported ports: [ 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: 1
        Transceiver: external
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Потерь сейчас нет, так что статистику брошу завтра.

Хорошо. Я на сегодня тоже всё.

Ситуация более-менее прояснилась.
Сегодня весь день наблюдал анализатором
трафика (ethereal) со своей машины, что же твориться
в сети.

Обнаружилось интересное явление:
когда потерь нет, я вижу только broadcast трафик.
Во время потерь, я вижу, что на порт приходят tcp(ssh)
пакеты с IP-сервера на IP-клиента (не broadcast и не
мой IP).

Возможно, в какой-то момент времени (зависит от нагрузки)
у switch'а нарушается таблица MAC-адресов, и, соответственно,
пакеты уходят в неизвестном направлении.

Немного смущает, что потери заметны только на одном сервере,
но это можно объяснить теорией вероятности: 150 клиентов SSH
генерируют такой поток пакетов, что вероятность пропадания
именно этих пакетов выше.

В общем, будем разбираться с сеткой.

Спасибо всем, кто не остался равнодушен к моей проблеме! :-)

Сделай пинг с опцией R со своего компьютера на сервер и наоборот, т.е. ping -R <host>

На 100% не уверен, но думаю проблема у тебя не с сеткой.

Там где ты показывал netstat -s в секции icmp, есть вот такое:

source quenches: 235

Source quenches -> A receiving host generates a source-quench message when it cannot process datagrams at the speed requested due to a lack of memory or internal resources. This message serves as a simple flow control mechanism that a receiving host can use to alert a sender to slow down its data transmission.

Вот это еще интересней:

redirects: 625312

Redirects -> Only gateways generate redirect messages to inform source hosts of misguided datagrams. A gateway receiving a misdirected frame does not trash the offending datagram if it can forward it.

боюсь, что и с сеткой тоже. у него явно свитч начинает работать как хаб, слать пакеты на все порты, а не только на целевой - иначе бы ssh-пакеты от сервера к другому клиенту он бы не увидел... что это - просто переполнение cam-таблицы или какая-то спланированная атака на сеть - сложно сказать.

С моего компа:
$ ping -R 10.30.10.7
PING 10.30.10.7 (10.30.10.7): 56 data bytes
checksum mismatch from 10.30.10.7
24 bytes from 10.30.10.7: icmp_seq=0 ttl=64 time=0.464 ms
RR:     10.30.10.123
        10.30.10.7
        10.30.10.7
        10.30.10.123
checksum mismatch from 10.30.10.7
24 bytes from 10.30.10.7: icmp_seq=1 ttl=64 time=0.240 ms        (same route)
checksum mismatch from 10.30.10.7
24 bytes from 10.30.10.7: icmp_seq=2 ttl=64 time=0.273 ms        (same route)
--- 10.30.10.7 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.240/0.326/0.464/0.099 ms

С сервера:
$ ping -R 10.30.10.123
PING 10.30.10.123 (10.30.10.123): 56 data bytes
checksum mismatch from 10.30.10.123
24 bytes from 10.30.10.123: icmp_seq=0 ttl=64 time=0.271 ms
RR:     ArchY (10.30.10.7)
        10.30.10.123
        10.30.10.123
        ArchY (10.30.10.7)
checksum mismatch from 10.30.10.123
24 bytes from 10.30.10.123: icmp_seq=1 ttl=64 time=0.266 ms      (same route)
checksum mismatch from 10.30.10.123
24 bytes from 10.30.10.123: icmp_seq=2 ttl=64 time=0.249 ms      (same route)
--- 10.30.10.123 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.249/0.262/0.271/0.009 ms

> что это - просто переполнение cam-таблицы или какая-то
> спланированная атака
Думаю, переполнение.
Я же говорил: в локальную сеть объединены три здания
с доброй сотней компьютеров в каждом.
Соответственно, в сети гуляет море ARP-пакетов, много
broadcast-пакетов Name Query от виндовых машин и т.п.

а что это за checksum mismatch from ??? не нравицца...

сеть сегментирована ?

> сеть сегментирована ?
Ethernet сегмент один, роутерами не поделён.
Соответственно, broadcast'ы гуляют по всем трём
зданиям.

> а что это за checksum mismatch from ??? не нравицца...
man ping вот что говорит:

BUG

The maximum IP header length is too small for options like
RECORD_ROUTE to be completely useful. There's not much that
that can be done about this, however.

ОДИН сегмент ? и три сотни станций ?? даже если это и не относится к проблеме непосредственно - срочно лечить._

> срочно лечить
От меня это мало зависит.
Буду поднимать вопрос перед руководством.

+1

виланы, или разнести сегменты физически по разным интерфейсам: воткнуть три сетевухи в роутер, чтобы каждый смотрел в свою внутреннюю сеть.