Есть FreeBSD 6.2, две сетевые карты, одна в инет, вторая в локалку. В локалке используются как "белые" адреса, так и "серые", т.е. часть пользователей ходит в инет через нат. Нат реализован через natd. Так же присутствует ограничение полосы пропускания средствами dummynet. Проблема в потери ~5% пакетов для пользователей локальной сети. При чем в независимости от того ходит пользователь через нат или у него "белый" адрес, потери у всех. При пинге с внешнего интерфейса самой FreeBSD потерь не наблюдается. Скорость в инет 10Mb/s.
Сетевые карты: RealTek 8139
Ядро Generic +
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=1000
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET
options TCP_DROP_SYNFIN
maxusers 512
options NBUF=4096
options DEVICE_POLLING
options HZ=1000В чем может быть проблема?
> maxusers 512
> options NBUF=4096А железо у Вас "тянет"? Соберите ядро без этих строчек, и уменьшите options IPFIREWALL_VERBOSE_LIMIT до 10. Еще хотелось бы взглянуть на правила фаервола..
>> maxusers 512
>> options NBUF=4096
>
>А железо у Вас "тянет"? Соберите ядро без этих строчек, и уменьшите
>options IPFIREWALL_VERBOSE_LIMIT до
>10. Еще хотелось бы взглянуть на правила фаервола..Firewall:
--
00040 divert 8668 ip from 192.168.1.0/24 to any via rl1 out
00050 divert 8668 ip from any to any via rl1 in
00060 allow ip from me to any
00065 allow udp from any 53 to me
00070 allow tcp from any to me dst-port 22
00080 pipe 1000 ip from any to table(2) via rl0
00090 pipe 1001 ip from table(2) to any via rl0${fwcmd} pipe 1000 config mask dst-ip 0xffffffff bw 512kbit/s
${fwcmd} pipe 1001 config mask src-ip 0xffffffff bw 512kbit/s
--rl1 - внешний интерфейс
rl0 - внутренний интерфейс
пользователи для шейпа добавляются в table 2Железо должно "тянуть", там core2duo + 2 гига памяти, для роутера по моему достаточно. При полной загрузке аплинка, судя по top'у нагрузки почти нет.
где-нибудь десяточкой поставь allow для обмена внутри сети. чтобы до ната не доходили.общая нагрузка на карты?
может одна из 8139 (внутренняя) забита под свои 90 и потому дропает?
>[оверквотинг удален]
>options IPFIREWALL_FORWARD
>options IPDIVERT
>options DUMMYNET
>options TCP_DROP_SYNFIN
>maxusers 512
>options NBUF=4096
>options DEVICE_POLLING
>options HZ=1000
>
>В чем может быть проблема?:)
у как по твоему думминет режет трафик?
открывай фаревол, отключай думми - смотри потери - думаю они прекратятся )
>[оверквотинг удален]
>>options NBUF=4096
>>options DEVICE_POLLING
>>options HZ=1000
>>
>>В чем может быть проблема?
>
>:)
>у как по твоему думминет режет трафик?
>открывай фаревол, отключай думми - смотри потери - думаю они прекратятся )
>Т.е. такие потери в данном случае нормальное явление и бороться с ними не имеет смысла?
>[оверквотинг удален]
>>>
>>>В чем может быть проблема?
>>
>>:)
>>у как по твоему думминет режет трафик?
>>открывай фаревол, отключай думми - смотри потери - думаю они прекратятся )
>>
>
>Т.е. такие потери в данном случае нормальное явление и бороться с ними
>не имеет смысла?ну дак естно - думми то тупо дропает лишние пакеты ))) отключи думми и посмотри
стутистику дропов видно (если я ниче не путаю) через ipfw pipe show
>[оверквотинг удален]
>>>открывай фаревол, отключай думми - смотри потери - думаю они прекратятся )
>>>
>>
>>Т.е. такие потери в данном случае нормальное явление и бороться с ними
>>не имеет смысла?
>
>ну дак естно - думми то тупо дропает лишние пакеты ))) отключи
>думми и посмотри
>стутистику дропов видно (если я ниче не путаю) через ipfw pipe show
>Присутствуют правила вида:
allow ip from any to table(1)
allow ip from table(1) to anyВ table 1 добавляются ip для которых не должно быть ограничений. Они не проходят через dummy, а потери на них такие же ~5%. Посмотрел ipfw pipe show дропов там меньше чем 5%. Быть может не в dummy дело?
>[оверквотинг удален]
>>
>
>Присутствуют правила вида:
>allow ip from any to table(1)
>allow ip from table(1) to any
>
>В table 1 добавляются ip для которых не должно быть ограничений. Они
>не проходят через dummy, а потери на них такие же ~5%.
>Посмотрел ipfw pipe show дропов там меньше чем 5%. Быть может
>не в dummy дело?ну как вариант у провайдера режется - вообще варианттов много
пингуй с внешнего интерфейса шлюза и смотри
при потерях основные причины ИМХО гнилой канал (в том числе битые пачкорды)
или шейпер
>[оверквотинг удален]
>>В table 1 добавляются ip для которых не должно быть ограничений. Они
>>не проходят через dummy, а потери на них такие же ~5%.
>>Посмотрел ipfw pipe show дропов там меньше чем 5%. Быть может
>>не в dummy дело?
>
>ну как вариант у провайдера режется - вообще варианттов много
>пингуй с внешнего интерфейса шлюза и смотри
>при потерях основные причины ИМХО гнилой канал (в том числе битые пачкорды)
>
>или шейперПро внешний интерфейс писал в первом посте, повторюсь, при пинге с внешнего интерфейса потерь нет. Может быть все дело в огромном количестве коннектов из локальной сети от пользователей торрентов? Как диагностироваться, не знаю. Может надо как-то ядро оттюнить?
>[оверквотинг удален]
>>ну как вариант у провайдера режется - вообще варианттов много
>>пингуй с внешнего интерфейса шлюза и смотри
>>при потерях основные причины ИМХО гнилой канал (в том числе битые пачкорды)
>>
>>или шейпер
>
>Про внешний интерфейс писал в первом посте, повторюсь, при пинге с внешнего
>интерфейса потерь нет. Может быть все дело в огромном количестве коннектов
>из локальной сети от пользователей торрентов? Как диагностироваться, не знаю. Может
>надо как-то ядро оттюнить?как вариант проапгрейдится до семерки и заюзать ядерный nat
>[оверквотинг удален]
>>>при потерях основные причины ИМХО гнилой канал (в том числе битые пачкорды)
>>>
>>>или шейпер
>>
>>Про внешний интерфейс писал в первом посте, повторюсь, при пинге с внешнего
>>интерфейса потерь нет. Может быть все дело в огромном количестве коннектов
>>из локальной сети от пользователей торрентов? Как диагностироваться, не знаю. Может
>>надо как-то ядро оттюнить?
>
>как вариант проапгрейдится до семерки и заюзать ядерный natкак нестранно согласен с Pahanivo
от себя же добавлю как вариант выдернуть пачкорд каторый смотри от свича в фряху, взять бук или комп (желательно с никсом на борту заведомо проверенный)пачкордом(заведомо желательно новым и проверенным) воткнуца в свич (также желательно новым и проверенным) другим шнурком воткнуться к фряхе к внутреннему интерфейсу и посмотреть пинги и остальное возможно (если у вас большая сеть) гонит гдето ютипишка или сам(и) свич(и).Также проверьте ерры на сетевухе каторая смотрит в локаль.возможно гдето коллизия.Также через tcpdum или trafshow посмотрите что за трафик прет с локали.При проверке всего вышесказанного в конце 90% вы будете знать в чем проблема.
>[оверквотинг удален]
>как нестранно согласен с Pahanivo
>от себя же добавлю как вариант выдернуть пачкорд каторый смотри от свича
>в фряху, взять бук или комп (желательно с никсом на борту
>заведомо проверенный)пачкордом(заведомо желательно новым и проверенным) воткнуца в свич (также желательно
>новым и проверенным) другим шнурком воткнуться к фряхе к внутреннему интерфейсу
>и посмотреть пинги и остальное возможно (если у вас большая сеть)
>гонит гдето ютипишка или сам(и) свич(и).Также проверьте ерры на сетевухе каторая
>смотрит в локаль.возможно гдето коллизия.Также через tcpdum или trafshow посмотрите что
>за трафик прет с локали.При проверке всего вышесказанного в конце 90%
>вы будете знать в чем проблема.ах да забыл проверьте на наличие петлей.
>[оверквотинг удален]
>>в фряху, взять бук или комп (желательно с никсом на борту
>>заведомо проверенный)пачкордом(заведомо желательно новым и проверенным) воткнуца в свич (также желательно
>>новым и проверенным) другим шнурком воткнуться к фряхе к внутреннему интерфейсу
>>и посмотреть пинги и остальное возможно (если у вас большая сеть)
>>гонит гдето ютипишка или сам(и) свич(и).Также проверьте ерры на сетевухе каторая
>>смотрит в локаль.возможно гдето коллизия.Также через tcpdum или trafshow посмотрите что
>>за трафик прет с локали.При проверке всего вышесказанного в конце 90%
>>вы будете знать в чем проблема.
>
>ах да забыл проверьте на наличие петлей.ОС до 7.х проапгрейдить не могу по ряду причин. Петель, коллизий, и ерроров нет. Проблема с потерей возникает именно при прохождении пакета через маршрутизатор. Грешу на торренты, так как открывают очень много сессий и большой pps. Можно ли как-то тюнингом ядра решить этот вопрос?
>[оверквотинг удален]
>>>смотрит в локаль.возможно гдето коллизия.Также через tcpdum или trafshow посмотрите что
>>>за трафик прет с локали.При проверке всего вышесказанного в конце 90%
>>>вы будете знать в чем проблема.
>>
>>ах да забыл проверьте на наличие петлей.
>
>ОС до 7.х проапгрейдить не могу по ряду причин. Петель, коллизий, и
>ерроров нет. Проблема с потерей возникает именно при прохождении пакета через
>маршрутизатор. Грешу на торренты, так как открывают очень много сессий и
>большой pps. Можно ли как-то тюнингом ядра решить этот вопрос?1) ммм тюнинг ядра не решит вопрос с нехваткой портов )) их всего 65536 на один айпи ))
2) с 6 на 7 проапгрейдится не думаю чтоб сильно проблематично - не с 4 всетаки ))
3) попробую юзать больше айпи адресов на интерфейсах шлюза снутри и с наружи
>[оверквотинг удален]
>>ерроров нет. Проблема с потерей возникает именно при прохождении пакета через
>>маршрутизатор. Грешу на торренты, так как открывают очень много сессий и
>>большой pps. Можно ли как-то тюнингом ядра решить этот вопрос?
>
>1) ммм тюнинг ядра не решит вопрос с нехваткой портов )) их
>всего 65536 на один айпи ))
>2) с 6 на 7 проапгрейдится не думаю чтоб сильно проблематично -
>не с 4 всетаки ))
>3) попробую юзать больше айпи адресов на интерфейсах шлюза снутри и с
>наружиНа этом роутере крутится софт работающий только под 6.х. Как количество портов влияет потерю пакетов? Все же склоняюсь к мысли, что проблема именно в большем количестве пакетов проходящих через роутер в единицу времени.
>[оверквотинг удален]
>>
>>1) ммм тюнинг ядра не решит вопрос с нехваткой портов )) их
>>всего 65536 на один айпи ))
>>2) с 6 на 7 проапгрейдится не думаю чтоб сильно проблематично -
>>не с 4 всетаки ))
>>3) попробую юзать больше айпи адресов на интерфейсах шлюза снутри и с
>>наружи
>
>На этом роутере крутится софт работающий только под 6.х. Как количество портов
>влияет потерю пакетов?ты вообще в курсе как работает НАТ?
>Все же склоняюсь к мысли, что проблема именно
>в большем количестве пакетов проходящих через роутер в единицу времени.
>[оверквотинг удален]
>>>не с 4 всетаки ))
>>>3) попробую юзать больше айпи адресов на интерфейсах шлюза снутри и с
>>>наружи
>>
>>На этом роутере крутится софт работающий только под 6.х. Как количество портов
>>влияет потерю пакетов?
>>Все же склоняюсь к мысли, что проблема именно
>>в большем количестве пакетов проходящих через роутер в единицу времени.
>
>ты вообще в курсе как работает НАТ?Подозреваю :) И что? Озвучите свою мысль. Может я чего-то не понимаю...
>[оверквотинг удален]
>>>
>>>На этом роутере крутится софт работающий только под 6.х. Как количество портов
>>>влияет потерю пакетов?
>>>Все же склоняюсь к мысли, что проблема именно
>>>в большем количестве пакетов проходящих через роутер в единицу времени.
>>
>>ты вообще в курсе как работает НАТ?
>
>Подозреваю :) И что? Озвучите свою мысль. Может я чего-то не понимаю...
>Пример-задачка для шыбко одаренных:
У тебя через шлюз проходит отновременно 66000 тысяч tcp соединений
Вопрос - как такое возможно если в принципе каличество портов на один айпи ограничено 65536? Как при этом вы вообще представляете таблицу трансляции?
>[оверквотинг удален]
>>>ты вообще в курсе как работает НАТ?
>>
>>Подозреваю :) И что? Озвучите свою мысль. Может я чего-то не понимаю...
>>
>
>Пример-задачка для шыбко одаренных:
>У тебя через шлюз проходит отновременно 66000 тысяч tcp соединений
>Вопрос - как такое возможно если в принципе каличество портов на один
>айпи ограничено 65536? Как при этом вы вообще представляете таблицу трансляции?
>Ещё раз повторюсь... И что? Какое отношение это имеет к озвученной мной проблеме? В самом первом посте написано, что пакеты теряются как у пользователей с натом, так и у пользователей с "белым" IP, которые через нат никоим боком не проходят.
Офтопик: Давайте не будет считать других идиотами и начнем внимательно читать о чем пишут.
>Есть FreeBSD 6.2, две сетевые карты, одна в инет, вторая в локалку.
>Сетевые карты: RealTek 8139
>В чем может быть проблема?Были такие грабли, назывались FreeBSD + RealTek 8139. Про 6.2 точно не скажу, но беда с драйвером точно была конкретная. Замени на серверную карту хотя бы одну из них, которая теряет, а лучше - обе. На такие, стоимость которых под 2 т.р., они сами "думают".
Если погуглить на эту тему, то находится масса эмоций, где народ пишет по поводу дешёвых карт на чипах, подобных rt.
>Были такие грабли, назывались FreeBSD + RealTek 8139.Были такие грабли, назывались RealTek.
FIXED! Любой версии под любой осью!
Ставь интеля, те которые em - стоят копейки но пашут как зверЪ ! :)
>>Были такие грабли, назывались FreeBSD + RealTek 8139.
>
>Были такие грабли, назывались RealTek.
>
>
>FIXED! Любой версии под любой осью!
>Ставь интеля, те которые em - стоят копейки но пашут как зверЪ
>! :)Спасибо за совет! Может есть какая-нить модель проверенная из бюджетных? А то ставить на этот маршрутизатор карты за 2000р. слеХка перебор...
>[оверквотинг удален]
>>
>>Были такие грабли, назывались RealTek.
>>
>>
>>FIXED! Любой версии под любой осью!
>>Ставь интеля, те которые em - стоят копейки но пашут как зверЪ
>>! :)
>
>Спасибо за совет! Может есть какая-нить модель проверенная из бюджетных? А то
>ставить на этот маршрутизатор карты за 2000р. слеХка перебор...3COM-905 - из 100 мбитных одна из лучших.
Dlink DGE-530T (именно 530) - тоже проблем с ней не было.
1. Отказаться от natd в пользу ng_nat. В идеале - обновиться до 7.х и перейти на ipnat.
2. 00050 divert 8668 ip from any to any via rl1 in это НЕ правильно! Ты заорачиваешь в natd ВЕСЬ входящий трафик. Посмотри сколько ресурсов ест у тебя natd. Удивишься.
Создай таблицу "0", в нее занеси все белые сети. Измени правило: 00050 divert 8668 ip from any to not "table(0)" via rl1 in. Или перед этими правилами поставь skipto (начало правил с шейперами) ip from any to not "table(0)" via rl1 in. Но не забывай п.1. Он обязателен.
3. IPFIREWALL_VERBOSE_LIMIT вполне достаточно 200.
4. Однозначно выкинуть rlt. Это НЕ серверная карта. Никогда ею не была и никогда ею не будет. Она просто не в состоянии работать под нагрузкой. Полллинг она тоже не держит. Так что твой "options DEVICE_POLLING" мимо кассы. Выбор - однозначно intel pro 1000.
5. Когда поставишь интел - включай поллинг. Гарантированно полегшает.
6. Увеличь buckets для pipe где-то до 4096. По дефолту не помню сколько, но чо-то мало. Это позволит уменьшить дропы на шейпере.
7. В ядро добавь "options KVA_PAGES=512" чтобы твои 2 гига не балластились в пустую.По памяти, вроде все.
Перечисленные меры позволили на такой же в точности конфиге (только сетевухи были Intel) обслуживать чуть более двух тысяч абонентов в онлайне, внешним каналом 150 Мбит/сек. со смешанными (белые и серые) адресами вообще без проблем.
top -S
netstat -w1
где все это для начала?
>top -S
>netstat -w1
>где все это для начала?В общем дошли наконец руки до этого роутера, заменил сетевухи на Intel(R) PRO/1000 Network Connection. Проблема исчезла.
Всем спасибо за помощь.