nshut

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

а ошибок может и не быть на коммутаторе, один битый немного патч может такие выкрутасы делать (( причем только под нагрузкой я бы первым делом попробовал обменять настройки em1 и em0 сетевые идентичные, замена конфигов дело 3х минут и в ребут (конечно если патчи есть возможность передернуть, заменить где ошибки и поменять местами если в конфигах поменяете ) также посмотрите на статистику буферов, смущает missed packets

и от себя добавлю. Есть люди теоретики, есть практики. Теоретики читают кучу инфы, потом виртуальные машины и т.д., практики ставят на реальное железо и начинают. Изучение фри и линуха думаю быстрей когда как выше сказано решается цель. Выпустите себя в интернет через нат, а потом через него же телевизор и айфон. начинаем, ставим фрю/линух, забиваем в гугле как присвоить айпи. ну а далее по задачам: маршрутизация, нат. увы сколько не ставил систем для десктопа, больше трех дней не жили. тупо лазить по каталогам и смотреть список файлов не очень интересно.

всем устраивает до сих пор. - есть один сервер интел с железом рэйд который 8ка не держит. точнее чтото с дровами, теряются кластеры. я программер но копать дрова сказевые нет времени. - также хочу сравнить производительность паралельных систем, т.к. все здесь яро кричат что 9ка пилина перепилена в плане сети, а выбор производительного роутера у меня сейчас главная задача - у меня не заводится лагг порты на i350-t4, пока в чем причина не разобрался, думал глянуть на девятке, грубо говоря это был первый тест но до него не дошел. точнее заводится но каждые 20сек задержки идут. Показатели всех очередей в норме. ну и потрогать другую ось. я просто на самом деле в недоумении как можно релиз стеблом назвать тем более 9.1 если есть такие глюки. ну и надо же комуто тестировать ОСь, ведь почему то люди забывают о 4-7 версиях бсди п.с. вообще походив по баг репортам, и посмотрев решения open, а также время открытия. Похоже freebsd поддержка ложится на самих пользователей :) такчто либо лезем в код c++, а я так и остаюсь на восьмерке

- ядро пересоберу без этой опции как только сервер новый придет, я уже замучил юзеров ребутами, так что пока на паузе - буферов тоже сейчас не погляжу, винт отключен. но он полная копия конфигов с 8ки, т.е. sysctl, rc.conf, pf, ipfw а на 8ке точно всего хватает. отписался в один мэйллист ссылка вообще судя по поиску в интернете проблема очень актуальная. но я видимо единственный у кого маршруты слетают чаще чем в раз в день. А так пользователи пишут скрипты, наблюдают и возвращают на место. Тему продолжу как придет сервер. посмотрю на буфера, попробую отключить pf , ipfw и т.д. там дальше думать буду. хотя глаз уже косится на debian nat

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

добрался до винта с 9кой, вот что в логе Apr 5 20:37:15 gw kernel: pf: state key linking mismatch! dir=OUT, if=igb0, stored af=2, a0: 172.24.49.75:26167, a1: 93.77.135.82:46401, proto=17, found af=2, a0: 172.24.70.30:50699, a1: 94.20.68.43:11789, proto=6. Apr 5 20:37:17 gw kernel: arpresolve: can't allocate llinfo for 5.9.99.11 Apr 5 20:37:17 gw last message repeated 158 times Apr 5 20:37:17 gw kernel: allocate llinfo for 5.9.99.11 Apr 5 20:37:17 gw kernel: arpresolve: can't allocate llinfo for 5.9.99.11 увы ответов в интернете на эти ошибки не нашел, кроме того, чтоб не обращали внимания. да уж, каждые пять минут слетают маршруты маршрутизатора и это не баг :) похоже все дело в pf, но понять в чем не могу проблема тем более на 8ке все работает. freebsd ставил методом замены винта. т.е. железо тоже маршрут меняется на цифры от балды, к примеру 5.9.99.11 это и есть маршрут. удаляем, делаем правильный и через время тоже самое, только шлюз другой :(

тем не менее проблема есть http://freebsd.1045724.n5.nabble.com/Default-route-changes-unexpectedly-td5792887.html настройки 9ки сделаны копированием конфигов, поэтому разница только в версии. сейчас думаю как провести тест не роняя основной канал. думаю выбрать кучу популярный сайтов и отправить их через 9ку чтобы хоть както поанализировать

День добрый. собстенно из темы проблема понятна. Стояла бсд 8.3 стаб от декабря. Установил 9.1 релиз, перекомпилил ядро options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_NAT options IPFIREWALL_FORWARD options LIBALIAS options IPDIVERT options DUMMYNET options DEVICE_POLLING options ROUTETABLES=3 device pf скопировал все настройки и запустил на боевом железе ipfw dummy, pf nat интерфейсы lagg, igb каждые 2-5 минут (10 стат маршрутов) слетает любой из них, не просто удаляется а меняется на произвольный адрес, который даже не принадлежит и близко моим сетям. пока вернулся на 8ку и все работает как часы. данную проблему описывают в куче майл-листов но везде статус опен. сервер гоняет примерно 600-800 мбит. обновление не обходимо для дальнешего усовершенствования системы и задач. что это за релиз софт роутера в котором 10 маршрутов не могут жить. кто сталкивался, от чего зависит? дело в том что сервер боевой и сидеть отлавливать изза чего такое случается нет возможности

день добрый. тема конечно устарела, но я также искал данный конвертер, т.к. флоу тулз имеет много полезных утилит. остановился на flowd у него есть также фильтры отсечения ненужного трафика, т.е. например потоки локального трафика. но есть минусы, чтобы отправить в 5 версию надо уже разбирать сформированный файл, т.к. он сам его не ротэйтит, приходиться убивать демон. а версия 9 это всетаки шаблонная, значит идет потеря трафика пока демон шаблонов нацепляет, убивая каджые 5 минут объем множится. главный минус не умеет отправлять не в stdout не в pipe. поковырял исходники и дописал патч к версии flowd-0.9.1_2 теперь с параметром -n программа валит поток в stderr в cvs формате как и flowd-reader, что прекрастно понимают flow-tools, так же с данным параметром не сохраняется дамп на диск, т.к. я его отправляю в другой графический колектор уже удалив ненужные потоки, что ненапрягает диск лишний раз и не забивает место. ну или прячет виайпи :) патч прилагаю, пользуйтесь. ну и запуск уже работающего фильтра для колектора у меня такой flowd -n -f /usr/local/etc/flowd.conf 2>&1|flow-import -V5 -f2|flow-send -V5 127.0.0.1/127.0.0.1/9995 нагрузки на процессоры пока замечено небыло надеюсь flowd всетаки допишет утилиту для онлайн сбора и обработки flowd.c.diff.txt