HelgS Опубликовано 20 марта, 2012 · Жалоба Наблюдаю у одного из провайдеров потери фрагментированных 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 20 марта, 2012 · Жалоба оО думал у меня только. >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 > Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 21 марта, 2012 (изменено) · Жалоба А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются. А может иметь место несовместимость железа с фрагментацией ICMP пакетов? Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам? Изменено 21 марта, 2012 пользователем Tosha Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 марта, 2012 · Жалоба Все ответы на ваши пинги прилетают мне %) 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. хорошая штука для досеров %) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 21 марта, 2012 · Жалоба А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются. А может иметь место несовместимость железа с фрагментацией ICMP пакетов? Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам? Он мейлру пингует, а не железо провайдера, не? Это нормально для ICMP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 21 марта, 2012 · Жалоба Все ответы на ваши пинги прилетают мне %) ping google.com -l 1473 те мне сразу выплёвывает вон ту партянку, а чуть спустя идёт icmp_req=829. хорошая штука для досеров %) это потому, что -l в винде и никсах - немного разные вещи Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 22 марта, 2012 · Жалоба Он мейлру пингует, а не железо провайдера, не? А черт знает что там на mail.ru... Может аппаратный балансировщик и (или) защита от DDOS :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HelgS Опубликовано 25 марта, 2012 (изменено) · Жалоба А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются. А может иметь место несовместимость железа с фрагментацией ICMP пакетов? Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам? Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :) Техподдержка говорит что у них везде Cisco. О намеренном ограничении фрагментированных ICMP пакетов не знают, передали заявку выше. Он мейлру пингует, а не железо провайдера, не? Это нормально для ICMP. Без разницы пинговать mail.ru, другой хост или сеть провайдера. В любом направлении с/на клиента теряются фрагментированные ICMP. А черт знает что там на mail.ru... Может аппаратный балансировщик и (или) защита от DDOS :) mail.ru был взят просто для примера, он отвечает на пинги размером до 16000 байт. У других (4) провайдеров потерь до mail.ru нет. Изменено 25 марта, 2012 пользователем HelgS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 25 марта, 2012 · Жалоба Я понимаю, что тема исключительно гурманская - но зачем Вам в принципе fragmented ICMP? Если других проблем с сетью нет - можно спокойно класть с прибором на то, что оное не ходит. А так - всё может быть очень просто: путь достаточно неоднородный, а фрагментированные пакеты на ряде железок обрабатываются не ASIC'ами, а CPU. Соответственно есть rate-limiting по сборке оных, и часть пакетов теряется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HelgS Опубликовано 26 марта, 2012 · Жалоба Я понимаю, что тема исключительно гурманская - но зачем Вам в принципе fragmented ICMP? Если других проблем с сетью нет - можно спокойно класть с прибором на то, что оное не ходит. А так - всё может быть очень просто: путь достаточно неоднородный, а фрагментированные пакеты на ряде железок обрабатываются не ASIC'ами, а CPU. Соответственно есть rate-limiting по сборке оных, и часть пакетов теряется. Кратко говоря "клиент" с которым мы должны беспрерывно обмениваться данными утверждает что у нас есть потери больших TCP пакетов на нашем канале. Показывая нам ping -l 2000 yourhostname в качестве доказательства. Клиента переубедили, но вопрос "почему так" интересен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 26 марта, 2012 · Жалоба "клиент" с которым мы должны беспрерывно обмениваться данными утверждает что у нас есть потери больших TCP пакетов на нашем канале. Показывая нам ping -l 2000 yourhostname в качестве доказательства. Клиента переубедили, но вопрос "почему так" интересен. Используйте для диагностики tcptraceroute. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tosha Опубликовано 26 марта, 2012 · Жалоба Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :) ICMP протокол нужен для диагностики и отправки некоторых управляющих сообщений. Длина сообщений маленькая, штатно пакеты ICMP не фрагментируются. Фрагментированные пакеты ICMP нагружают процессор и классифицируются как DOS атака ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HelgS Опубликовано 26 марта, 2012 · Жалоба Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :) ICMP протокол нужен для диагностики и отправки некоторых управляющих сообщений. Длина сообщений маленькая, штатно пакеты ICMP не фрагментируются. Фрагментированные пакеты ICMP нагружают процессор и классифицируются как DOS атака ;) Для диагностики всего кроме фрагментированных IP пакетов? ;) Почему тогда провайдер устраивает фрагментированным ICMP дропнет 24/7 независимо от нагрузки, а не просто режет на входе от клиента и извне? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 26 марта, 2012 · Жалоба Для диагностики всего кроме фрагментированных IP пакетов? ;) Для _начальной_ диагностики, а не для диагностики _всего_. Почему тогда провайдер устраивает Потому что он счёл это наиболее оптимальным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sio Опубликовано 26 марта, 2012 · Жалоба Как вариант, у провайдера, через которого теряются фрагментированные пинги, есть агрегированные линки с балансировкой per packet, на которых меняется порядок фрагментов. Нормальная железка, получив первый и третий фрагмент, посчитает пакет битым, а пришедший следом второй фрагмент сольёт в null. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 26 марта, 2012 · Жалоба Во флуда-то развели. Все банально. Я давно в одной из статей по безопасности читал такую вещь (ipfw freebsd): add 1000 deny icmp from any to any frag Во времена аплинков емкостью в сотни килобит - единицы мегабит фрагментированный пинг являлся инструментом досеров. Про такие шедевры, как сетевой стек Windows 98 я вообще промолчу. Сейчас залез на свой сервер, глянул, а это правило в ipfw и ныне там. Рудимент. Нынче аплинки не сильно пингов боятся. Но с другой стороны - нехер! Пусть и дальше стоит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chocholl Опубликовано 27 марта, 2012 · Жалоба вы посмотрите, от вас пакеты уходят с 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HelgS Опубликовано 3 апреля, 2012 (изменено) · Жалоба "Проблему" решили переключением нас на другой маршрутизатор. В чем причина странного поведения замененной циски пока неизвестно. Провайдер намеренно для своих клиентов ICMP не фильтрует и не приоретизирует. Изменено 3 апреля, 2012 пользователем HelgS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nerik Опубликовано 18 ноября, 2013 · Жалоба Всем доброго дня. Тема актуальна. Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет. В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо) Заранее спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 18 ноября, 2013 · Жалоба хз как у вас , а у нас все нормально , проверено на 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
orlik Опубликовано 18 ноября, 2013 · Жалоба Всем доброго дня. Тема актуальна. Столкнулись с этой проблемой при настройке 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nnm Опубликовано 18 ноября, 2013 · Жалоба Всем доброго дня. Тема актуальна. Столкнулись с этой проблемой при настройке 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 фрагментов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...