Пинг сообщит о дублированных и поврежденных пакетах. Дублирующие пакеты никогда не должны возникать, и, по-видимому, они вызваны неправильными повторными передачами на уровне канала. Дубликаты могут встречаться во многих ситуациях и редко (если вообще когда-либо) являются хорошим признаком, хотя наличие низких уровней дубликатов не всегда может быть причиной для тревоги.
Поврежденные пакеты, очевидно, являются серьезной причиной для тревоги и часто указывают на неисправное оборудование где-то на пути пакета ping (в сети или на хостах).
Для этого есть разные причины. Вы захватывали сетевой трафик с помощью интерфейса в смешанном режиме? Иногда это является причиной дублирования пакетов.
Это означает, что ответный пакет является дубликатом. Ответы ICMP содержат порядковый номер. Иногда вы получите более одного ответа с одним и тем же порядковым номером. Это обычно вызывается неисправными сетями. Беспроводные сети часто полагаются на повторную отправку пакетов, если они не прошли надлежащую проверку, и если первая действительно сработала, повторная отправка будет дубликатом. При обычном использовании дубликаты отбрасываются. В ответах ping они отмечены, потому что они что-то рассказывают о том, как работает сеть. Например, если вы получаете 100% дубликатов, какой-то механизм обнаружения ошибок может быть поврежден.
Проверьте, если несколько компьютеров не используют тот же IP. Это был мой случай для этого сообщения.
Я сталкиваюсь с этим, когда клонирую виртуальную машину и запускаю оба одновременно. Конфигурация сети была в режиме моста и IP связан с Mac. Поэтому, когда вторая машина начала использовать сеть, у меня возникли проблемы с ssh:
> >>Много чего может быть. Такое, например, было когда один умник на выставил >>в винде IP старенького HP-UXа. > >То есть кто-то использует IP моего шлюза?
>Всем привет! Не подскажет кто, что означает этот DUP? инет пропадает время >от времени, и иногда проскакивает вот этот DUP.
У меня такое очень часто возникает если в линке присутствует радиобридж. Служит показателем того, что этот бридж работает плохо.
>Всем привет! Не подскажет кто, что означает этот DUP? инет пропадает время >от времени, и иногда проскакивает вот этот DUP.
У меня ситуация еще хуже, уже не знаю что смотреть даже и где. Ситуация следующая В один прекрасный день появилась такая вот штука сеть 192.168.1.0/24
64 bytes from 192.168.1.149: icmp_seq=0 ttl=255 time=0.601 ms 64 bytes from 192.168.1.116: icmp_seq=0 ttl=255 time=1.016 ms (DUP!) 64 bytes from 192.168.1.183: icmp_seq=0 ttl=64 time=1.138 ms (DUP!) 64 bytes from 192.168.1.254: icmp_seq=0 ttl=60 time=1.730 ms (DUP!) 64 bytes from 192.168.1.160: icmp_seq=0 ttl=64 time=6.516 ms (DUP!) 64 bytes from 192.168.1.149: icmp_seq=1 ttl=255 time=0.300 ms
60 bytes from 192.168.1.1 (00:13:22:26:d6:3a): icmp_seq=0 time=19.478 msec 64 bytes from 192.168.1.149 (08:00:66:80:47:99): icmp_seq=0 time=9.481 msec (DUP!) 60 bytes from 192.168.1.183 (00:0c:f8:ca:58:c2): icmp_seq=0 time=9.584 msec (DUP!) 60 bytes from 192.168.1.116 (08:00:33:00:cd:41): icmp_seq=0 time=9.602 msec (DUP!) 60 bytes from 192.168.1.160 (00:01:a9:8a:26:24): icmp_seq=0 time=9.615 msec (DUP!) 60 bytes from 192.168.1.254 (00:10:40:b9:9a:7f): icmp_seq=0 time=9.626 msec (DUP!)
64 bytes from 192.168.1.149 (08:00:66:80:47:99): icmp_seq=0 time=9.481 msec 60 bytes from 192.168.1.183 (00:0c:f8:ca:58:c2): icmp_seq=0 time=9.584 msec 60 bytes from 192.168.1.116 (08:00:33:00:cd:41): icmp_seq=0 time=9.602 msec 60 bytes from 192.168.1.160 (00:01:a9:8a:26:24): icmp_seq=0 time=9.615 msec 60 bytes from 192.168.1.254 (00:10:40:b9:9a:7f): icmp_seq=0 time=9.626 msec 60 bytes from 192.168.1.3 (00:13:22:26:d6:3a): icmp_seq=0 time=19.478 msec
На этом же сервер сидит вторая сеть 192.168.100.0/24 с ней все впорядке.
ставлю другой сервер 100% работоспособный результат такой же. Свич тоже менял.
Народ может кто подскажет что еще может быть?
ага, фиг там два, два было на промежуточном свиче(с фрёй), с роутера шлется вот сколько: 64 packets captured 44630 packets received by filter 0 packets dropped by kernel . вот ё! фря7.0,SMP
> Всем привет! Не подскажет кто, что означает этот DUP? инет пропадает время > от времени, и иногда проскакивает вот этот DUP.
приходит два ответа, например такое возможно если вы пингуете с машины которая включена в порт свитча который настроен как получатель port mirroring в свитче
Пример выше.Почему свитч отвечает 2-3 раза? в wireshark
Конфликта ip адресов нету,менял адрес,такая же ситуация.
либо конфликт есть, либо свитч глючный и размножает пакеты, либо на свитче петля
в этом твоём логе вайершарка хорошо бы посмотреть, идут ли дубликаты с того же MAC адреса
По конфликту есть в первом посте.
а в свитч что-то воткнуто помимо пингующего компа?
все 24 порта заняты.
если я не ошибаюсь то я так и написал,вопрос почему?
А что за сеть? Структура и железо
А что за коммутатор?
Сеть разделена на vlan-ы или это просто несколько ip-сетей в одной среде? Если есть vlan-ы, то есть ли у коммутатора ip-адреса в этих сетях?
обычно это говорит о том что в сети есть петля 🙂
Ещё может быть криво настроена агрегация между свичами, когда с одной стороны etherchannel а с другой просто два порта
коммутатор DGS-1210-28P.Их в сети два,и оба занимаются такой хернёй,на остальных проблем нет. При пинге из подсети коммутатора,проблем нет.И ответ почему-то аж 8 мс.Хотя я в него включён. Есть vlanы но в данном случае это две подсети в одной среде без vlan.
Если это единственная проблем, то не трогай ничего в них.
Хуже них только TP-Link T2600G-52TS
Лови решение. Management VLAN Configuration. Включи его. У самого в сети один длинк так тупит. Полдня потратил, искал кольцо. Оказалось проблема в ущербном коммутаторе
ping сообщит о дублированных и поврежденных пакетах. Дублирующие пакеты никогда не должны возникать и, по-видимому, вызваны неправильными повторными передачами на уровне ссылок. Дубликаты могут встречаться во многих ситуациях и редко (если вообще когда-либо) являются хорошим знаком, хотя наличие низкого уровня дубликатов может не всегда быть причиной тревоги.
Поврежденные пакеты, очевидно, являются серьезной причиной возникновения тревоги и часто указывают на неисправное оборудование где-то на пути пакета ping (в сети или на хостах).
Для этого есть разные причины: захватили ли вы свой сетевой трафик с помощью интерфейса в беспорядочном режиме? Иногда это является причиной для дублированных пакетов.
Это означает, что ответный пакет является дубликатом. Каждый ICMP-пакет, отправленный для pint-хоста, имеет порядковый номер, который возвращается с ответом. Иногда вы получите больше одного ответа. Обычно это вызвано неправильными сетями. Беспроводные сети часто полагаются на повторную отправку пакетов, если они не получают правильной проверки, и если первая действительно работает, повторная отправка будет дублировать. При обычном использовании дубликаты отбрасываются. В ответах ping они отмечены, потому что они рассказывают вам о том, как функционирует сеть. Например, если вы получаете 100% дубликатов, механизм обнаружения сбоев, вероятно, будет нарушен.
Проверьте, что паровые машины не используют один и тот же ip. Это был мой случай с этим сообщением.
Я сталкиваюсь с этим, когда клонирую машину vm и запускаю оба одновременно. Конфигурация сети была в режиме моста и ip связана с mac. Поэтому, когда вторая машина начинает использовать сеть, я испытываю проблемы с ssh:
И ошибка ping при ping. Надеюсь, это поможет кому-то)
Pinging some hosts causes multiple responses for a ping echo request. This is reported by the Linux and Mac OSX ping command but not by Windows. For iPhones the results depend on the app, e.g. NetAnalyzer and Ping Lite do not show the DUPs, whereas Ping does. Typically from a RHEL6-64 Linux host (pinger.slac.stanford.edu, not using multicast, the interfaces are not bonded) at SLAC it appears as:
On a SunOS host it appears as:
Duplicate packets should never occur when pinging a unicast address, and seem to be caused by inappropriate link-level retransmissions. Duplicates may occur in many situations and are rarely (if ever) a good sign, although the presence of low levels of duplicates may not always be cause for alarm. Duplicates are expected when pinging a broadcast or multicast address, since they are not really duplicates but replies from different hosts to the same request. From http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=ping#4
Duplicate ping responses can be seen for example from SLAC to CERN or www.realbroadband.co.sz. They can be caused by:
Some tests that may help include:
An example of the prevalence of duplicate ping packets comes from PingER measurements on March 31st 2012 from SLAC to 703 hosts in over 160 countries. Of these hosts 15 responded with duplicate pings. For 13 of the 15 hosts it occurred on both 100 and 1000 Byte pings. Out of 10 pings sent:
The sites of the hosts range from national labs (CERN, IHEP SU), developed countries (Israel), developing countries (Burkina Faso, Malawi, Mauritius, Sierra Leone, Swaziland, Zambia), and educational sites (SDSC). Only the www.cern.ch address was consistent in the number and frequency of duplicate pings.
PingER simply reports whether there were duplicates or not. A useful metric is to report the number of pings received/number pings sent. The number received may depend on the ping command options. One option will send a given number of pings until it receives that many back or times out. Another option will send 10 pings and wait (or time out) until they are received. So the metric value may also depend on the ping command.
For each ping sent to www.cern.ch from pinger.slac.stanford.edu or ping.desy.de, perfsonar-unimas.myren.net.my (but not from pinger-host.fnal.gov, netmon.physics.carleton.ca) it responds with
A possible source is the Load Balancing of the CERN www server. SLAC also load balances (via F5s) its www server. However, the SLAC Load Balancer only forwards the http/https requests to the web servers, the pings are responded to by the F5 load balancer itself. Thus though we pinged www.slac.stanford.edu from ping.desy.de, we do not see any duplicate pings.
Analysis of data in Jan 2015
We have data capable of detecting duplicate pings from PingER, going back to 2005 which I have mined to look for DUP’s. The input data is one line per set of pings made from SLAC to a remote host. The line indicates whether there were DUP’s. Each line is for a remote host monitored from SLAC with up to 10 successful (with a cut off at 30 tries) 100 Byte pings each 30 mins.
We wrote a perl script (dupes.pl) to analyze the data.
The monitoring host (pinger.slac.stanford.edu) is not using multicast, the interfaces are not bonded. It is running Linux:
Linux pinger 2.6.32-279.19.1.el6.i686 #1 SMP Sat Nov 24 14:42:18 EST 2012 i686 i686 i386 GNU/Linux
Of the 128 S. E. Asian hosts monitored from SLAC (number of hosts with DUPs / number of hosts monitored in country)
(??) on 28-Апр-06, 16:55
