HelgS Posted March 20, 2012 Posted March 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 Вставить ник Quote
Megas Posted March 20, 2012 Posted March 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 > Вставить ник Quote
Tosha Posted March 21, 2012 Posted March 21, 2012 (edited) А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются. А может иметь место несовместимость железа с фрагментацией ICMP пакетов? Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам? Edited March 21, 2012 by Tosha Вставить ник Quote
Ivan_83 Posted March 21, 2012 Posted March 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. хорошая штука для досеров %) Вставить ник Quote
sexst Posted March 21, 2012 Posted March 21, 2012 А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются. А может иметь место несовместимость железа с фрагментацией ICMP пакетов? Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам? Он мейлру пингует, а не железо провайдера, не? Это нормально для ICMP. Вставить ник Quote
vitalyb Posted March 21, 2012 Posted March 21, 2012 Все ответы на ваши пинги прилетают мне %) ping google.com -l 1473 те мне сразу выплёвывает вон ту партянку, а чуть спустя идёт icmp_req=829. хорошая штука для досеров %) это потому, что -l в винде и никсах - немного разные вещи Вставить ник Quote
Tosha Posted March 22, 2012 Posted March 22, 2012 Он мейлру пингует, а не железо провайдера, не? А черт знает что там на mail.ru... Может аппаратный балансировщик и (или) защита от DDOS :) Вставить ник Quote
HelgS Posted March 25, 2012 Author Posted March 25, 2012 (edited) А зачем слать толстые ICMP пакеты? Это же глубоко искусcтвенный тест. В жизни большие ICMP пакеты не встречаются. А может иметь место несовместимость железа с фрагментацией ICMP пакетов? Сделали ASIC ответов и генерации сообщений ICMP но не предусмотрели что эти пакеты надо еще собирать по фрагментам? Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :) Техподдержка говорит что у них везде Cisco. О намеренном ограничении фрагментированных ICMP пакетов не знают, передали заявку выше. Он мейлру пингует, а не железо провайдера, не? Это нормально для ICMP. Без разницы пинговать mail.ru, другой хост или сеть провайдера. В любом направлении с/на клиента теряются фрагментированные ICMP. А черт знает что там на mail.ru... Может аппаратный балансировщик и (или) защита от DDOS :) mail.ru был взят просто для примера, он отвечает на пинги размером до 16000 байт. У других (4) провайдеров потерь до mail.ru нет. Edited March 25, 2012 by HelgS Вставить ник Quote
Alex/AT Posted March 25, 2012 Posted March 25, 2012 Я понимаю, что тема исключительно гурманская - но зачем Вам в принципе fragmented ICMP? Если других проблем с сетью нет - можно спокойно класть с прибором на то, что оное не ходит. А так - всё может быть очень просто: путь достаточно неоднородный, а фрагментированные пакеты на ряде железок обрабатываются не ASIC'ами, а CPU. Соответственно есть rate-limiting по сборке оных, и часть пакетов теряется. Вставить ник Quote
HelgS Posted March 26, 2012 Author Posted March 26, 2012 Я понимаю, что тема исключительно гурманская - но зачем Вам в принципе fragmented ICMP? Если других проблем с сетью нет - можно спокойно класть с прибором на то, что оное не ходит. А так - всё может быть очень просто: путь достаточно неоднородный, а фрагментированные пакеты на ряде железок обрабатываются не ASIC'ами, а CPU. Соответственно есть rate-limiting по сборке оных, и часть пакетов теряется. Кратко говоря "клиент" с которым мы должны беспрерывно обмениваться данными утверждает что у нас есть потери больших TCP пакетов на нашем канале. Показывая нам ping -l 2000 yourhostname в качестве доказательства. Клиента переубедили, но вопрос "почему так" интересен. Вставить ник Quote
Ilya Evseev Posted March 26, 2012 Posted March 26, 2012 "клиент" с которым мы должны беспрерывно обмениваться данными утверждает что у нас есть потери больших TCP пакетов на нашем канале. Показывая нам ping -l 2000 yourhostname в качестве доказательства. Клиента переубедили, но вопрос "почему так" интересен. Используйте для диагностики tcptraceroute. Вставить ник Quote
Tosha Posted March 26, 2012 Posted March 26, 2012 Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :) ICMP протокол нужен для диагностики и отправки некоторых управляющих сообщений. Длина сообщений маленькая, штатно пакеты ICMP не фрагментируются. Фрагментированные пакеты ICMP нагружают процессор и классифицируются как DOS атака ;) Вставить ник Quote
HelgS Posted March 26, 2012 Author Posted March 26, 2012 Зачем тогда вообще нужен ICMP протокол? Он же при передаче данных не нужен. :) ICMP протокол нужен для диагностики и отправки некоторых управляющих сообщений. Длина сообщений маленькая, штатно пакеты ICMP не фрагментируются. Фрагментированные пакеты ICMP нагружают процессор и классифицируются как DOS атака ;) Для диагностики всего кроме фрагментированных IP пакетов? ;) Почему тогда провайдер устраивает фрагментированным ICMP дропнет 24/7 независимо от нагрузки, а не просто режет на входе от клиента и извне? Вставить ник Quote
Ilya Evseev Posted March 26, 2012 Posted March 26, 2012 Для диагностики всего кроме фрагментированных IP пакетов? ;) Для _начальной_ диагностики, а не для диагностики _всего_. Почему тогда провайдер устраивает Потому что он счёл это наиболее оптимальным. Вставить ник Quote
sio Posted March 26, 2012 Posted March 26, 2012 Как вариант, у провайдера, через которого теряются фрагментированные пинги, есть агрегированные линки с балансировкой per packet, на которых меняется порядок фрагментов. Нормальная железка, получив первый и третий фрагмент, посчитает пакет битым, а пришедший следом второй фрагмент сольёт в null. Вставить ник Quote
Alexandr Ovcharenko Posted March 26, 2012 Posted March 26, 2012 Во флуда-то развели. Все банально. Я давно в одной из статей по безопасности читал такую вещь (ipfw freebsd): add 1000 deny icmp from any to any frag Во времена аплинков емкостью в сотни килобит - единицы мегабит фрагментированный пинг являлся инструментом досеров. Про такие шедевры, как сетевой стек Windows 98 я вообще промолчу. Сейчас залез на свой сервер, глянул, а это правило в ipfw и ныне там. Рудимент. Нынче аплинки не сильно пингов боятся. Но с другой стороны - нехер! Пусть и дальше стоит. Вставить ник Quote
chocholl Posted March 27, 2012 Posted March 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 Вставить ник Quote
HelgS Posted April 3, 2012 Author Posted April 3, 2012 (edited) "Проблему" решили переключением нас на другой маршрутизатор. В чем причина странного поведения замененной циски пока неизвестно. Провайдер намеренно для своих клиентов ICMP не фильтрует и не приоретизирует. Edited April 3, 2012 by HelgS Вставить ник Quote
nerik Posted November 18, 2013 Posted November 18, 2013 Всем доброго дня. Тема актуальна. Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет. В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо) Заранее спасибо. Вставить ник Quote
orlik Posted November 18, 2013 Posted November 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 Вставить ник Quote
orlik Posted November 18, 2013 Posted November 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 Вставить ник Quote
nnm Posted November 18, 2013 Posted November 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 фрагментов. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.