форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[ Отслеживать ]

"Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
Сообщение от boykov (ok) on 01-Ноя-07, 22:36
Свежеустановленная 6.0 (или приподнятая до 6.2 и ядро GENERIC, один пень). ipfw не подгружается. mtu стандартный, но и с меньшим -- нет разницы. делаем на хосте relay traceroute to ya.ru (213.180.204.8), 64 hops max, 2000 byte packets 1  * * * 2 xxxxxxxxxxx 3 xxxxxxxxxx 4 xxxxxxxxx 5  host198.telekom.ru (194.190.198.161)  45.726 ms  42.521 ms  45.377 ms 6  fe3-0-0-201.m9-1.M9.telekom.ru (194.190.198.201)  45.556 ms  47.176 ms  45.278 ms 7  * * * 8  ya.ru (213.180.204.8)  56.414 ms *  78.300 ms Первый хоп -- исследуемая система. На ней на интерфейсе tcpdump -ni bge0 "host relay and ((udp  and not port 53) or icmp)" 22:25:57.845600 IP relay.45850 > 213.180.204.8.33435: UDP, length 1972 22:25:57.845610 IP relay > 213.180.204.8: udp 22:25:57.845638 IP фряха > relay: ICMP time exceeded in-transit, length 36   <--!!! вообще непонятно!!! 22:26:02.848704 IP relay.45850 > 213.180.204.8.33436: UDP, length 1972 22:26:02.848714 IP relay > 213.180.204.8: udp 22:26:02.850921 IP хоп2 > relay: ICMP time exceeded in-transit, length 36 22:26:02.855472 IP relay.45850 > 213.180.204.8.33437: UDP, length 1972 22:26:02.855483 IP relay > 213.180.204.8: udp 22:26:02.858665 IP 194.190.198.181(хоп3) > relay: ICMP time exceeded in-transit, length 36 В то же время делаем на нее же пинг: relay# ping -s 20000 cc2 PING cc2.kolasc.net.ru (192.168.90.2): 20000 data bytes 20008 bytes from 192.168.90.2: icmp_seq=0 ttl=64 time=4.526 ms 20008 bytes from 192.168.90.2: icmp_seq=1 ttl=64 time=4.616 ms В 10 раз больше пролетает легко. Это что вообще может быть?
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
Сообщение от universite (ok) on 02-Ноя-07, 04:46
>Свежеустановленная 6.0 (или приподнятая до 6.2 и ядро GENERIC, один пень). >ipfw не подгружается. mtu стандартный, но и с меньшим -- нет разницы. >В 10 раз больше пролетает легко. >Это что вообще может быть? Понизьте MTU до 1400. Как только заработает пинг, увеличивайте размер MTU.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от boykov (ok) on 02-Ноя-07, 09:40
	>>Свежеустановленная 6.0 (или приподнятая до 6.2 и ядро GENERIC, один пень). >>ipfw не подгружается. mtu стандартный, но и с меньшим -- нет разницы. >>В 10 раз больше пролетает легко. >>Это что вообще может быть? > >Понизьте MTU до 1400. Как только заработает пинг, увеличивайте размер MTU. Звиняйте, но читать надо до конца... Пинги ходють, аж со свистом. Теперь по делу. Я вот что подумал. Отправленные на интерфейс icmp ответы  (третьи строчки tcpdump) есть, а на принимающей стороне (relay) -- звезда. Соединение между ними прямое. А вот с других хостов -- проходят, звезд нет. ipfw show: 00056       65       4084 allow icmp from me to any 00056        8        448 allow icmp from any to me 00095  2745463  392717106 allow ip from any to me 00097  3056905 1463857568 allow ip from me to any первые строки добавлены от нечего делать... Но толку нет все равно.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от magr (??) on 02-Ноя-07, 10:21
	>[оверквотинг удален] >ipfw show: >00056       65     >  4084 allow icmp from me to any >00056        8     >    448 allow icmp from any to me > >00095  2745463  392717106 allow ip from any to me >00097  3056905 1463857568 allow ip from me to any > >первые строки добавлены от нечего делать... Но толку нет все равно. А traceroute -P icmp такую же картину дает?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от boykov (ok) on 02-Ноя-07, 13:44
	>А traceroute -P icmp такую же картину дает? ага. на traceroute to ya.ru (213.180.204.8), 64 hops max, 2000 byte packets 1  * 2  хоп 2  2.818 ms в  дампе на фряхе 13:34:41.157067 IP relay > 213.180.204.8: ICMP echo request, id 53435, seq 1, length 1480 13:34:41.157078 IP relay > 213.180.204.8: icmp 13:34:41.157119 IP фряха > relay: ICMP time exceeded in-transit, length 36 13:34:46.158360 IP relay > 213.180.204.8: ICMP echo request, id 53435, seq 2, length 1480 13:34:46.158373 IP relay > 213.180.204.8: icmp 13:34:46.160306 IP хоп 2 > relay: ICMP time exceeded in-transit, length 36 То есть первые две строки -- фрагментированный пакет, третья -- ответ. Но ответ не доходит до адресата. И вся эта бодяга, если пакет фрагментируется. Если нет -- все оки. Вторая странность -- ответы на пинг того же размера -- легко. Скажите, me -- это точно _все_ адреса сервера? Я уж на алиасы начал грешить...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от magr (??) on 02-Ноя-07, 15:22
	>То есть первые две строки -- фрагментированный пакет, третья -- ответ. >Но ответ не доходит до адресата. если запустите tcpdump на хосте-инициаторе трассировки, то увидите что ответ ему доходит. А почему так реагирует (*) сам traceroute - ... ICMP time exceeded in-transit - это нормально, так отвечают промежуточные хопы. me -- это точно _все_ адреса сервера Если вы зададите для трейсроута размер пакета поменьше ([ packetlen ]), то у вас все должно работать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от boykov (ok) on 02-Ноя-07, 16:38
	>>То есть первые две строки -- фрагментированный пакет, третья -- ответ. >>Но ответ не доходит до адресата. > >если запустите tcpdump на хосте-инициаторе трассировки, то увидите что ответ ему доходит. >А почему так реагирует (*) сам traceroute - ... Вот: 16:20:28.912264 relay > ya.ru: icmp: echo request (frag 63896:1480@0+) [ttl 1] 16:20:28.912299 relay > ya.ru: icmp (frag 63896:500@1480) [ttl 1] 16:20:28.912787 cc2 > relay: icmp: time exceeded in-transit (frag 52031:36@0+) 16:20:33.913889 relay > ya.ru: icmp: echo request (frag 63897:1480@0+) 16:20:33.913923 relay > ya.ru: icmp (frag 63897:500@1480) 16:20:33.916491 hop2 > relay.kolasc.net.ru: icmp: time exceeded in-transit [tos 0xc0] 16:20:33.920480 relay.kolasc.net.ru > ya.ru: icmp: echo request (frag 63898:1480@0+) 16:20:33.920514 relay.kolasc.net.ru > ya.ru: icmp (frag 63898:500@1480) 16:20:33.923733 host198.telekom.ru > relay.kolasc.net.ru: icmp: time exceeded in-transit [tos 0xc0] 16:20:33.924475 host198.telekom.ru > relay.kolasc.net.ru: icmp: time exceeded in-transit [tos 0xc0] Угу. То есть трейс ждет подтверждений всех фрагментов, так получается? если собралась нужная кучка -- то все ОК? Однако не согласуется с вышеприведенным (где строго тройками идут блоки пакетов). > >ICMP time exceeded in-transit - это нормально, так отвечают промежуточные хопы. > Я в курсе :) >me -- это точно _все_ адреса сервера > >Если вы зададите для трейсроута размер пакета поменьше ([ packetlen ]), то >у вас все должно работать. ТАк не ради же трейса я это творю... Рвутся почтовые сессии, веротяно из-за потери пакетов :) Может дело в канале, может в моем рутере. Хочется исключить свой рутер (или найти в нем причину)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от universite (ok) on 02-Ноя-07, 21:42
	>>>То есть первые две строки -- фрагментированный пакет, третья -- ответ. >>>Но ответ не доходит до адресата. >> >>если запустите tcpdump на хосте-инициаторе трассировки, то увидите что ответ ему доходит. >>А почему так реагирует (*) сам traceroute - ... >ТАк не ради же трейса я это творю... Рвутся почтовые сессии, веротяно >из-за потери пакетов :) Может дело в канале, может в моем >рутере. Хочется исключить свой рутер (или найти в нем причину) Сетевую карту пробовали сменить?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от boykov (ok) on 04-Ноя-07, 18:51
	>>>>То есть первые две строки -- фрагментированный пакет, третья -- ответ. >>>>Но ответ не доходит до адресата. >>> >>>если запустите tcpdump на хосте-инициаторе трассировки, то увидите что ответ ему доходит. >>>А почему так реагирует (*) сам traceroute - ... >>ТАк не ради же трейса я это творю... Рвутся почтовые сессии, веротяно >>из-за потери пакетов :) Может дело в канале, может в моем >>рутере. Хочется исключить свой рутер (или найти в нем причину) > >Сетевую карту пробовали сменить? Угу. Да и длинные пинги по 20 000 байт не ходили бы по причине битой карты. Для доп инфомации -- это компаковская двухголовая гигабитная карта. Опознается как em
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
Сообщение от boykov (ok) on 06-Ноя-07, 19:48
Хорошо. Зайдем с другой стороны. Что такого должно произойти, чтобы traceroute (freebsd realisation) получив ответ тем не менее рисовал звезду. При длинных, то бишь фрагментированных, пакетах. Мое предположение -- эта штука считает отправленные фрагменты и количество ответов. Хотя есть резоны этому быть и не так. Знает кто точно?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Что такое в FreeBSD 6.x  может блокировать длинные пакеты?"		+/–
	Сообщение от TrEK (ok) on 26-Ноя-09, 10:51
	>Хорошо. Зайдем с другой стороны. >Что такого должно произойти, чтобы traceroute (freebsd realisation) получив ответ тем не >менее рисовал звезду. При длинных, то бишь фрагментированных, пакетах. > >Мое предположение -- эта штука считает отправленные фрагменты и количество ответов. Хотя >есть резоны этому быть и не так. >Знает кто точно? Решили проблемму? у меня похожая ситуация.. второй хоп дает ICMP-ureachable на запрашуемые сайты , это тсп-дам с шлюза через который проходят запросы в мир: 13:34:46.160306 IP хоп 2 > relay: ICMP time exceeded in-transit, length 36 вот более подробный лог: root@ubuntu:/home/trek# tcpdump -n  host 10.11.128.30 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:17:51.112429 IP 10.11.128.30 > 192.168.183.213: ICMP host 77.120.96.248 unreachable, length 36 15:17:51.253134 IP 10.11.128.30 > 194.188.189.218: ICMP host 81.222.128.12 unreachable, length 36 15:17:51.343677 IP 10.11.128.30 > 194.188.189.181: ICMP host 83.241.31.127 unreachable, length 36 15:17:51.360859 IP 10.11.128.30 > 192.168.183.213: ICMP host 213.180.204.91 unreachable, length 36 15:17:51.390612 IP 10.11.128.30 > 194.188.189.218: ICMP host 93.186.238.112 unreachable, length 36 за секунду проскакивает строк 20 таких.. от разных айпишек внутренней сети. и что я заметил, везде этот length 36. Что это означает... длинна пакета отправляемого клиентом, или такую длину формирует 10.11.128.30 при отправке ICMP ? root@ubuntu:/home/trek# tcpdump -v -n  host 10.11.128.30 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:23:41.738169 IP (tos 0x0, ttl 62, id 41740, offset 0, flags [DF], proto ICMP (1), length 56) 10.11.128.30 > 192.168.189.253: ICMP host 74.125.87.17 unreachable, length 36         IP (tos 0x0, ttl 124, id 15018, offset 0, flags [DF], proto TCP (6), length 252) 192.168.189.253.51871 > 74.125.87.17.443:  tcp 232 [bad hdr length 0 - too short, < 20] 15:23:42.199858 IP (tos 0x0, ttl 62, id 41744, offset 0, flags [DF], proto ICMP (1), length 56) 10.11.128.30 > 192.168.187.37: ICMP host 193.108.129.130 unreachable, length 36         IP (tos 0x10, ttl 60, id 1654, offset 0, flags [DF], proto TCP (6), length 126) 192.168.187.37.4049 > 193.108.129.130.8000:  tcp 106 [bad hdr length 0 - too short, < 20] 15:23:42.251346 IP (tos 0x0, ttl 62, id 41746, offset 0, flags [none], proto ICMP (1), length 56) 10.11.128.30 > 192.168.185.154: ICMP host 94.41.7.243 unreachable, length 36
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема