none
Пропадают пинги на все внешние адреса, на внутреннх адресах всё работает RRS feed

  • Вопрос

  • Доброе время суток.

    Ситуация такая:

    Одноранговая сеть с 80 тонкими клиентами, 2 терминальных сервера Windows 2003

    R2 x32 и Windows 2008 x64. Три линукс сервера FreeBSD (Gateway), CentOS

    (DNS/Mail Server), Debian (DNS2).

    Две подсети. Одна для тонких клиентов (192.168.12.0) без интернета и одна для

    "толстых" (192.168.1.0) с интернетом.

    Вот конфигурация типичного тонкого клиента:

    IP 192.168.12.34

    Mask 255.255.255.0

    Gateway

    DNS



    Вот конфиггуация типичного компьютера, подключённого к интернету:

    IP 192.168.1.34

    Mask 255.255.255.0

    Gateway 192.168.1.1

    DNS 192.168.1.15



    В каждом терминальном сервере стоит по 2 сетевых карты, одна подключена к

    свичам с тонкими клиентами, другая к свичам с интернетом. DHCP на установлен

    на одном из терминальных серверов с Windows 2003 R2 x32 на борту.

    Соответственно, конфигурация на обоих серверах примерно следующая:

    Adapter 1
    IP 192.168.1.2

    Mask 255.255.255.0

    Gateway 192.168.1.1

    DNS 192.168.1.15



    Adapter2

    IP 192.168.12.2

    Mask 255.255.255.0

    Gateway

    DNS



    Свичи SG 200-50 50-Port Gigabit Smart Switch - 3шт, один на первой подсети,

    два на второй.

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

    Вообщем, ситуация такая... На втором терминальном сервере с Windows 2008 x64

    периодически отваливается интернет. При этом никакого нового ПО и железа не

    устанавливалось. Антивирусника два - микрософтовскй и Malwarebytes

    Anti-Malware. Выглядит всё это так:

    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Превышен интервал ожидания для запроса.
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48
    Ответ от 8.8.8.8: число байт=32 время=16мс TTL=48



    Через какое-то время (от 3 секунд до часа+) интернет тоже внезапно

    появляется. При этом никаких разрывов связи в обоих локальных подсетях не

    наблюдается, никого не дисконнектит. На локальные айпи пинг идёт стабильно.

    На других компьютерах и серверах, подключённых к интернету такой проблемы не

    наблюдается.



    На этом проблемном сервере две встроенные в материнскую плату сетевые карты

    Intel(R) 82575EB Gigabit Network Connection

    (PCI\VEN_8086&DEV_10A7&SUBSYS_34DC8086&REV_02)

    Имеется одно неизвестне устройство, определяющееся как Ethernet-контроллер.

    Пытался понять что это и откуда. Никаких 3COM сетвых карт в сервере нет. Вот

    его айди:

    PCI\VEN_10B7&DEV_9200&SUBSYS_100010B7&REV_78
    PCI\VEN_10B7&DEV_9200&SUBSYS_100010B7
    PCI\VEN_10B7&DEV_9200&CC_020000
    PCI\VEN_10B7&DEV_9200&CC_0200

    Драйверов для этого устройства для x64 систем не существует в природе.

    Материнская плата 2012 года разлива с двумя ксеонами на сокете 2011.



    Патч корды менялись, перетыкал в другой порт коммутатора, делал netsh

    interface tcpv4 reset, менял драйвера на сетевую карту... Попытки реанимации

    результатов не дали. Помогите!
    27 августа 2013 г. 11:01

Ответы

  • Мы же все уже проверили. Проблема у вас в проходном оборудовании. Возможно, в том, в которое включен шлюз для выхода в Интернет. Надо смотреть уже на оборудовании, а это за рамками форума, как мне кажется.
    Проблема была в вирусе на компе 192.168.1.40, который слал пакеты на все компы в первой подсети. Проблема решилась удалением вируса... Но блин интересно, каким образом он фактически лишал доступа к интернету все компы на ОС выше WinXP. При этом WinXP и 2003 работали.... 
    7 сентября 2013 г. 4:59

Все ответы

  • если у вас пинги в локальной сети ходят нормально, то какой смысл трогать серверы? очевидно, что проблема в гетвеях. Посмотрите в момент возникновения сбоя до какого адреса идет пинг. Например, tracert. И найдете свой сбойный узел. Я почти уверен, что проблема эта с FreeBSD. Не надо было ее линуксом называть ;)
    27 августа 2013 г. 11:34
  • Если б проблема была б с гейтом,  то подобное бы присходило и с другими компьютерами в сети... 
    27 августа 2013 г. 11:43
  • смотрите. У вас есть локальная сеть. И внешняя сеть. При сбое работоспособность в локальной сети сохраняется. Где собака порылась, если в локальной сети связь сохраняется? Поэтому самое простое, что вы можете сделать - это tracert на 8.8.8.8 и посмотреть где затык. Опыт подсказывает, что иногда такие простые действия приводят к весьма неожиданным открытиям.

    Ведь отсутствие ответа на PING вполне может указывать не на то, что пакеты не могут уйти, а на то, что они не могут вернуться. Подозреваю, что у вас вполне может дурить NAT и выключение автотюнинга сети в 2008 поможет. Но это пораженческий путь решения.

    • Изменено Sudden Death 27 августа 2013 г. 12:05
    27 августа 2013 г. 12:03
  • если у вас пинги в локальной сети ходят нормально, то какой смысл трогать серверы? очевидно, что проблема в гетвеях. Посмотрите в момент возникновения сбоя до какого адреса идет пинг. Например, tracert. И найдете свой сбойный узел. Я почти уверен, что проблема эта с FreeBSD. Не надо было ее линуксом называть ;)

    о!

    Вот что я заскринил - tracert после пропадания пинга и tracert после восстановлеия пинга

    C:\Users\Admin>tracert 8.8.8.8

    Трассировка маршрута к google-public-dns-a.google.com [8.8.8.8]
    с максимальным числом прыжков 30:

    1 * * * Превышен интервал ожидания для запроса.
    2 * * * Превышен интервал ожидания для запроса.
    3 * * * Превышен интервал ожидания для запроса.
    4 * * * Превышен интервал ожидания для запроса.
    5 * * * Превышен интервал ожидания для запроса.
    ^C
    C:\Users\Admin>tracert 8.8.8.8

    Трассировка маршрута к google-public-dns-a.google.com [8.8.8.8]
    с максимальным числом прыжков 30:

    1 <1 мс <1 мс <1 мс 192.168.1.1
    2 <1 мс 1 ms <1 мс butyrval52-me1-vl112.corbina.net [89.179.165.241
    ]
    3 <1 мс <1 мс <1 мс nvsl-bb-vlan95.msk.corbina.net [85.21.226.190]
    4 2 ms 3 ms 3 ms ko-crs-be12.corbina.net [195.14.54.226]

    ^C

    27 августа 2013 г. 12:08
  • смотрите. У вас есть локальная сеть. И внешняя сеть. При сбое работоспособность в локальной сети сохраняется. Где собака порылась, если в локальной сети связь сохраняется? Поэтому самое простое, что вы можете сделать - это tracert на 8.8.8.8 и посмотреть где затык. Опыт подсказывает, что иногда такие простые действия приводят к весьма неожиданным открытиям.

    Ведь отсутствие ответа на PING вполне может указывать не на то, что пакеты не могут уйти, а на то, что они не могут вернуться. Подозреваю, что у вас вполне может дурить NAT и выключение автотюнинга сети в 2008 поможет. Но это пораженческий путь решения.

    Выключение атотюнинга - это как понять?
    Дело в том, что если в момент пропадания пинга с любого компа, находящгося в подсети 192.168.1.0 пинговать сервер 192.168.1.2, то пинг будет. Есть компьютеры, которые тоже сидят в  первой подсетке и подключаются к этому серверу, и их не дисконектит...
    27 августа 2013 г. 12:13
  • Было такое ни раз на старых IBM серверах в режиме работы 1 г/бит FullDuplex. И на самозборе Асувском тоже наблюдалось, при добавлении сетевой карточки начинала глючить интегрированная. 

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

    27 августа 2013 г. 12:25
  • Ну поздравляю. Вы нашли свой больной зуб. Это 192.168.1.1

    включайте на нем tcpdump, натравливайте его на ICMP пакеты и будет вам счастье ;)

    27 августа 2013 г. 12:29
  • Было такое ни раз на старых IBM серверах в режиме работы 1 г/бит FullDuplex. И на самозборе Асувском тоже наблюдалось, при добавлении сетевой карточки начинала глючить интегрированная. 

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

    Да, кстати. Я купил ещё 2 карточки - двухпортовую интеловскую и одну реалтековскую. Эксперименты с ними привели к тем-же граблям - пинги в какой-то момент терялись напрочь... Поэтому я их вытащил и оставил старые.

    Кстати, вот ещё route print

    C:\Users\Admin>route print
    ===========================================================================
    Список интерфейсов
    15 ...00 1e 67 33 78 1b ...... Intel(R) 82575EB Gigabit Network Connection #2
    14 ...00 1e 67 33 78 1a ...... Intel(R) 82575EB Gigabit Network Connection
    1 ........................... Software Loopback Interface 1
    22 ...00 00 00 00 00 00 00 e0 10 ...02 00 54 55 4e 01 ...... Teredo Tunneling
    Pseudo-Interface
    17 ...00 00 00 00 00 00 00 e0 isatap.{D212EAFE-87DA-4034-AF51-29FE16E80397}
    ===========================================================================

    IPv4 таблица маршрута
    ===========================================================================
    Активные маршруты:
    Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
      0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.2 266
    127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
    127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
    127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
      169.254.0.0 255.255.0.0 On-link 192.168.12.2 30
      169.254.255.255 255.255.255.255 On-link 192.168.12.2 276
      192.168.1.0 255.255.255.0 On-link 192.168.1.2 266
      192.168.1.2 255.255.255.255 On-link 192.168.1.2 266
      192.168.1.255 255.255.255.255 On-link 192.168.1.2 266
      192.168.12.0 255.255.255.0 On-link 192.168.12.2 276
      192.168.12.2 255.255.255.255 On-link 192.168.12.2 276
      192.168.12.255 255.255.255.255 On-link 192.168.12.2 276
    224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
      224.0.0.0 240.0.0.0 On-link 192.168.12.2 276
      224.0.0.0 240.0.0.0 On-link 192.168.1.2 266
    255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
      255.255.255.255 255.255.255.255 On-link 192.168.12.2 276
      255.255.255.255 255.255.255.255 On-link 192.168.1.2 266
    ===========================================================================
    Постоянные маршруты:
    Сетевой адрес Маска Адрес шлюза Метрика
    0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию
    ===========================================================================

    IPv6 таблица маршрута
    ===========================================================================
    Активные маршруты:
    Метрика Сетевой адрес Шлюз
    1 306 ::1/128 On-link
    15 276 fe80::/64 On-link
    14 266 fe80::/64 On-link
    15 276 fe80::b494:c0c0:f42b:732e/128
    On-link
    14 266 fe80::b836:1b21:ee8f:99e4/128
    On-link
    1 306 ff00::/8 On-link
    15 276 ff00::/8 On-link
    14 266 ff00::/8 On-link
    ===========================================================================
    Постоянные маршруты:
    Отсутствует

    C:\Users\Admin>

    27 августа 2013 г. 12:33
  • Зачем вам IPv6 ?
    27 августа 2013 г. 12:40
  • Зачем вам IPv6 ?
     Он не нужен впринципе...

    27 августа 2013 г. 12:43
  • Зачем вам IPv6 ?

     Он не нужен впринципе...

    Так можно выключить. Я думаю надо все отключать что не надо.
    27 августа 2013 г. 12:51
  • Зачем вам IPv6 ?

     Он не нужен впринципе...

    Так можно выключить. Я думаю надо все отключать что не надо.

    Но это явно не вернёт пинг, когда он отваливается :(

    Есть ещё какие-нибудь идеи в какую сторону ковырять?

    27 августа 2013 г. 12:58
  • ну посмотрите вы наконец на 192.168.1.1 активность пакетов ICMP с вашего больного сервера. Что ж вы такой упрямый? ;) Нет тут никакого колдунства. Все более-менее очевидно. 
    27 августа 2013 г. 13:05
  • Wireshark вам в помощь.


    27 августа 2013 г. 13:12
  • ну посмотрите вы наконец на 192.168.1.1 активность пакетов ICMP с вашего больного сервера. Что ж вы такой упрямый? ;) Нет тут никакого колдунства. Все более-менее очевидно. 
     Я б сделал, если б знал точную команду. А то там вываливается куча мусора....

    27 августа 2013 г. 13:25
  • tcpdump -n icmp and 'icmp[0] != 8 and icmp[0] != 0'
    27 августа 2013 г. 13:33
  • Народ, помогите! Просто ппц какой-то!

    28 августа 2013 г. 6:20
  • попробуйте ловить пинг только с вашего сервера

    tcpdump -i ИМЯ_СЕТЕВОЙ icmp and icmptype = 0 and src host ИП_ВАШЕГО_СЕРВЕРА


    • Изменено Sudden Death 28 августа 2013 г. 10:16
    28 августа 2013 г. 9:59
  • попробуйте ловить пинг только с вашего сервера

    tcpdump -i ИМЯ_СЕТЕВОЙ icmp and icmptype = 0 and src host ИП_ВАШЕГО_СЕРВЕРА


    Команду запустил. Когда сервер терял пинг с 8.8.8.8, на гейте ничего не происходило. Когда пинги восстанавливались, гейт это отображал

    root@gwn1:/home/misha# tcpdump -i eth0 icmp and icmptype = 0 and src host 192.168.1.2
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

    (пингов нет, тишина)

    (пинги вернулись)

    17:02:14.851693 IP 192.168.1.2 > google-public-dns-a.google.com: ICMP echo request, id 7, seq 46900, length 40
     17:02:15.350744 IP 192.168.1.2 > google-public-dns-a.google.com: ICMP echo request, id 7, seq 46901, length 40
     17:02:15.852882 IP 192.168.1.2 > google-public-dns-a.google.com: ICMP echo request, id 7, seq 46902, length 40
     17:02:16.351875 IP 192.168.1.2 > google-public-dns-a.google.com: ICMP echo request, id 7, seq 46903, length 40


    28 августа 2013 г. 13:03
  • отлично. Значит с гейтом все ок. Получается это проблема в промежуточном оборудовании (свитчах). попробуйте как-либо исключить промежуточное оборудование и посмотреть, что будет. Самое простое, чтобы сделал я, это взял три пачкорда и какой-нибудь подходящий свитч. Подключил гетвей к свитчу, второй порт свитча к локальной сети, третий порт - к серверу. 

    Если сетевое оборудование управляемое, активность можно посмотреть и на нем. Если вы используете Dlink 3ххх серии, обновите FirmWare. Эти свитчи славятся подобной фигней (по крайней мере в моей практике)

    28 августа 2013 г. 13:27
  • отлично. Значит с гейтом все ок. Получается это проблема в промежуточном оборудовании (свитчах). попробуйте как-либо исключить промежуточное оборудование и посмотреть, что будет. Самое простое, чтобы сделал я, это взял три пачкорда и какой-нибудь подходящий свитч. Подключил гетвей к свитчу, второй порт свитча к локальной сети, третий порт - к серверу. 

    Если сетевое оборудование управляемое, активность можно посмотреть и на нем. Если вы используете Dlink 3ххх серии, обновите FirmWare. Эти свитчи славятся подобной фигней (по крайней мере в моей практике)

    Свичи циско 50-портовые, управляемые. Активность вижу. Менял на том порте, который идёт к серверу дуплекс/фулдуплекс/скорость подключения... Толку 0
    Есть и старые свичи, с ними и поэкспериментирую, завтра отпишусь.
    28 августа 2013 г. 14:03
  • Переткнул в другой свич, 8-м портовый. Другой конец - в циску. Ничего не изменилось, пинги теряются.
    29 августа 2013 г. 7:33
  • отлично. Значит с гейтом все ок. Получается это проблема в промежуточном оборудовании (свитчах). попробуйте как-либо исключить промежуточное оборудование и посмотреть, что будет. Самое простое, чтобы сделал я, это взял три пачкорда и какой-нибудь подходящий свитч. Подключил гетвей к свитчу, второй порт свитча к локальной сети, третий порт - к серверу. 

    Если сетевое оборудование управляемое, активность можно посмотреть и на нем. Если вы используете Dlink 3ххх серии, обновите FirmWare. Эти свитчи славятся подобной фигней (по крайней мере в моей практике)

    И так сделал.. Результаты те-же...
    29 августа 2013 г. 10:36
  • а доступ к серверу в той же подсети, что смотрит в Интернет, остается? Хм.

    Попробуйте на сервере выполнить вот это https://ticketing.nforce.com/index.php?/Knowledgebase/Article/View/19/0/fix-slow-remote-desktop-connection

    Это отключение фич в настройке сети в 2008. Иногда помогает, ибо 2008 считает себя слишком умным.

    29 августа 2013 г. 13:54
  • а доступ к серверу в той же подсети, что смотрит в Интернет, остается? Хм.

    Попробуйте на сервере выполнить вот это 

    Это отключение фич в настройке сети в 2008. Иногда помогает, ибо 2008 считает себя слишком умным.

    Та-же фигня... :(
    30 августа 2013 г. 12:35
  • Народ, помогите! Есть хоть какие-нибудь идеи, что это может быть? Экспериментировал всю неделю...
    5 сентября 2013 г. 6:14
  • Мы же все уже проверили. Проблема у вас в проходном оборудовании. Возможно, в том, в которое включен шлюз для выхода в Интернет. Надо смотреть уже на оборудовании, а это за рамками форума, как мне кажется.
    5 сентября 2013 г. 6:32
  • Мы же все уже проверили. Проблема у вас в проходном оборудовании. Возможно, в том, в которое включен шлюз для выхода в Интернет. Надо смотреть уже на оборудовании, а это за рамками форума, как мне кажется.
    Проблема была в вирусе на компе 192.168.1.40, который слал пакеты на все компы в первой подсети. Проблема решилась удалением вируса... Но блин интересно, каким образом он фактически лишал доступа к интернету все компы на ОС выше WinXP. При этом WinXP и 2003 работали.... 
    7 сентября 2013 г. 4:59