Перейти к содержимому
Калькуляторы

Потери фрагментированных ICMP пакетов это нормально?

Ответить

HelgS   

HelgS
Опубликовано

Наблюдаю у одного из провайдеров потери фрагментированных ICMP пакетов. Это нормально для провайдера юриков?

Когда размер пакетов меньше или равен MTU - все хорошо:

PING mail.ru (94.100.191.203) 1472(1500) bytes of data.
1480 bytes from 94.100.191.203: icmp_req=1 ttl=56 time=61.2 ms
[skipped]
1480 bytes from 94.100.191.203: icmp_req=50 ttl=56 time=60.7 ms

--- mail.ru ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49064ms
rtt min/avg/max/mdev = 60.616/61.109/63.449/0.627 ms

 

Как только пакеты начинают фрагментироваться появляются существенные (40%-70%) потери:

PING mail.ru (94.100.191.203) 1473(1501) bytes of data.
1481 bytes from 94.100.191.203: icmp_req=1 ttl=55 time=61.1 ms
1481 bytes from 94.100.191.203: icmp_req=4 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=5 ttl=55 time=61.6 ms
1481 bytes from 94.100.191.203: icmp_req=6 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=7 ttl=55 time=61.1 ms
1481 bytes from 94.100.191.203: icmp_req=12 ttl=55 time=80.7 ms
1481 bytes from 94.100.191.203: icmp_req=17 ttl=55 time=61.0 ms
1481 bytes from 94.100.191.203: icmp_req=18 ttl=55 time=63.2 ms
1481 bytes from 94.100.191.203: icmp_req=21 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=22 ttl=55 time=86.6 ms
1481 bytes from 94.100.191.203: icmp_req=23 ttl=55 time=61.0 ms
1481 bytes from 94.100.191.203: icmp_req=26 ttl=55 time=61.3 ms
1481 bytes from 94.100.191.203: icmp_req=30 ttl=55 time=61.5 ms
1481 bytes from 94.100.191.203: icmp_req=34 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=35 ttl=55 time=61.5 ms
1481 bytes from 94.100.191.203: icmp_req=41 ttl=55 time=61.3 ms
1481 bytes from 94.100.191.203: icmp_req=42 ttl=55 time=61.4 ms
1481 bytes from 94.100.191.203: icmp_req=43 ttl=55 time=61.0 ms
1481 bytes from 94.100.191.203: icmp_req=49 ttl=55 time=61.3 ms

--- mail.ru ping statistics ---
50 packets transmitted, 19 received, 62% packet loss, time 49209ms
rtt min/avg/max/mdev = 61.037/63.756/86.680/6.930 ms

 

С увеличением размера потери растут:

PING mail.ru (94.100.191.202) 1972(2000) bytes of data.
1980 bytes from 94.100.191.202: icmp_req=3 ttl=55 time=61.6 ms
1980 bytes from 94.100.191.202: icmp_req=18 ttl=55 time=61.3 ms
1980 bytes from 94.100.191.202: icmp_req=29 ttl=55 time=61.2 ms
1980 bytes from 94.100.191.202: icmp_req=30 ttl=55 time=62.8 ms
1980 bytes from 94.100.191.202: icmp_req=31 ttl=55 time=61.3 ms
1980 bytes from 94.100.191.202: icmp_req=42 ttl=55 time=61.3 ms
1980 bytes from 94.100.191.202: icmp_req=45 ttl=55 time=61.4 ms
1980 bytes from 94.100.191.202: icmp_req=46 ttl=55 time=61.5 ms
1980 bytes from 94.100.191.202: icmp_req=48 ttl=55 time=61.3 ms
--- mail.ru ping statistics ---
50 packets transmitted, 9 received, 82% packet loss, time 49109ms
rtt min/avg/max/mdev = 61.296/61.602/62.895/0.575 ms

PING mail.ru (94.100.191.201) 3972(4000) bytes of data.
3980 bytes from 94.100.191.201: icmp_req=1 ttl=55 time=67.3 ms
3980 bytes from 94.100.191.201: icmp_req=19 ttl=55 time=65.0 ms
3980 bytes from 94.100.191.201: icmp_req=23 ttl=55 time=65.2 ms
3980 bytes from 94.100.191.201: icmp_req=28 ttl=55 time=412 ms
3980 bytes from 94.100.191.201: icmp_req=29 ttl=55 time=65.6 ms
3980 bytes from 94.100.191.201: icmp_req=36 ttl=55 time=64.7 ms
3980 bytes from 94.100.191.201: icmp_req=37 ttl=55 time=65.1 ms
3980 bytes from 94.100.191.201: icmp_req=47 ttl=55 time=66.0 ms
3980 bytes from 94.100.191.201: icmp_req=48 ttl=55 time=66.1 ms
--- mail.ru ping statistics ---
50 packets transmitted, 9 received, 82% packet loss, time 49316ms
rtt min/avg/max/mdev = 64.744/104.229/412.830/109.109 ms


PING mail.ru (94.100.191.202) 5972(6000) bytes of data.
5980 bytes from 94.100.191.202: icmp_req=49 ttl=55 time=68.7 ms
--- mail.ru ping statistics ---
50 packets transmitted, 1 received, 98% packet loss, time 49000ms
rtt min/avg/max/mdev = 68.765/68.765/68.765/0.000 ms

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Megas   

Megas
Опубликовано

оО думал у меня только.

>ping google.com -l 1473

Обмен пакетами с google.com [173.194.69.100] по 1473 байт:

Control-C
^C
>ping google.com -l 1472

Обмен пакетами с google.com [173.194.69.100] по 1472 байт:

Ответ от 173.194.69.100: число байт=64 (отправка 1472) время=68мс TTL=45
Ответ от 173.194.69.100: число байт=64 (отправка 1472) время=71мс TTL=45

Статистика Ping для 173.194.69.100:
   Пакетов: отправлено = 2, получено = 2, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
   Минимальное = 68мсек, Максимальное = 71 мсек, Среднее = 69 мсек
Control-C
^C
>

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Tosha   

Tosha
Опубликовано (изменено)

А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются.

 

А может иметь место несовместимость железа с фрагментацией ICMP пакетов?

Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам?

Изменено пользователем Tosha

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Ivan_83   

Ivan_83
Опубликовано

Все ответы на ваши пинги прилетают мне %)

 

 

 

ping google.com -l 1473

WARNING: probably, rcvbuf is not enough to hold preload.

PING google.com (173.194.69.102) 56(84) bytes of data.

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=5 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=4 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=1 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=2 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=7 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=10 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=12 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=8 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=3 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=9 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=11 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=6 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=13 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=15 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=17 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=16 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=14 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=18 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=19 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=21 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=24 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=26 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=25 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=28 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=72 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=76 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=82 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=71 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=62 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=84 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=86 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=85 ttl=49 time=139 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=27 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=20 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=23 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=22 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=33 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=40 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=32 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=34 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=39 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=38 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=46 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=35 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=48 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=31 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=45 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=29 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=53 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=43 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=42 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=47 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=41 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=37 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=30 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=54 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=49 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=50 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=55 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=44 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=59 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=58 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=51 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=56 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=52 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=60 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=57 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=61 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=36 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=69 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=67 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=64 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=74 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=65 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=68 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=63 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=70 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=79 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=75 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=78 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=73 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=80 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=66 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=77 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=83 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=81 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=88 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=89 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=91 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=92 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=87 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=90 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=95 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=99 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=93 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=94 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=96 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=98 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=103 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=97 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=106 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=102 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=105 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=107 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=100 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=101 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=104 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=117 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=112 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=115 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=120 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=108 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=118 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=111 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=114 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=119 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=116 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=110 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=113 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=109 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=121 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=125 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=124 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=127 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=131 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=134 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=123 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=130 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=132 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=126 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=135 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=128 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=129 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=122 ttl=49 time=141 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=133 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=136 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=139 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=137 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=143 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=138 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=147 ttl=49 time=141 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=198 ttl=49 time=141 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=217 ttl=49 time=141 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=239 ttl=49 time=142 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=303 ttl=49 time=142 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=321 ttl=49 time=142 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=345 ttl=49 time=143 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=362 ttl=49 time=143 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=393 ttl=49 time=143 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=400 ttl=49 time=144 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=428 ttl=49 time=144 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=435 ttl=49 time=144 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=461 ttl=49 time=144 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=488 ttl=49 time=145 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=539 ttl=49 time=145 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=587 ttl=49 time=145 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=618 ttl=49 time=145 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=633 ttl=49 time=146 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=653 ttl=49 time=146 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=665 ttl=49 time=146 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=676 ttl=49 time=147 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=710 ttl=49 time=147 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=749 ttl=49 time=147 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=760 ttl=49 time=147 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=786 ttl=49 time=148 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=793 ttl=49 time=148 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=790 ttl=49 time=148 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=809 ttl=49 time=149 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=828 ttl=49 time=139 ms

 

 

 

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=829 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=830 ttl=49 time=140 ms

64 bytes from bk-in-f102.1e100.net (173.194.69.102): icmp_req=831 ttl=49 time=140 ms

 

те мне сразу выплёвывает вон ту партянку, а чуть спустя идёт icmp_req=829.

хорошая штука для досеров %)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

sexst   

sexst
Опубликовано

А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются.

 

А может иметь место несовместимость железа с фрагментацией ICMP пакетов?

Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам?

Он мейлру пингует, а не железо провайдера, не?

Это нормально для ICMP.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

vitalyb   

vitalyb
Опубликовано

Все ответы на ваши пинги прилетают мне %)

 

 

ping google.com -l 1473

 

те мне сразу выплёвывает вон ту партянку, а чуть спустя идёт icmp_req=829.

хорошая штука для досеров %)

 

это потому, что -l в винде и никсах - немного разные вещи

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Tosha   

Tosha
Опубликовано

Он мейлру пингует, а не железо провайдера, не?

А черт знает что там на mail.ru...

Может аппаратный балансировщик и (или) защита от DDOS :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

HelgS   

HelgS
Опубликовано (изменено)

А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются.

 

А может иметь место несовместимость железа с фрагментацией ICMP пакетов?

Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам?

Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :)

Техподдержка говорит что у них везде Cisco. О намеренном ограничении фрагментированных ICMP пакетов не знают, передали заявку выше.

 

Он мейлру пингует, а не железо провайдера, не?

Это нормально для ICMP.

Без разницы пинговать mail.ru, другой хост или сеть провайдера. В любом направлении с/на клиента теряются фрагментированные ICMP.

 

А черт знает что там на mail.ru...

Может аппаратный балансировщик и (или) защита от DDOS :)

mail.ru был взят просто для примера, он отвечает на пинги размером до 16000 байт. У других (4) провайдеров потерь до mail.ru нет.

Изменено пользователем HelgS

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alex/AT   

Alex/AT
Опубликовано

Я понимаю, что тема исключительно гурманская - но зачем Вам в принципе fragmented ICMP? Если других проблем с сетью нет - можно спокойно класть с прибором на то, что оное не ходит.

А так - всё может быть очень просто: путь достаточно неоднородный, а фрагментированные пакеты на ряде железок обрабатываются не ASIC'ами, а CPU. Соответственно есть rate-limiting по сборке оных, и часть пакетов теряется.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

HelgS   

HelgS
Опубликовано

Я понимаю, что тема исключительно гурманская - но зачем Вам в принципе fragmented ICMP? Если других проблем с сетью нет - можно спокойно класть с прибором на то, что оное не ходит.

А так - всё может быть очень просто: путь достаточно неоднородный, а фрагментированные пакеты на ряде железок обрабатываются не ASIC'ами, а CPU. Соответственно есть rate-limiting по сборке оных, и часть пакетов теряется.

Кратко говоря "клиент" с которым мы должны беспрерывно обмениваться данными утверждает что у нас есть потери больших TCP пакетов на нашем канале. Показывая нам ping -l 2000 yourhostname в качестве доказательства. Клиента переубедили, но вопрос "почему так" интересен.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Ilya Evseev   

Ilya Evseev
Опубликовано

"клиент" с которым мы должны беспрерывно обмениваться данными утверждает

что у нас есть потери больших TCP пакетов на нашем канале.

Показывая нам ping -l 2000 yourhostname в качестве доказательства.

Клиента переубедили, но вопрос "почему так" интересен.

Используйте для диагностики tcptraceroute.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Tosha   

Tosha
Опубликовано

Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :)

ICMP протокол нужен для диагностики и отправки некоторых управляющих сообщений. Длина сообщений маленькая, штатно пакеты ICMP не фрагментируются. Фрагментированные пакеты ICMP нагружают процессор и классифицируются как DOS атака ;)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

HelgS   

HelgS
Опубликовано

Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :)

ICMP протокол нужен для диагностики и отправки некоторых управляющих сообщений. Длина сообщений маленькая, штатно пакеты ICMP не фрагментируются. Фрагментированные пакеты ICMP нагружают процессор и классифицируются как DOS атака ;)

Для диагностики всего кроме фрагментированных IP пакетов? ;)

Почему тогда провайдер устраивает фрагментированным ICMP дропнет 24/7 независимо от нагрузки, а не просто режет на входе от клиента и извне?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Ilya Evseev   

Ilya Evseev
Опубликовано

Для диагностики всего кроме фрагментированных IP пакетов? ;)

Для _начальной_ диагностики, а не для диагностики _всего_.

 

Почему тогда провайдер устраивает

Потому что он счёл это наиболее оптимальным.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

sio   

sio
Опубликовано

Как вариант, у провайдера, через которого теряются фрагментированные пинги, есть агрегированные линки с балансировкой per packet, на которых меняется порядок фрагментов. Нормальная железка, получив первый и третий фрагмент, посчитает пакет битым, а пришедший следом второй фрагмент сольёт в null.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alexandr Ovcharenko   

Alexandr Ovcharenko
Опубликовано

Во флуда-то развели.

Все банально. Я давно в одной из статей по безопасности читал такую вещь (ipfw freebsd):

add 1000 deny icmp from any to any frag

Во времена аплинков емкостью в сотни килобит - единицы мегабит фрагментированный пинг являлся инструментом досеров. Про такие шедевры, как сетевой стек Windows 98 я вообще промолчу.

 

Сейчас залез на свой сервер, глянул, а это правило в ipfw и ныне там. Рудимент. Нынче аплинки не сильно пингов боятся. Но с другой стороны - нехер! Пусть и дальше стоит.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

chocholl   

chocholl
Опубликовано

вы посмотрите, от вас пакеты уходят с DF или без.

Если без DF тогда все логично, железные роутеры не любят фрагментацией заниматься.

Если с DF, посмотрите по своей сети может DF где-то обнуляется.

ping умеет кстати слать и с DF и без, поэкспериментируйте.

 

 

Наблюдаю у одного из провайдеров потери фрагментированных ICMP пакетов. Это нормально для провайдера юриков?

Когда размер пакетов меньше или равен MTU - все хорошо:

PING mail.ru (94.100.191.203) 1472(1500) bytes of data.
1480 bytes from 94.100.191.203: icmp_req=1 ttl=56 time=61.2 ms
[skipped]
1480 bytes from 94.100.191.203: icmp_req=50 ttl=56 time=60.7 ms

--- mail.ru ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49064ms
rtt min/avg/max/mdev = 60.616/61.109/63.449/0.627 ms

 

Как только пакеты начинают фрагментироваться появляются существенные (40%-70%) потери:

PING mail.ru (94.100.191.203) 1473(1501) bytes of data.
1481 bytes from 94.100.191.203: icmp_req=1 ttl=55 time=61.1 ms
1481 bytes from 94.100.191.203: icmp_req=4 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=5 ttl=55 time=61.6 ms
1481 bytes from 94.100.191.203: icmp_req=6 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=7 ttl=55 time=61.1 ms
1481 bytes from 94.100.191.203: icmp_req=12 ttl=55 time=80.7 ms
1481 bytes from 94.100.191.203: icmp_req=17 ttl=55 time=61.0 ms
1481 bytes from 94.100.191.203: icmp_req=18 ttl=55 time=63.2 ms
1481 bytes from 94.100.191.203: icmp_req=21 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=22 ttl=55 time=86.6 ms
1481 bytes from 94.100.191.203: icmp_req=23 ttl=55 time=61.0 ms
1481 bytes from 94.100.191.203: icmp_req=26 ttl=55 time=61.3 ms
1481 bytes from 94.100.191.203: icmp_req=30 ttl=55 time=61.5 ms
1481 bytes from 94.100.191.203: icmp_req=34 ttl=55 time=61.2 ms
1481 bytes from 94.100.191.203: icmp_req=35 ttl=55 time=61.5 ms
1481 bytes from 94.100.191.203: icmp_req=41 ttl=55 time=61.3 ms
1481 bytes from 94.100.191.203: icmp_req=42 ttl=55 time=61.4 ms
1481 bytes from 94.100.191.203: icmp_req=43 ttl=55 time=61.0 ms
1481 bytes from 94.100.191.203: icmp_req=49 ttl=55 time=61.3 ms

--- mail.ru ping statistics ---
50 packets transmitted, 19 received, 62% packet loss, time 49209ms
rtt min/avg/max/mdev = 61.037/63.756/86.680/6.930 ms

 

С увеличением размера потери растут:

PING mail.ru (94.100.191.202) 1972(2000) bytes of data.
1980 bytes from 94.100.191.202: icmp_req=3 ttl=55 time=61.6 ms
1980 bytes from 94.100.191.202: icmp_req=18 ttl=55 time=61.3 ms
1980 bytes from 94.100.191.202: icmp_req=29 ttl=55 time=61.2 ms
1980 bytes from 94.100.191.202: icmp_req=30 ttl=55 time=62.8 ms
1980 bytes from 94.100.191.202: icmp_req=31 ttl=55 time=61.3 ms
1980 bytes from 94.100.191.202: icmp_req=42 ttl=55 time=61.3 ms
1980 bytes from 94.100.191.202: icmp_req=45 ttl=55 time=61.4 ms
1980 bytes from 94.100.191.202: icmp_req=46 ttl=55 time=61.5 ms
1980 bytes from 94.100.191.202: icmp_req=48 ttl=55 time=61.3 ms
--- mail.ru ping statistics ---
50 packets transmitted, 9 received, 82% packet loss, time 49109ms
rtt min/avg/max/mdev = 61.296/61.602/62.895/0.575 ms

PING mail.ru (94.100.191.201) 3972(4000) bytes of data.
3980 bytes from 94.100.191.201: icmp_req=1 ttl=55 time=67.3 ms
3980 bytes from 94.100.191.201: icmp_req=19 ttl=55 time=65.0 ms
3980 bytes from 94.100.191.201: icmp_req=23 ttl=55 time=65.2 ms
3980 bytes from 94.100.191.201: icmp_req=28 ttl=55 time=412 ms
3980 bytes from 94.100.191.201: icmp_req=29 ttl=55 time=65.6 ms
3980 bytes from 94.100.191.201: icmp_req=36 ttl=55 time=64.7 ms
3980 bytes from 94.100.191.201: icmp_req=37 ttl=55 time=65.1 ms
3980 bytes from 94.100.191.201: icmp_req=47 ttl=55 time=66.0 ms
3980 bytes from 94.100.191.201: icmp_req=48 ttl=55 time=66.1 ms
--- mail.ru ping statistics ---
50 packets transmitted, 9 received, 82% packet loss, time 49316ms
rtt min/avg/max/mdev = 64.744/104.229/412.830/109.109 ms


PING mail.ru (94.100.191.202) 5972(6000) bytes of data.
5980 bytes from 94.100.191.202: icmp_req=49 ttl=55 time=68.7 ms
--- mail.ru ping statistics ---
50 packets transmitted, 1 received, 98% packet loss, time 49000ms
rtt min/avg/max/mdev = 68.765/68.765/68.765/0.000 ms

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

HelgS   

HelgS
Опубликовано (изменено)

"Проблему" решили переключением нас на другой маршрутизатор. В чем причина странного поведения замененной циски пока неизвестно.

Провайдер намеренно для своих клиентов ICMP не фильтрует и не приоретизирует.

Изменено пользователем HelgS

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

nerik   

nerik
Опубликовано

Всем доброго дня. Тема актуальна.

Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет.

В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо)

Заранее спасибо.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

orlik   

orlik
Опубликовано

хз как у вас , а у нас все нормально , проверено на hetzner и Казахтелеком

 

$ ping -i 0.2 -q -c 100  -s 6000 mail.ru
PING mail.ru (94.100.180.199) 6000(6028) bytes of data.

--- mail.ru ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 21014ms
rtt min/avg/max/mdev = 55.653/55.993/56.437/0.357 ms

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

orlik   

orlik
Опубликовано

Всем доброго дня. Тема актуальна.

Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет.

В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо)

Заранее спасибо.

не умеет J балансить per packet , по крайней мере без сервис пиков.

per-packet - это на самом деле per-flow. Если per-flow не включен - то будет pre-prefix

 

Вот тут можно почитать http://juniper.cluepon.net/index.php/Load_Balancing

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

nnm   

nnm
Опубликовано

Всем доброго дня. Тема актуальна.

Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет.

В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо)

Заранее спасибо.

 

У Juniper действительно нет per-packet, но могут быть нюансы. Попробуйте исключить из хэша порты отправителя и получателя (опции no-destination-port и no-source-port в [edit forwarding-options enhanced-hash-key family inet]

Но я признаться не уверен, что причина потерь у Вашего клиента именно reordering фрагментов.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
Подписчики 0
Перейти к списку тем Активное оборудование Ethernet, IP, MPLS, SDN/NFV...