Есть сеточка в ней траф делится по приоритетам с помощью queue . И всё работало нормально пока был слабенький канальчик . Сейчас расширили этот самый канал и наткнулись на просечки в трафе : т.е. у чела инет может пропасть минут на 1-10 потом благополучно появиться и некоторое время чуть ли не со скоростью всего канала фигачить. При этом во время пропадания инета у чела у остальных людей траф идет. Чтой-то мне говорит , что дело в функционировании очередей. В мане написано , что во время проверки состояния очередей я должен быть за консолью. Тут я полностью согласен. НО как мне всё-таки эту проверку организовать? Плиз вместе с RTFM выслать и ссылочку гиде это почитать , а если и на русском то тут ваааще благодарен буду ? Или мне начальству заявлять , что фря с этим никогда не справится и пора кошку покупать?
незнаю как у кого а у меня 512К ipfw делил совсем некрсаиво.
что-то у него там неравномерно работает и клиент то тащит во всю, то стал как придурок. Похоже что dummynet при достижении верхней планки пайпа просто перестает принимать пакеты снаружи - что само по себе очень обидно (пакет то вошол - трафик защитался).Вобщем я поставил transparent сквида, настроил delay_pool и афигеваю с ровненького заборчика в закачках пользователей.
а ipfw всего лишь фаерволит по своему прямому назначению...
>Вобщем я поставил transparent сквида, настроил delay_pool и афигеваю с ровненького заборчика
>в закачках пользователей.
проблем в том, что через сквида не весь траф идет и тот же осёл враз всю полосу забивает.
>незнаю как у кого а у меня 512К ipfw делил совсем некрсаиво.
>
>что-то у него там неравномерно работает и клиент то тащит во всю,
>то стал как придурок. Похоже что dummynet при достижении верхней планки
>пайпа просто перестает принимать пакеты снаружи - что само по себе
>очень обидно (пакет то вошол - трафик защитался).Ну правильно, классический tail drop. Более нормальные ОС (как то, Cisco IOS) используют более другие методы, а FreeBSD другого не умеет. А проект AltQ давно заморожен :(
>Есть сеточка в ней траф делится по приоритетам с помощью queue .
>И всё работало нормально пока был слабенький канальчик . Сейчас расширили
>этот самый канал и наткнулись на просечки в трафе : т.е.
>у чела инет может пропасть минут на 1-10 потом благополучно появиться
>и некоторое время чуть ли не со скоростью всего канала фигачить.
>При этом во время пропадания инета у чела у остальных
>людей траф идет. Чтой-то мне говорит , что дело в функционировании
>очередей. В мане написано , что во время проверки состояния очередей
>я должен быть за консолью. Тут я полностью согласен. НО как
>мне всё-таки эту проверку организовать? Плиз вместе с RTFM выслать и
>ссылочку гиде это почитать , а если и на русском то
>тут ваааще благодарен буду ? Или мне начальству заявлять , что
>фря с этим никогда не справится и пора кошку покупать?ipfw pipe show|list
ipfw queue show|list
+покажи правила
>ipfw pipe show|list
>ipfw queue show|list
Непонятки там ну есть правила , но я не вижу все ли пакеты в очередь ставятся и чего не хватает.
>+покажи правила
ipfw pipe show
30000: 2.000 Mbit/s 0 ms 50 sl. 0 queues (1024 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x000000ff/0x0000
31000: 2.000 Mbit/s 0 ms 50 sl. 0 queues (1024 buckets) droptail
mask: 0x00 0x000000ff/0x0000 -> 0x00000000/0x0000
q00001: weight 50 pipe 30000 50 sl. 72 queues (1024 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x000000ff/0x0000
q05001: weight 50 pipe 31000 50 sl. 72 queues (1024 buckets) droptail
mask: 0x00 0x000000ff/0x0000 -> 0x00000000/0x0000
ipfw show
41007 713593 190021930 queue 1 ip from any to 192.168.1.7
41007 366018 29013117 queue 5001 ip from 192.168.1.7 to any
55000 1011809 212806455 allow ip from 192.168.1.7 to any limit dst-addr 15
55000 65938 5938751 allow ip from any to 192.168.1.7 limit src-addr 15