forum.lissyara.su

Имееться 2 хоста freebsd 6.2-6.4 со связкой ipfw+natd периодически замечаю обрывы сессий сквозь нат. Тобишь выкачать с фтп изошку куском более 120-170 мег без докачки практически невозможно. Также дружно начинают жаловаться геймеры с одинаковым симптомом "рвет каждых 10-15-20 минут". На фоне этого пакетлоза нету - пускаем пинг подальше на несколько суток - максимум пара пакетов теряеться что считаю отличным показателем. Пока что на скорую руку поднял по несколько экземпляров natd на алиасах и свободных сетевухах и рассовываю туда дивертами особо чувствительный траффик типа всяких мморпг итд на которые более всего жалуються юзера. Но это естественно не вариант и конечно же плохо.

Среднестатистический load averages: 0.13, 0.23, 0.35 тобишь не зашкаливают как таковые, natd кудою ходит большинство траффика тоже в топе не проявляют чудес нагруженности. Ладно. Раньше списывал на здоровый поток (на каждом из хостов в среднем 20-30 мбит трафика при 300-500 юзерами за этим же натом) и славу natd(все понимаю, юзерспейс, переключение контекста итд..).

Все это можно было объяснить до того момента когда пришло время выносить на новый хост небольшой сегмент сети. Для начала переехало туда около сотни пользователей для долизывания нового биллинга, из них 20-30 постоянно онлайн (читай видим их деятельность в trafshow). Казалось бы все должно быть отлично хоть тут (юзеров немного, чистым интернетом там ходит 2-5 мбит/с, весь остальной траффик не существенен так как ходит не сквозь нат, да и его не много). Теперь сижу изумляюсь тому как даже при таких условиях докачать без докачки изошку (принял для себя как тест) более чем до 90-120 мег невозможно.

Гуглил - sysctl кручен во все стороны - абсолютно никакого видимого еффекта.
Теперь изгуглил весь гугл, обчитался много-много "умных советов" про "переходи на ipnat/ng_nat/pfnat - natd зло итд". Но практической возможности вот так вот просто "взять и перейти" на pfnat как минимум на одном из хостов допустим попросту нету - себестоимость такого перехода и сложность реализации в силу наличия клозедсорцного биллинга для одного из сегментов сети будет мягко говоря очень неприятной. Естественно что при скоростях выше 30-40 мбит/с я вижу единственный способ - заиметь АС и вообще отказаться от ната. Но это в ближайших перспективах. С другой стороны я просто не понимаю - что связка ipfw+natd не способна вытянуть 2-5 мбит живого траффика при 20-30 пользователях? Естественно способна, причем по заверениям умных людей конец ей приходит при тех же 35-40 мбитах потока. Итого вопрос - что я делаю не так? И в каком направлении следует порыть причину _внезапных_ дропов сессий?

пахнет хреновым аплинком
няшный natd работает как швейцарские часы, гарантирую :-)

пахнет хреновым аплинком

- отказываюсь верить

Без НАТа единичный виндовый хост воткнутый на прямую на сим аплинке с назначенной реальной айпишкой отлично льет на предельной скорости изошки любого размера ясно без обрывов. Кроме того няшные natd которые понаподнимались рядышком проблеме не подвержены практически - тудою тожно можно комфортно лить изошки

няшный natd работает как швейцарские часы, гарантирую :-)

Ну это зависит думаю от руконогости - в данном случае грешу на собственную. Только банально не понимаю где может быть подвох.

Посидел, мыслей воообще нету - изошки далее не качаються :\

Все конструктивно вроде, бы безупречно

cat /etc/rc.conf | grep default
defaultrouter="192.168.3.1"
#(читаем резервный канал)


NATD висят следующим образом:

/sbin/natd -u -p 8671 -a xxx.xxx.xxx.122 - основной канал
/sbin/natd -u -p 8673 -a 192.168.1.3 - все тот же основной канал но сквозь другой хост
/sbin/natd -u -p 8672 -a 192.168.3.5 - резервный канал


FwCMD="/sbin/ipfw -q"

${FwCMD} -f flush


# Networks define

# тут живут юзера
${FwCMD} table 2 add 172.90.0.0/21

# Это наши реальные и нереальные айпишки с сервисами
# к которым не будем натить
${FwCMD} table 9 add xxx.xxx.xxx.116
${FwCMD} table 9 add xxx.xxx.xxx.120
${FwCMD} table 9 add xxx.xxx.xxx.115
${FwCMD} table 9 add xxx.xxx.xxx.117
${FwCMD} table 9 add xxx.xxx.xxx.118
${FwCMD} table 9 add xxx.xxx.xxx.119
${FwCMD} table 9 add xxx.xxx.xxx.121
${FwCMD} table 9 add xxx.xxx.xxx.122
${FwCMD} table 9 add 192.168.0.0/24

#security
${FwCMD} add 101 allow all from 172.90.0.1 to any
${FwCMD} add 101 allow all from any to 172.90.0.1
${FwCMD} add 101 allow all from 172.16.0.1 to any
${FwCMD} add 101 allow all from any to 172.16.0.1
${FwCMD} add 102 deny all from table\(2\) to 192.168.0.0/24
${FwCMD} add 102 deny all from 192.168.0.0/24 to table\(2\)

# ну мы же хотим чтобы пользователи могли свою статистику проверить даже если денег нету
${FwCMD} add 103 allow all from table\(2\) to me dst-port 80
${FwCMD} add 103 allow all from table\(2\) to me dst-port 53
${FwCMD} add 104 deny all from table\(2\) to me dst-port 139
${FwCMD} add 104 deny all from me to table\(2\) dst-port 139


#internet natting and preserving

# Категория пользователей которые живут перманентно в резервном канале - table(5)
# - всякие спонсорские, и ультрадешевые промо-пакеты
${FwCMD} add 1700 divert 8672 ip from table\(5\) to not table\(9\) out via xl1

# в 8671 сворачиваеться весь траффик собственно к интернетам, в 1800 оное не попадает что логично

${FwCMD} add 1799 divert 8671 ip from table\(2\) to not table\(9\)

# если основной аплинк скончался просто убиваеться предыдущее правило и весь траффик из юзерской сети
# уходит в резервный канал (диверт 8672), также убиваеться форвард 1849 и обратный диверт 2099
${FwCMD} add 1800 divert 8672 ip from table\(2\) to not table\(9\) out via xl1

# прокидываем хост по которому от себя контролируем скриптом живость основного аплинка строго в него
${FwCMD} add 1847 fwd xxx.xxx.xxx.113 ip from me to 213.180.204.8

# далее идут форварды собственно куда надо
${FwCMD} add 1849 fwd xxx.xxx.xxx.113 ip from xxx.xxx.xxx.122 to not table\(9\)
${FwCMD} add 1850 fwd 192.168.3.1 ip from 192.168.3.5 to not table\(9\)
${FwCMD} add 1851 fwd 192.168.1.2 ip from 192.168.1.3 to not table\(9\)

# ... и обратные диверты
${FwCMD} add 2099 divert 8671 ip from any to xxx.xxx.xxx.122 in via xl0
${FwCMD} add 2100 divert 8672 ip from any to 192.168.3.5 in via xl1

..... вот здесь уже идут allow и шейпера к table(2) ......

${FwCMD} add 65533 deny all from table\(2\) to any
${FwCMD} add 65534 deny all from any to table\(2\)
${FwCMD} add 65535 allow all from any to any

Вопрос знатокам: что я делаю не так?

natd использовал как стартовый опыт, pfnat, ngnat, ipfw nat ^__^

а чем именно natd так критичен? если ОС 7.х - можно попробовать nat , который в ядре уже...
переделывать особо ничего не нужно...теже таблицы, тот же аля диверт на нат...

pf ng... так и не прочитали почему этого не будет даже в теории. Разве что на органы пол колектива продать чтобы это окупилось.

Нет не 7, переустановка продакшн серверов тоже не рассматриваеться как возможная. Вобще не вижу смысла в замене ната под небольшими нагрузками.

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

ну у меня с натд тоже приколы, из-за долгой работы переполняется место в /var

Вобще не вижу связи переполнения места в var и natd. Поубирать нафиг log со всех рулесов не пробывали?

ПС ах да еще ж вербоуз лимит

ну как бы траблу решал довольно таки долго. НАТ держит файл, который удален. его реально нет, а место занимает.
тут именно с НАТом дело

sysctl.conf ничего не ставил, скорее всего там рубит

после рестарта ната, все становится на свои места

#lsof | grep natd | grep var
#

даже не осмеливаюсь предположить какие же он у вас логи там пишет

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

кто мешает для тестов прописать одну строку ната
и заюзать ipnat,pfnat
дабы понять где проблема
?
а потом уже думать

потому как

"рвет каждых 10-15-20 минут".

настораживает что это проблема где то вне сервера
кабель, провайдер итд

кто мешает для тестов прописать одну строку ната

собственно подымается еще один нат на алиасе(вверху реализация), сворачиваеться туда единичного пользователя (допустим меня) и все летает отлично.

настораживает что это проблема где то вне сервера

физиологические проблемы и провайдер исключены так как если паралельно воткнуть еще один хост - на нем тоже работает все отлично, строим на этом хосте нат по аналогичному методу - ну как минимум для одного пользователя тобишь меня - все тоже отлично. Естественно это все на фоне стоящих рядышком двух хостов на которых методично обрываються сессии.

собственно подымается еще один нат на алиасе(вверху реализация), сворачиваеться туда единичного пользователя (допустим меня) и все летает отлично

предлагаю попробовать pfnat
с одним правилом
токо не на одного пользователя
а на всех
в конфигурации когда рветься tcp сессия у natd
и тогда станет ясно хотя бы куда копать

вариант
попробовать ядреный natd

это вы серьезно про переход на pf?

я про те 4 мбит потока которые сейчас на втором хосте при активных на данный момент 6 пользователях + моем тестовом аккаунте?

Не могу ниразу назвать это пределом natd

# ps aux | grep natd
root 649 1.0 0.3 11636 11036 ?? Rs 31May09 380:42.16 /sbin/natd -u -p 8671 -a ххх.ххх.ххх.122
root 651 0.0 0.1 3556 2948 ?? Ss 31May09 3:59.51 /sbin/natd -u -p 8672 -a 192.168.3.5
root 653 0.0 0.0 1704 1092 ?? Ss 31May09 46:41.51 /sbin/natd -u -p 8673 -a 192.168.1.3

тем более учитывая ночной тест какраз на разгруженном хосте когда закачка шириной в 256к тянулась всего от одного пользователя.

я не говорил про пределы и про переход
я сказал что вам нужно локализовать проблему
поскоку вы щас даже приблизительно незнаете где проблема - так?
вот и поеспериментируйте
если будет глючить на всех pfnat и ipnat
тогда и будет смотреть дальше

поскоку вы щас даже приблизительно незнаете где проблема - так?

в конкретном экземпляре natd, которым ломиться весь траффик, причем идентично на двух разных хостах с совершенно разной нагрузкой.

можно далеко не ходить - думаю образцово поднятый еще один natd ликвидирующий на себе проблему говорит что рыть следует таки в сторону natd а не сетевух (em/xl/fxp кстати всюду) итд.


Еще с более веселым выражением лица представил себе приостановку 2 продакшн серверов на период "пересобрать ядро/переписать 2 разных биллинга один из которых без сорцов и намертво прибит гвоздями к ipfw/поиграться (а вдруг получиться)" лично этого "попробовать просто так" я себе не представляю.

pf.ko и ipf.ko
в пересборки ядра не нуждаються
это к примеру

но насчет ядреного natd
это уж вам виднее

ipfw add 1796 divert 8673 tcp from any to any dst-port 80

вот и чудо - качнул без обрывов и проблем изошку фри по хттп на скорости 20-25 мбит

Идей вообще никаких, канал тот же, юзера все теже, просто диверт соседний.
Хотя всеже есть идея относительно количества сессий, а как можно нежно ограничить их для table(2)?

http://subnets.ru/blog/?tag=ng_nat рекомендую! или ipfw nat

люблю повторяться:

вот так вот просто "взять и перейти" на pfnat как минимум на одном из хостов допустим попросту нету - себестоимость такого перехода и сложность реализации в силу наличия клозедсорцного биллинга для одного из сегментов сети будет мягко говоря очень неприятной.

я тоже могу взять и порекомендовать пятициферную циску и автономку /21 - в чем проблема?

локализуй проблему на своем сервере
а не повторяя такие же операции на других серверах

Что значит на "своем"? Если имееться в виду тестовая машина повторяющая набор сервисов и конфигурацию продакшнов так - давно уже. Проблемы там нет так каковой думаю изза отсутствия живых пользователей за спиной.

Чем можно посмотреть общее количество активных tcp сессий висящих сквозь nat и количество активных/wait сессий от каждого пользователя в частности?