Ситуация такова: рабочая станция на Gentoo Linux (base system 1.2.9), шлюз на FreeBSD 6.2+pf (на pf только NAT, ничего больше). При пинге любого удаленного хоста (или даже внешнего интерфейса шлюза) периодически (один раз из 5-6) "зависает" первый пакет, в итоге теряется, остальные бегают нормально. Также невозможна трассировка UDP пакетами ( ICMP при этом проходят на "ура") - пакеты не уходят дальше шлюза.
В сети есть еще станции на Debian, Mandriva, WinXP - там такого не наблюдается.
Подскажите, куда копать?

• Gentoo+шлюз на FreeBSD - проблемы,leave, 16:48 , 31-Июл-07
  • Gentoo+шлюз на FreeBSD - проблемы,Den, 17:09 , 31-Июл-07
    • Gentoo+шлюз на FreeBSD - проблемы,leave, 17:12 , 31-Июл-07
      • Gentoo+шлюз на FreeBSD - проблемы,Den, 17:17 , 31-Июл-07
        • Gentoo+шлюз на FreeBSD - проблемы,leave, 17:42 , 31-Июл-07
• Gentoo+шлюз на FreeBSD - проблемы,Paul, 17:32 , 31-Июл-07
  • Gentoo+шлюз на FreeBSD - проблемы,leave, 17:40 , 31-Июл-07
    • Gentoo+шлюз на FreeBSD - проблемы,Den, 17:46 , 31-Июл-07
    • Gentoo+шлюз на FreeBSD - проблемы,Paul, 18:41 , 31-Июл-07
      • Gentoo+шлюз на FreeBSD - проблемы,leave, 18:54 , 31-Июл-07
        • Gentoo+шлюз на FreeBSD - проблемы,Paul, 19:04 , 31-Июл-07
        • Gentoo+шлюз на FreeBSD - проблемы,Paul, 19:21 , 31-Июл-07
          • Gentoo+шлюз на FreeBSD - проблемы,leave, 19:40 , 31-Июл-07

вдогонку - pf.conf

ext_if="rl0"
internal_net="192.168.155.0/24"
internal_net2="192.168.15.0/24"
scrub in all
scrub out all
nat on $ext_if from $internal_net to any -> ($ext_if)
nat on $ext_if from $internal_net2 to any -> ($ext_if)
pass in all
pass out all
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state

>[оверквотинг удален]
>ext_if="rl0"
>internal_net="192.168.155.0/24"
>internal_net2="192.168.15.0/24"
>scrub in all
>scrub out all
>nat on $ext_if from $internal_net to any -> ($ext_if)
>nat on $ext_if from $internal_net2 to any -> ($ext_if)
>pass in all
>pass out all
>pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state

может трабла с dns, сразу тратится время на резолвинг ?

>может трабла с dns, сразу тратится время на резолвинг ?

на это можно было бы грешить если бы проблема была у меня одного, и если бы описанная ситуация возникала только при пинге по домену. но разницы, что пинговать - домен или айпишник нету. и к чему тогда грабли с traceroute?

>
>>может трабла с dns, сразу тратится время на резолвинг ?
>
>на это можно было бы грешить если бы проблема была у меня
>одного, и если бы описанная ситуация возникала только при пинге по
>домену. но разницы, что пинговать - домен или айпишник нету. и
>к чему тогда грабли с traceroute?

временно отключи нат, установи реальники на freebsd и gentoo и проверь в чистом роутинге?
Если проблем нету значит криво работает pf

>временно отключи нат, установи реальники на freebsd и gentoo и проверь в
>чистом роутинге?
>Если проблем нету значит криво работает pf

отключал, проблем не было. значит криво работает pf. только почему трабла наблюдается исключительно с Гентой? вопрос спорный - кто виноват. с тем же Дебианом все всегда работает отлично. а мне пришлось заалиасить traceroute на traceroute -I :)

А при пинге внутреннего интерфейса шлюза наблюдается?

>А при пинге внутреннего интерфейса шлюза наблюдается?

нет. оно и на внешним-то не всегда бывает, но на внутреннем - никогда.

>>А при пинге внутреннего интерфейса шлюза наблюдается?
>
>нет. оно и на внешним-то не всегда бывает, но на внутреннем -
>никогда.

сам сейчас сижу за gentoo'ой и шлюз на freebsd + pf = проблем не наблюдаю.
Попробуйте проанализировать tcpdump'ом и отловить пакет который дропается на внешнем интерфейсе.

Но раз Вы говорите, что при пинге внутреннего интерфейса проблем не наблюдается, значит проблема в pf. И нужно копать в его сторону

>>А при пинге внутреннего интерфейса шлюза наблюдается?
>
>нет. оно и на внешним-то не всегда бывает, но на внутреннем -
>никогда.

Очень похоже на системную проблему, так как дропается именно первый пакет и с определенной периодичностью, таким образом могу предположить три причины:

1. Работает какой-то демон динамической маршрутизации на bsd. Можно попробовать его выловить.
2. Иногда бывают потери пакетов в процессе согласования скорости обмена между сетевой картой и коммутатором. Можно попробовать задать скорости на портах жестко.
3. Если есть какой-то VPN с шифрованием между интерфейсом bsd и внешним миром, то может быть из-за согласования ключей шифрования в IPSEC.

--
www.ppokrovsky.org

>Очень похоже на системную проблему, так как дропается именно первый пакет и
>с определенной периодичностью, таким образом могу предположить три причины:
>
>1. Работает какой-то демон динамической маршрутизации на bsd. Можно попробовать его выловить.
>
>2. Иногда бывают потери пакетов в процессе согласования скорости обмена между сетевой
>картой и коммутатором. Можно попробовать задать скорости на портах жестко.
>3. Если есть какой-то VPN с шифрованием между интерфейсом bsd и внешним
>миром, то может быть из-за согласования ключей шифрования в IPSEC.

3 - точно нет
2 - на портах свича? наш офисный шуреком на такое не способен ((
1 - тоже нет, роуты прописаны статично на следующий за нами шлюз, который уже и выпускает непосредственно в инет.

>3 - точно нет
>2 - на портах свича? наш офисный шуреком на такое не способен
>((
>1 - тоже нет, роуты прописаны статично на следующий за нами шлюз,
>который уже и выпускает непосредственно в инет.

ну если наблюдается только для gentoo могу еще предположить, что проблема где-то также в стеке gentoo, иногда (довольно редко, но все же) такой трабл наблюдается из-за фрагментации пакетов, в этом случае надо поиграться с MTU. Попробуйте правда сниффером на шлюзе (на обоих интерфейсах) послушать на предмет need_frag.

--
http://www.ppokrovsky.org

>[оверквотинг удален]
>>2. Иногда бывают потери пакетов в процессе согласования скорости обмена между сетевой
>>картой и коммутатором. Можно попробовать задать скорости на портах жестко.
>>3. Если есть какой-то VPN с шифрованием между интерфейсом bsd и внешним
>>миром, то может быть из-за согласования ключей шифрования в IPSEC.
>
>3 - точно нет
>2 - на портах свича? наш офисный шуреком на такое не способен
>((
>1 - тоже нет, роуты прописаны статично на следующий за нами шлюз,
>который уже и выпускает непосредственно в инет.

Кстати вот еще проблема, очень похожая на описанную Вами.
http://archives.neohapsis.com/archives/openbsd/2007-07/0430....
Речь о каком-то баге в pf. Может быть в этом дело. Но опять же лучше отснифферить и посмотреть дамп в ethereal, чтобы убедиться наверняка.

--
http://www.ppokrovsky.org

>Кстати вот еще проблема, очень похожая на описанную Вами.
>http://archives.neohapsis.com/archives/openbsd/2007-07/0430....
>Речь о каком-то баге в pf. Может быть в этом дело. Но
>опять же лучше отснифферить и посмотреть дамп в ethereal, чтобы убедиться
>наверняка.
>
>--
>http://www.ppokrovsky.org

кстати, очень похоже. спасибо за помощь, поснифим завтра ночью.