Есть ли алгоритм отлова (DUP!) в ping?- Сети и их администрирование

Гость

0 - 31.01.2013 - 11:57

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!)
.
Как с этим бороться быстро! и эффективно?

Гость

1 - 31.01.2013 - 12:46

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

Гость

2 - 31.01.2013 - 12:51

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

Гость

3 - 31.01.2013 - 13:05

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

Гость

4 - 31.01.2013 - 13:37

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

Гость

5 - 31.01.2013 - 13:48

Цитата:

Сообщение от Старый Седой Лис

MAC один на один IP

т.е. в tcpdump -ev -i ethX host 192.168.0.7

Цитата:

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!)

показывает одним маком если пинговать с тойже подсети? и так с 5-ю железками ? я тогда хз, самому интересно унать чего это :)

Гость

6 - 31.01.2013 - 13:51

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

Гость

7 - 31.01.2013 - 14:49

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

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

Гость

8 - 31.01.2013 - 14:52

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

Гость

9 - 31.01.2013 - 15:05

Пинг с 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

Гость

10 - 31.01.2013 - 15:22

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

Гость

11 - 31.01.2013 - 15:28

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

Гость

12 - 31.01.2013 - 15:30

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

Гость

13 - 31.01.2013 - 15:30

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

Гость

14 - 31.01.2013 - 15:32

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

Гость

15 - 31.01.2013 - 15:33

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

Гость

16 - 31.01.2013 - 15:33

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

[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

Гость

17 - 31.01.2013 - 15:33

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

Гость

18 - 31.01.2013 - 15:34

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

Гость

19 - 31.01.2013 - 15:34

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

Гость

20 - 31.01.2013 - 15:44

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

Гость

21 - 31.01.2013 - 15:46

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

Гость

22 - 31.01.2013 - 15:52

кусок из пингующей винды
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)

Гость

23 - 31.01.2013 - 15:55

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

Гость

24 - 31.01.2013 - 15:58

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

Гость

25 - 31.01.2013 - 16:41

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

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

Гость

26 - 31.01.2013 - 16:43

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

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.

Гость

27 - 31.01.2013 - 16:45

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

Гость

28 - 31.01.2013 - 17:00

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

Гость

29 - 31.01.2013 - 17:08

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

Гость

30 - 31.01.2013 - 17:09

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

Гость

31 - 31.01.2013 - 17:13

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

Гость

32 - 31.01.2013 - 17:26

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

Гость

33 - 31.01.2013 - 17:34

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

Гость

34 - 31.01.2013 - 17:45

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

Гость

35 - 31.01.2013 - 18:03

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

Гость

36 - 31.01.2013 - 18:04

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

Гость

37 - 31.01.2013 - 18:20

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

Гость

38 - 31.01.2013 - 18:21

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

Гость

39 - 31.01.2013 - 18:49

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 - в одной сети но разные маски

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

Интернет-форум Краснодарского края и Краснодараг. Краснодар, Краснодарский край 2022г.

Интернет-форум Краснодарского края и Краснодара
г. Краснодар, Краснодарский край 2022г.