Есть ли алгоритм отлова (DUP!) в ping?
 

PING 192.168.0.7 (192.168.0.7) 56(84) bytes of data.
64 bytes from 192.168.0.7: icmp_seq=1 ttl=128 time=0.534 ms
64 bytes from 192.168.0.7: icmp_seq=1 ttl=255 time=9.582 ms (DUP!)
64 bytes from 192.168.0.7: icmp_seq=2 ttl=128 time=0.291 ms
64 bytes from 192.168.0.7: icmp_seq=2 ttl=255 time=12.376 ms (DUP!)
64 bytes from 192.168.0.7: icmp_seq=3 ttl=128 time=0.279 ms
64 bytes from 192.168.0.7: icmp_seq=3 ttl=255 time=8.359 ms (DUP!)
64 bytes from 192.168.0.7: icmp_seq=4 ttl=128 time=0.474 ms
64 bytes from 192.168.0.7: icmp_seq=4 ttl=255 time=23.480 ms (DUP!)
.
Как с этим бороться быстро! и эффективно?

а кто отвечает второй раз ? судя по ttl железки разные

arping наверн или как-то выяснить мак, потом понять кто и чего, как по другому я хз.

а ну да wireshark\tcpdump же это ж универсально раз поставил и все всегда быстро и эффективно, если ещё свитчи cisc-и , то Cisco Network Assistant по бырому можно найти на каких портах мак засветился, даж если этих свитчей много, чтоб не ходить на каждый отдельно....ну или запилить скрипт там какой по snmp например маки сгребать...ну а там когда поймете что это вылазиет, будет уже проще внести коррективы для следующих разгребонов если это например специфичное поведение какой-нить железяки.

Железки одни и те же, их всего пять из полутора сотен в сегменте, два маршрутизатора, два сервера(win2003 и Centos) и NAS. MAC один на один IP, устройство отключаешь - не пингуется вообще.
Tcpdump - крайне долго, потому и спрашиваю про алгоритм)

[quote=Старый Седой Лис;28829127]MAC один на один IP[/quote]
т.е. в tcpdump -ev -i ethX host 192.168.0.7
[quote]
64 bytes from 192.168.0.7: icmp_seq=1 ttl=128 time=0.534 ms
64 bytes from 192.168.0.7: icmp_seq=1 ttl=255 time=9.582 ms (DUP!)[/quote]
показывает одним маком если пинговать с тойже подсети? и так с 5-ю железками ? я тогда хз, самому интересно унать чего это :)

кста, а в логах коммутатора нет macflap по интерфейсам ?

I 01/31/13 14:44:32 time: System time adjusted by -301 seconds
I 01/31/13 14:52:02 time: System time adjusted by -149 seconds
W 01/31/13 14:59:35 time: SNTP server poll timed out
W 01/31/13 15:07:05 time: SNTP server poll timed out
I 01/31/13 15:14:32 time: System time adjusted by -450 seconds
W 01/31/13 15:22:05 time: SNTP server poll timed out
I 01/31/13 15:29:32 time: System time adjusted by -300 seconds
I 01/31/13 15:37:02 time: System time adjusted by -150 seconds
I 01/31/13 15:44:32 time: System time adjusted by -150 seconds

лог коммутатора

6-701054 > вот и я в... этом, как его. причем три железки на одном коммутаторе, а два коммутатора еще за двумя в кольце... уже этаж положил вместе с коммутаторами - пришельцев нет, на остальных устройствах дупы остаются.

Пинг с 192.168.0.2 на 192.168.0.254 с дупами.
[root@m log]# tcpdump icmp -ev -i eth0 host 192.168.0.254

192.168.0.2 > 192.168.0.254: ICMP echo request, id 23111, seq 9664, length 64
16:02:45.132204 c8:60:00:c7:79:d3 (oui Unknown) > 00:25:00:ac:c9:f2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 33841, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.254 > 192.168.0.2: ICMP echo reply, id 23111, seq 9664, length 64
16:02:46.133272 00:25:00:ac:c9:f2 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 57672, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.2 > 192.168.0.254: ICMP echo request, id 23111, seq 9665, length 64
16:02:46.133292 c8:60:00:c7:79:d3 (oui Unknown) > 00:25:00:ac:c9:f2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 33842, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.254 > 192.168.0.2: ICMP echo reply, id 23111, seq 9665, length 64
16:02:47.134376 00:25:00:ac:c9:f2 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 51547, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.2 > 192.168.0.254: ICMP echo request, id 23111, seq 9666, length 64
16:02:47.134394 c8:60:00:c7:79:d3 (oui Unknown) > 00:25:00:ac:c9:f2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 33843, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.254 > 192.168.0.2: ICMP echo reply, id 23111, seq 9666, length 64
16:02:48.135449 00:25:00:ac:c9:f2 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 17738, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.2 > 192.168.0.254: ICMP echo request, id 23111, seq 9667, length 64
16:02:48.135470 c8:60:00:c7:79:d3 (oui Unknown) > 00:25:00:ac:c9:f2 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 33844, offset 0, flags [none], proto ICMP (1), length 84)
192.168.0.254 > 192.168.0.2: ICMP echo reply, id 23111, seq 9667, length 64
^C

9-Старый Седой Лис > не вижу дупов, 4 запрос/ответ

возможно если в сети образовалось кольцо.
коммутация (физика) выпонена нормально?
попробуй посмотреть пинг со своего девайса и с коммутатора.

непонятно...мак один ttl-и тоже...tcpdump же на 192.168.0.2 запущен ?

10-gloomymen > это tcpdump icmp -ev -i eth0 на центосе, который отвечает дупами.

не, там все красиво он видит и отвечает правильно, надо на том с кого (кому дуп приходит)

как отвечают ресурсы типа ya.com ???
попробуй послушать шарком на порту. может что ответит.

Вот с пингующего центоса

[root@gik etc]# tcpdump icmp -ev -i eth0
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:29:38.068971 c8:60:00:c7:7a:68 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
gik.local > m.gik.loc: ICMP echo request, id 9534, seq 45, length 64
16:29:38.069161 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 61700, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 45, length 64
16:29:38.072605 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 10546, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 45, length 64
16:29:39.070649 c8:60:00:c7:7a:68 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
gik.local > m.gik.loc: ICMP echo request, id 9534, seq 46, length 64
16:29:39.070858 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 61702, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 46, length 64
16:29:39.074605 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 11494, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 46, length 64
16:29:40.072650 c8:60:00:c7:7a:68 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
gik.local > m.gik.loc: ICMP echo request, id 9534, seq 47, length 64
16:29:40.072867 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 61703, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 47, length 64
16:29:40.076737 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 13147, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 47, length 64
16:29:41.073782 c8:60:00:c7:7a:68 (oui Unknown) > c8:60:00:c7:79:d3 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
gik.local > m.gik.loc: ICMP echo request, id 9534, seq 48, length 64
16:29:41.073981 c8:60:00:c7:79:d3 (oui Unknown) > c8:60:00:c7:7a:68 (oui Unknown), ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 61704, offset 0, flags [none], proto ICMP (1), length 84)
m.gik.loc > gik.local: ICMP echo reply, id 9534, seq 48, length 64

15-glumymen > WAN и остальная локалка отвечают нормально

ну или если там венда, то кусок из wiresharka аналогичный

13-Старый Седой Лис >[em]на центосе, который отвечает дупами.[/em]
это, простите, бред
центось отвечает нормально, пакеты дублирует какой-то из коммутаторов, который считает, что пакет не был доставлен, считать она так может из-за появления несущей в канале в течении интервала доставки (коллизии), либо ошибочно

Старый Седой Лис > а сеть беспроводная или проводная?

+19, ну может еще болячки с недохешем недокоммутатора
спросите у 701054, он вам по ошибкам хешей ссылочку подкинет, я уже не найду наверное

кусок из пингующей винды
419 0.967848000 192.168.0.252 192.168.0.254 ICMP 74 Echo (ping) request id=0x0001, seq=15574/54844, ttl=128
422 0.970425000 192.168.0.252 192.168.0.254 ICMP 102 Destination unreachable (Protocol unreachable)
1242 1.968891000 192.168.0.252 192.168.0.254 ICMP 74 Echo (ping) request id=0x0001, seq=15575/55100, ttl=128
1246 1.969439000 192.168.0.252 192.168.0.254 ICMP 102 Destination unreachable (Protocol unreachable)
1927 2.969987000 192.168.0.252 192.168.0.254 ICMP 74 Echo (ping) request id=0x0001, seq=15576/55356, ttl=128
1930 2.972615000 192.168.0.252 192.168.0.254 ICMP 102 Destination unreachable (Protocol unreachable)

20-glumymen > проводная. да как-то не поднимается рука HP и Allied telesis недокуммутаторами обозвать))

23-Старый Седой Лис > не стоит молиться на буквы, даже у сиськи есть такие недо

остается только метод научного тыка , снять линки со свитчей и добавлять по одному..., в идеале вообще б собрать все эти 5 с дупами в один, ещё правда можно попробовать маки поменять на этих железяках ну или свитчи...отпишите потом, где собака зарылась.

про хэши тут лучше всего написано [url]http://habrahabr.ru/post/155265/[/url]

и что-то слишком часто такое в маршрутизаторе стало появляться

Jan 31 17:41:41:990 2013 MSTP Information MSTP_NOTIFIED_TC Instance 0's port Bridge-Aggregation2 was notified of a topology change.
Jan 31 17:41:41:566 2013 MSTP Information MSTP_NOTIFIED_TC Instance 0's port Bridge-Aggregation2 was notified of a topology change.
Jan 31 17:41:00:041 2013 MSTP Information MSTP_NOTIFIED_TC Instance 0's port Bridge-Aggregation2 was notified of a topology change.
Jan 31 17:40:59:612 2013 MSTP Information MSTP_NOTIFIED_TC Instance 0's port Bridge-Aggregation2 was notified of a topology change.

25-701054 > уже моск вскипел, ждем выходных для научного тыка, чтоб его

мож приложить до выяснения дублирующиеся линки, кольца там у вас и вообще....
надо идти

28-701054 > так работало все и топология не менялась

можно поочередно сращивать аплинки, исключая коммутаторы по одному или пачками насколько, длина позволяет, на трассе между конечными хостами

возможно всего один порт дурит, не весь коммутатор

от же [filolog]епть[/filolog], вся писька в Intel AMT оказалась. Пофиксили. Но начитался по самое немогу, спасибо)

А подробнее можно? Амт с тем же IP на той же сетевке ?

как вариант в сети есть хост с ип 192.168.0.5/30 и/или 192.168.0.6/30. Для него 192.168.0.7 является бродкастом. Вот он и отвечает на пинг.

33-701054 > Аха, забыли icmp запретить и из статики в DHCP перетащили с тем же адресом.

34-spiegel > не, маски сразу проверил

34-spiegel > чей стек будет отвечать на echo request по адресу бродкаста?
xp/7/centos 6.3, не отвечают

33-701054 > то есть была статика с локальными адресами без маршрута по умолчанию и у оси и у АМТ, а стало у оси ДХЦП с маршрутом, а у АМТ не поменяли. Весьма странная реакция, честно говоря.

37-gloomymen >циска ответит:

R1#ping 192.168.1.7(R3)

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.7, timeout is 2 seconds:

Reply to request 0 from 192.168.1.6, 68 ms
Reply to request 1 from 192.168.1.6, 40 ms
Reply to request 2 from 192.168.1.6, 68 ms
Reply to request 3 from 192.168.1.6, 32 ms
Reply to request 4 from 192.168.1.6, 56 ms

параллельно на R2 deb ip icmp:

ICMP: echo reply sent, src 192.168.1.7, dst 192.168.1.5

R1, R2, R3 - в одной сети но разные маски