Jump to content
Калькуляторы

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

Наблюдаю у одного из провайдеров потери фрагментированных 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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

Edited by Tosha

Share this post


Link to post
Share on other sites

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

 

 

 

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.

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

 

ping google.com -l 1473

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

 

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

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

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

 

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

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

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

Edited by HelgS

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

add 1000 deny icmp from any to any frag

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

 

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

Share this post


Link to post
Share on other sites

вы посмотрите, от вас пакеты уходят с 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

Share this post


Link to post
Share on other sites

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

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

Edited by HelgS

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

хз как у вас , а у нас все нормально , проверено на 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

Share this post


Link to post
Share on other sites

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

Столкнулись с этой проблемой при настройке 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

Share this post


Link to post
Share on other sites

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

Столкнулись с этой проблемой при настройке 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 фрагментов.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this