forum.opennet.ru

Форум Маршрутизаторы CISCO и др. оборудование.
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Ограничить ширину полосы для IP., Monster_C (?), 28-Фев-03, (0) [смотреть все]

входящий траффик если он из и-нета ограничивать особого смысла нета исходящий , Volume (?), 17:32 , 28-Фев-03, (1) //

А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписыва, Dim (?), 20:23 , 28-Фев-03, (2) //

правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу пропускания, Volume (?), 20:33 , 28-Фев-03, (3) //

Смысл есть Он состоит в том, что бы в дальнейшем такого не было А то провайдер, Monster_C (?), 09:09 , 01-Мрт-03, (4)

все-таки судя по всему вы не поняли то что дошло до вашего рутера уже заняло , Volume (?), 10:37 , 01-Мрт-03, (5)

Traffic-shape не дропает пакеты, а делеит их Достаточно посмотреть статитсику s, Sonne (?), 15:39 , 03-Мрт-03, (10)

Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку паке, uldus (?), 13:42 , 01-Мрт-03, (6)

да а вы можете именно их задержать или сможете именно их дропать да а когд, Volume (?), 14:04 , 01-Мрт-03, (7)

конечно, если резать входящий траффик в результате он сократится, но незначитель, Volume (?), 14:35 , 01-Мрт-03, (8)

traffic-shape for download is OK As much as it can it bufferspackets , Andrius (?), 14:05 , 03-Мрт-03, (9)

Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны пр, evo (?), 16:50 , 03-Мрт-03, (11)

а что провайдер то кричит, ему то какое дело, ему деньги за это и платят Для V, A Clockwork Orange (?), 14:23 , 04-Мрт-03, (12)
В корне не согласен Если я запру на вход некий IP, ни кто на него мне 1Gb трафи, Monster_C (?), 15:11 , 04-Мрт-03, (13)

Да я купил у провайдера кнала с такой то полосой пропусания, и какое дело и что , A Clockwork Orange (?), 16:35 , 04-Мрт-03, (15)

Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ см выше и это медицинский факт, Monster_C (?), 13:47 , 07-Мрт-03, (16)

А вот это, Вы, батенька зряя Здесь я могу прочитать, что Вы хотели сделать, но , LS (?), 23:37 , 07-Мрт-03, (18)
Вы праву, коммерция - ну ее - Речь идет о ВУЗовской сети Есть некий головной , Monster_C (?), 18:18 , 10-Мрт-03, (22)
ну, как говориться, раз пошла такая пьянка я в этом случае car посоветую - р, LS (?), 01:34 , 12-Мрт-03, (25)
прошу прощения - не udlus,а uldus , LS (?), 01:38 , 12-Мрт-03, (26)
Тут надо определиться в терминах Я считаю входящим для меня трафик поступающи, Monster_C (?), 10:20 , 12-Мрт-03, (27)
Ситуация НИКАКАЯ я в вопросе вижу только то, что Вы хотите сделать а Вы уверен, LS (?), 23:54 , 07-Мрт-03, (19)
Фильмы качают ото всюду - Меня интересует лишь канал НАРУЖУ - ВХОД и ВЫХОД , Monster_C (?), 18:40 , 10-Мрт-03, (24)

У меня на роутере 2 интерфейса, наружный и внутренний Что мне мешает полноценно, Monster_C (?), 18:25 , 10-Мрт-03, (23)

Спасибо, попробую применить , Monster_C (?), 15:14 , 04-Мрт-03, (14)

Это сводится к задаче шейпинга исходящих пакетов, так как пакеты с подтверждения, uldus (?), 21:46 , 08-Мрт-03, (20)

технически ты прав, но если крендель, который за день выкачивает фильмы пза 30 м, LS (?), 23:22 , 07-Мрт-03, (17)

для TCP во всяком случае - манипулированием шириной окна систему сделал, у неко, баггзи (?), 00:13 , 17-Мрт-03, (28) //

а 'МОЖНО! :)' тогда мыслями по этому повдоу поделиться?, LS (?), 03:14 , 18-Мрт-03, (29) //

какими еще мыслями все вроде уже сказано у TCP-пакета есть параметр окно win, баггзи (?), 09:43 , 18-Мрт-03, (30)

под linux набирается из головы, могут быть баги ставится width-patch чайн для, баггзи (?), 10:05 , 18-Мрт-03, (31)

Рабочий конфиг роутер под Linux SlackWare 8 1 PII-350 64Mb Ram Hdd 6Gbсетка на 3, Lorky (?), 12:56 , 10-Мрт-03, (21) //

Прочитал я ваши мнения, но так и не понял всех кто утверждает что не надо резать, Домовенок (?), 14:25 , 24-Янв-04, (32)

Сообщения [Сортировка по времени | RSS]

1. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Volume (?), 28-Фев-03, 17:32

>Задача вобщем такая.
>Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы
>на вход/выход для всех IP, кроме привилегированных. А то канал отдельные
>несознательные личности забивают.
>Железо: C-5505+ATM+RSFC.
>Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что
>лучше - недавно я с Цисками работать начал.
>Помогите советом плиззз.
входящий траффик (если он из и-нета) ограничивать особого смысла нет
а исходящий...я думаю traffic-shaping вам как раз
или CBWFQ

Ответить | Правка | Наверх | Cообщить модератору

2. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Dim (?), 28-Фев-03, 20:23

>
>входящий траффик (если он из и-нета) ограничивать особого смысла нет
>а исходящий...я думаю traffic-shaping вам как раз
>или CBWFQ
А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают? Пусть переписывают, но медленно...
Ведь деньги-то как раз за входящий и платятся.

Ответить | Правка | Наверх | Cообщить модератору

3. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Volume (?), 28-Фев-03, 20:33

>
>>
>>входящий траффик (если он из и-нета) ограничивать особого смысла нет
>>а исходящий...я думаю traffic-shaping вам как раз
>>или CBWFQ
>
>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают?
>Пусть переписывают, но медленно...
>Ведь деньги-то как раз за входящий и платятся.
правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу пропускания, провайдер его УЖЕ ПОСЧИТАЛ
так есть-ли особый смысл?

Ответить | Правка | Наверх | Cообщить модератору

4. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 01-Мрт-03, 09:09

>>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают?
>>Пусть переписывают, но медленно...
>>Ведь деньги-то как раз за входящий и платятся.
>
>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>так есть-ли особый смысл?

Смысл есть. Он состоит в том, что бы в дальнейшем такого не было.
А то провайдер вопить начинает: что делаете гады! Мы вас наголо подстригем !!
Кроме того, есть приоритетные адреса (сервера), доступ к которым должен быть гарантирован..
Я не против фильмов, но если фильм скачивается за полчаса, то остальные в это время отдыхают - фильмокачатель занял практически всю полосу. а если их 10 - то вообще дело труба.. То же самое и с исходящим трафиком, ибо фильмы туда-сюда летают..
Вобщем необходимы симметричные ограничения и уравнивание юзеров по занимаемой полосе.

Ответить | Правка | Наверх | Cообщить модератору

5. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Volume (?), 01-Мрт-03, 10:37

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

Ответить | Правка | Наверх | Cообщить модератору

10. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Sonne (?), 03-Мрт-03, 15:39

>какой смысл дропать пакеты, которые уже дошли до вас, за которые вы
>фактически заплатили?
Traffic-shape не дропает пакеты, а делеит их. Достаточно посмотреть статитсику sho traffic-shape statistic.
Задержка пакетов как раз и означает что уменьшается входной поток, т.к. клиентский комп увеличивает свои TCP таймауты и освобождает канал.

Ответить | Правка | Наверх | Cообщить модератору

6. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от uldus (?), 01-Мрт-03, 13:42

>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>так есть-ли особый смысл?
Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с подтверждением доставки или начать дропать пакеты, никуда входящий трафик не дойдет, а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия пакетов, остальные будут жать в очереди на отправляющей пакеты машине).

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

7. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Volume (?), 01-Мрт-03, 14:04

>>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>>так есть-ли особый смысл?
>
>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с
>подтверждением доставки или начать дропать пакеты, никуда входящий трафик
да? а вы можете именно их задержать? :) или сможете именно их дропать?
>не дойдет,
>а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия
>пакетов, остальные будут жать в очереди на отправляющей пакеты машине).
да? а когда выйдет таймаут tcp-сессия прервется и все пойдет заново?
а если udp-поток?

Ответить | Правка | Наверх | Cообщить модератору

8. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Volume (?), 01-Мрт-03, 14:35

>>>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>>>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>>>так есть-ли особый смысл?
>>
>>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с
>>подтверждением доставки или начать дропать пакеты, никуда входящий трафик
>да? а вы можете именно их задержать? :) или сможете именно их
>дропать?
>
>>не дойдет,
>>а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия
>>пакетов, остальные будут жать в очереди на отправляющей пакеты машине).
>
>да? а когда выйдет таймаут tcp-сессия прервется и все пойдет заново?
>а если udp-поток?
конечно, если резать входящий траффик в результате он сократится, но незначительно, и думаю что в результате фактически никакого выигрыша не будет

Ответить | Правка | Наверх | Cообщить модератору

9. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Andrius (?), 03-Мрт-03, 14:05

traffic-shape  for  download  is  OK.  As  much  as  it can it buffers
packets.  After  some  time  it  drops  packets. This way TCP "Window"
becomes smaller and "ACK" more seldom. (IMHO) :)

interface Ethernet0  <-- download (local) int
bandwidth 512  <-- total
traffic-shape group 192 420000 10080 10080 1000
!
! This way you shape all network to 420kbps and leave ~50kbps for your
! critical "10.10.10.111"
!

access-list 192 deny   ip any host 10.10.10.111   <-- critical IP
access-list 192 permit ip any any time-range sheiper1  <-- all other NET
time-range sheiper1
periodic weekdays 7:59 to 17:01
!

Ответить | Правка | Наверх | Cообщить модератору

11. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от evo (?), 03-Мрт-03, 16:50

Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны провайдера и со стороны Вашей сети.
Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они не откажут.
Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только на трафик из своей сети но ни как не в свою сеть.
Провайдер наоборот.

Ответить | Правка | Наверх | Cообщить модератору

12. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от A Clockwork Orange (?), 04-Мрт-03, 14:23

а что провайдер то кричит, ему то какое дело, ему деньги за это и платят...
Для Volume
Для чего же тогда trafic-shape оно нужно?

Ответить | Правка | Наверх | Cообщить модератору

13. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 04-Мрт-03, 15:11

>Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны
>провайдера и со стороны Вашей сети.
>Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они
>не откажут.
>Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только
>на трафик из своей сети но ни как не в свою
>сеть.
>Провайдер наоборот.
В корне не согласен. Если я запру на вход некий IP, ни кто на него мне 1Gb трафика не зальет. Логично? Тогда что мешает не убивать холопа, но и жить ему не давать? Речь, образно говоря, идет о создании некой плотины, которая не отправляет поток назад, а регулирует его сдерживая. Таким образом, мы получаем не бурный поток, а аккуратненький ручеек. Пусть юзер качает хоть Гигами, но не за полчаса, а за день-другой.
А провайдер недоволе не объемами, атем что наше учреждение полосу иногда занимает гигантскую. И либо провайдер начнет уши подстригать, либо я сам порядок с юзерами наведу. Вопрос стоит в таком ключе.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

15. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от A Clockwork Orange (?), 04-Мрт-03, 16:35

>>Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны
>>провайдера и со стороны Вашей сети.
>>Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они
>>не откажут.
>>Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только
>>на трафик из своей сети но ни как не в свою
>>сеть.
>>Провайдер наоборот.
>В корне не согласен. Если я запру на вход некий IP, ни
>кто на него мне 1Gb трафика не зальет. Логично? Тогда что
>мешает не убивать холопа, но и жить ему не давать? Речь,
>образно говоря, идет о создании некой плотины, которая не отправляет поток
>назад, а регулирует его сдерживая. Таким образом, мы получаем не бурный
>поток, а аккуратненький ручеек. Пусть юзер качает хоть Гигами, но не
>за полчаса, а за день-другой.
>А провайдер недоволе не объемами, атем что наше учреждение полосу иногда занимает
Да я купил у провайдера кнала с такой то полосой пропусания, и какое дело и что? какое дело провайдера на сколько канал занят? не понимаю
>гигантскую. И либо провайдер начнет уши подстригать, либо я сам порядок
>с юзерами наведу. Вопрос стоит в таком ключе.

Ответить | Правка | Наверх | Cообщить модератору

16. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 07-Мрт-03, 13:47

>>А провайдер недоволен не объемами, атем что наше учреждение полосу иногда занимает
>
>Да я купил у провайдера кнала с такой то полосой пропусания, и
>какое дело и что? какое дело провайдера на сколько канал занят?
>не понимаю
Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский
факт. Из него и надо исходить. Разговоры о провайдере - разговоры в пользу бедных.. Нужно техническое решение с моей стороны.
И все..

Ответить | Правка | Наверх | Cообщить модератору

18. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от LS (?), 07-Мрт-03, 23:37

>Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский
>факт. Из него и надо исходить. Разговоры о провайдере - разговоры в
>пользу бедных.. Нужно техническое решение с моей стороны.
>И все..
А вот это, Вы, батенька зряя..
Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы, что это правильно?
Нет никаких реальных исходных данных - хотя бы как идет работа с провайдером (разумеется только техника - ну ее коммерцию :-))?
Может тогда на Ваш вопрос найдется лучший ответ? Все же немного неприятно когда из тебя пытаются вытянуть решение, ничего не говоря (попросту говоря  - разводят).

Ответить | Правка | Наверх | Cообщить модератору

22. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 10-Мрт-03, 18:18

>
>А вот это, Вы, батенька зряя..
>
>Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы,
>что это правильно?
>
>Нет никаких реальных исходных данных - хотя бы как идет работа с
>провайдером (разумеется только техника - ну ее коммерцию :-))?
Вы праву, коммерция - ну ее. :-)
Речь идет о ВУЗовской сети. Есть некий головной ВУЗ со своим Центром
управления полетами - условный "провайдер". Есть разбросанные по городу
ВУЗы. Я админю один из них.
"Взаимодействие с "провайдером"" примерно такое - приходит почтой ко мне
малява: ваш IP-такой-то в такое-то время занимал гигантсую (входящуюу или
исходящуюу) полосу в канале, разобраться, принять меры, доложить! Вот и
все взаимодействие.
Я ни кого ни на что разводить не имею желания. Я имею желания установить
потолок в полосе на вход/выход для каждого IP из моих сетей, так что бы
связь была устойчивой для каждого, без потерь пакетов, с мнимальными
издержками. Исключение - привилегированные IP (сервера и т.д..).
Мое железо - C-5505+ATM+RSFC+FDDI. Железо новое, мной необъезженное,
по этому может и формулирую дурацкие запросы..
Если я сам не сделаю ограничений - сделают "уровнем выше" без всяких
разборок, от этого пострадают ВСЕ. А потом ломать их на снятие ограничений
дело долгое и утомительное..

Ответить | Правка | Наверх | Cообщить модератору

25. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от LS (?), 12-Мрт-03, 01:34

>>
>>А вот это, Вы, батенька зряя..
>>
>>Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы,
>>что это правильно?
>>
>>Нет никаких реальных исходных данных - хотя бы как идет работа с
>>провайдером (разумеется только техника - ну ее коммерцию :-))?
>
>Вы праву, коммерция - ну ее. :-)
>Речь идет о ВУЗовской сети. Есть некий головной ВУЗ со своим Центром
>
>управления полетами - условный "провайдер". Есть разбросанные по городу
>ВУЗы. Я админю один из них.
>"Взаимодействие с "провайдером"" примерно такое - приходит почтой ко мне
>малява: ваш IP-такой-то в такое-то время занимал гигантсую (входящуюу или
> исходящуюу) полосу в канале, разобраться, принять меры, доложить! Вот и
>все взаимодействие.
>Я ни кого ни на что разводить не имею желания. Я имею
>желания установить
>потолок в полосе на вход/выход для каждого IP из моих сетей, так
>что бы
>связь была устойчивой для каждого, без потерь пакетов, с мнимальными
>издержками. Исключение - привилегированные IP (сервера и т.д..).
>Мое железо - C-5505+ATM+RSFC+FDDI. Железо новое, мной необъезженное,
>по этому может и формулирую дурацкие запросы..
>Если я сам не сделаю ограничений - сделают "уровнем выше" без всяких
>
>разборок, от этого пострадают ВСЕ. А потом ломать их на снятие ограничений
>
> дело долгое и утомительное..
ну, как говориться, раз пошла такая пьянка...
я в этом случае car посоветую - режет трафик в обе стороны, меньше грузит циску.
однако это решение "в лоб" - советую присмотреться к высказываниям udlus и evo, поскольку проблему, обозначенную Volume это решить не поможет (если она актуальна - до сих пор непонятно откуда прет "наглый" входящий трафик (на твой маршрутизатор) - из вашей внутреней сети (вузоской) или из вне?)

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

26. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от LS (?), 12-Мрт-03, 01:38

>однако это решение "в лоб" - советую присмотреться к высказываниям udlus и

прошу прощения - не udlus,а uldus.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

27. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 12-Мрт-03, 10:20

>>А потом ломать их на снятие ограничений
>> дело долгое и утомительное..
>
>ну, как говориться, раз пошла такая пьянка...
>я в этом случае car посоветую - режет трафик в обе стороны,
>меньше грузит циску.
>однако это решение "в лоб" - советую присмотреться к высказываниям udlus и
>evo, поскольку проблему, обозначенную Volume это решить не поможет (если она
>актуальна - до сих пор непонятно откуда прет "наглый" входящий трафик
>(на твой маршрутизатор) - из вашей внутреней сети (вузоской) или из
>вне?)
Тут надо определиться в терминах. Я считаю входящим (для меня) трафик
поступающий на смотрящий наружу интерфейс (ATM) моего роутера.
Внутренней сетью я считаю СВОЮ сеть, на которую смотрит внутренний интерфейс роутера (FDDI). Вузовской сетью я называю сеть раскинутую по ВУЗам города. Идет трафик из Парагвая или из соседнего ВУЗа, мне фиолетово
- для меня он ВХОДЯЩИЙ. "Наглый" трафик может быть как входящий, так и
исходящий. Критерий наглости - гигантская занимаемая полоса. Ее и надо
ограничить.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

19. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от LS (?), 07-Мрт-03, 23:54

>Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский
>факт. Из него и надо исходить. Разговоры о провайдере - разговоры в
>пользу бедных.. Нужно техническое решение с моей стороны.
>И все..
Ситуация НИКАКАЯ! я в вопросе вижу только то, что Вы хотите сделать (а Вы уверенны, что это правильно?). При этом я не вижу полной ситуации, в которой  надо решать этот вопрос. Для примера - откуда качают эти фильмы?: из Вашей локальной сети или Ваш клиент через Вас?
Если Вы провайдер - это одно, если стоите на страже отдельной локальной сетки - это другое, если и первое и второе (все догадались :)) - это третье...

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

24. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 10-Мрт-03, 18:40

>Ситуация НИКАКАЯ! я в вопросе вижу только то, что Вы хотите сделать
>(а Вы уверенны, что это правильно?). При этом я не вижу
>полной ситуации, в которой  надо решать этот вопрос. Для примера
>- откуда качают эти фильмы?: из Вашей локальной сети или Ваш
>клиент через Вас?
>
>Если Вы провайдер - это одно, если стоите на страже отдельной локальной
>сетки - это другое, если и первое и второе (все догадались
>:)) - это третье...
Фильмы качают ото всюду :-)) Меня интересует лишь канал НАРУЖУ - ВХОД и ВЫХОД.

Ответить | Правка | Наверх | Cообщить модератору

23. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 10-Мрт-03, 18:25

>Это более оптимальный путь, так как Вы можете полноценно оказывать >влияние только
>на трафик из своей сети но ни как не в свою сеть.
У меня на роутере 2 интерфейса, наружный и внутренний. Что мне мешает
полноценно оказывать влияния на входящий и исходящий трафик ?????

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

14. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от Monster_C (?), 04-Мрт-03, 15:14

>traffic-shape  for  download  is  OK.  As
>much  as  it can it buffers
>packets.  After  some  time  it  drops
>packets. This way TCP "Window"
>becomes smaller and "ACK" more seldom. (IMHO) :)
>-----------SKIP-----------
>time-range sheiper1
> periodic weekdays 7:59 to 17:01
>!
Спасибо, попробую применить.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

20. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от uldus (?), 08-Мрт-03, 21:46

>>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с
>>подтверждением доставки или начать дропать пакеты, никуда входящий трафик
>да? а вы можете именно их задержать? :) или сможете именно их
>дропать?
Это сводится к задаче шейпинга исходящих пакетов, так как пакеты с подтверждениями уже исходящий трафик. Что касается "именно их", то заполнение полей TCP/IP заголовках никто не отменял, а задержать пакет в очереди или вообще периодически дропать не так сложно и этого вполне хватит для регулирования входящего потока (все вышесказанное справедливо конечно же для TCP).

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

17. "RE: Ограничить ширину полосы для IP." +/–

Сообщение от LS (?), 07-Мрт-03, 23:22

>>
>>>
>>>входящий траффик (если он из и-нета) ограничивать особого смысла нет
>>>а исходящий...я думаю traffic-shaping вам как раз
>>>или CBWFQ
>>
>>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают?
>>Пусть переписывают, но медленно...
>>Ведь деньги-то как раз за входящий и платятся.
>
>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу
>пропускания, провайдер его УЖЕ ПОСЧИТАЛ
>так есть-ли особый смысл?
технически ты прав, но если крендель, который за день выкачивает фильмы пза 30 минут, станет качать их по 12 часов, то думаю, ему это не так интересно будет, со всеми вытекающими последствиями :)....

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

28. "резать входящий трафик МОЖНО! :)" +/–

Сообщение от баггзи (?), 17-Мрт-03, 00:13

для TCP во всяком случае - манипулированием шириной окна. систему сделал, у некоторых стоит, вроде никаких жалоб.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

29. "а 'МОЖНО! :)'  тогда мыслями по этому повдоу  поделиться?" +/–

Сообщение от LS (?), 18-Мрт-03, 03:14

>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у
>некоторых стоит, вроде никаких жалоб.

Ответить | Правка | Наверх | Cообщить модератору

30. "можно..." +/–

Сообщение от баггзи (?), 18-Мрт-03, 09:43

>>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у
>>некоторых стоит, вроде никаких жалоб.
какими еще мыслями? все вроде уже сказано.
у TCP-пакета есть параметр "окно" (window), определяющее, сколько октетов информации готова принять сторона, сообщающая window (то есть пакеты с window идут в одну сторону, пакеты с данными - в обратную).
при window>MTU отсылается сразу несколько пакетов (например, 64K/1500 ~ 42). Сокращение параметра window до MTU вызовет снижение скорости в avg(window)/MTU раз за счет того, что за тот же промежуток времени отсылается только один пакет. Экспериментально снижение скорости составляет не меньше 10.
Остается только считать нагрузку на канал, и если она больше допустимой, менять на лету параметр window в TCP-пакетах, и это снижает нагрузку (до 10 раз). Этого достаточно, чтобы красиво резать трафик - без расхода памяти, загрузки процессора и глюков, возникающих из-за дропанья пакетов в других методах.
Недостатки:
1. ограничивает только TCP-составляющую. Впрочем, в подавляющем большинстве случаев именно TCP вызывает значительную загрузку канала.
2. при большой наглости (если желающие перегрузить канал откроют в 10 раз больше потоков, чем обычно) засрать канал таки удастся. решается добавлением дропалки при перегрузке, тогда лишние потоки будут только уменьшать результирующую скорость, и наглецы смиряцца и станут хорошими.
У меня есть только реализация под linux в виде пары модулей netfilter (рассчет нагрузки в байт/секунду и изменение окна TCP-пакета). Для прочих ОС и железок - пинайте своих кернелхакеров и фирмварщиков.

Ответить | Правка | Наверх | Cообщить модератору

31. "решение для оригинального вопрошавшего" +/–

Сообщение от баггзи (?), 18-Мрт-03, 10:05

под linux ;) набирается из головы, могут быть баги.
ставится width-patch
#чайн для ограничения трафика (имя не важно)
iptables -N cutter
#ежели на всех хватает, то не надо резать, мы не жадные...
#жадным следующую строчку не надо
iptables -A cutter -m width --bytes=ширина канала в байтах/сек -j RETURN
#неприкосновенным не мешать!
iptables -A cutter -s привелегированный -j RETURN
#сюда идет трафик непривелегинованных ип в случае перегрузки канала
#мы его считаем и в случае чего снижаем окно до MTU-100
iptables -A cutter -p TCP -m width --bytes=СколькоМыИмДадим -j TCPWIN --set-win=1400
#ну и домой
iptables -A cutter -j RETURN
#тк я не стал заморачиваться с connection tracking'ом, а менять window нужно в пакетах, идущих в "обратную сторону", на самом деле ограничивается трафик в обе стороны - и входящий, и исходящий.
#направим весь трафик сходить сосчитаться и поправиться
iptables -A INPUT -j cutter
iptables -A OUTPUT -j cutter

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "RE: Ограничить ширину полосы для IP."	+/–
Сообщение от Volume (?), 28-Фев-03, 17:32
>Задача вобщем такая. >Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы >на вход/выход для всех IP, кроме привилегированных. А то канал отдельные >несознательные личности забивают. >Железо: C-5505+ATM+RSFC. >Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что >лучше - недавно я с Цисками работать начал. >Помогите советом плиззз. входящий траффик (если он из и-нета) ограничивать особого смысла нет а исходящий...я думаю traffic-shaping вам как раз или CBWFQ
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Dim (?), 28-Фев-03, 20:23
	> >входящий траффик (если он из и-нета) ограничивать особого смысла нет >а исходящий...я думаю traffic-shaping вам как раз >или CBWFQ А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают? Пусть переписывают, но медленно... Ведь деньги-то как раз за входящий и платятся.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Volume (?), 28-Фев-03, 20:33
	> >> >>входящий траффик (если он из и-нета) ограничивать особого смысла нет >>а исходящий...я думаю traffic-shaping вам как раз >>или CBWFQ > >А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают? >Пусть переписывают, но медленно... >Ведь деньги-то как раз за входящий и платятся. правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу пропускания, провайдер его УЖЕ ПОСЧИТАЛ так есть-ли особый смысл?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 01-Мрт-03, 09:09
	>>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают? >>Пусть переписывают, но медленно... >>Ведь деньги-то как раз за входящий и платятся. > >правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу >пропускания, провайдер его УЖЕ ПОСЧИТАЛ >так есть-ли особый смысл? Смысл есть. Он состоит в том, что бы в дальнейшем такого не было. А то провайдер вопить начинает: что делаете гады! Мы вас наголо подстригем !! Кроме того, есть приоритетные адреса (сервера), доступ к которым должен быть гарантирован.. Я не против фильмов, но если фильм скачивается за полчаса, то остальные в это время отдыхают - фильмокачатель занял практически всю полосу. а если их 10 - то вообще дело труба.. То же самое и с исходящим трафиком, ибо фильмы туда-сюда летают.. Вобщем необходимы симметричные ограничения и уравнивание юзеров по занимаемой полосе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Volume (?), 01-Мрт-03, 10:37
	>Я не против фильмов, но если фильм скачивается за полчаса, то остальные >в это время отдыхают - фильмокачатель занял практически всю полосу. а >если их 10 - то вообще дело труба.. То же самое >и с исходящим трафиком, ибо фильмы туда-сюда летают.. >Вобщем необходимы симметричные ограничения и уравнивание юзеров по занимаемой полосе. все-таки судя по всему вы не поняли.... то что дошло до вашего рутера уже заняло канал, и от того что вы дропнете эти пакеты, канала больше не будет какой смысл дропать пакеты, которые уже дошли до вас, за которые вы фактически заплатили?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Sonne (?), 03-Мрт-03, 15:39
	>какой смысл дропать пакеты, которые уже дошли до вас, за которые вы >фактически заплатили? Traffic-shape не дропает пакеты, а делеит их. Достаточно посмотреть статитсику sho traffic-shape statistic. Задержка пакетов как раз и означает что уменьшается входной поток, т.к. клиентский комп увеличивает свои TCP таймауты и освобождает канал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от uldus (?), 01-Мрт-03, 13:42
	>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу >пропускания, провайдер его УЖЕ ПОСЧИТАЛ >так есть-ли особый смысл? Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с подтверждением доставки или начать дропать пакеты, никуда входящий трафик не дойдет, а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия пакетов, остальные будут жать в очереди на отправляющей пакеты машине).
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	7. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Volume (?), 01-Мрт-03, 14:04
	>>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу >>пропускания, провайдер его УЖЕ ПОСЧИТАЛ >>так есть-ли особый смысл? > >Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с >подтверждением доставки или начать дропать пакеты, никуда входящий трафик да? а вы можете именно их задержать? :) или сможете именно их дропать? >не дойдет, >а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия >пакетов, остальные будут жать в очереди на отправляющей пакеты машине). да? а когда выйдет таймаут tcp-сессия прервется и все пойдет заново? а если udp-поток?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Volume (?), 01-Мрт-03, 14:35
	>>>правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу >>>пропускания, провайдер его УЖЕ ПОСЧИТАЛ >>>так есть-ли особый смысл? >> >>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с >>подтверждением доставки или начать дропать пакеты, никуда входящий трафик >да? а вы можете именно их задержать? :) или сможете именно их >дропать? > >>не дойдет, >>а будет шейпится не хуже исходящего (точнее дойдет тельно первая партия >>пакетов, остальные будут жать в очереди на отправляющей пакеты машине). > >да? а когда выйдет таймаут tcp-сессия прервется и все пойдет заново? >а если udp-поток? конечно, если резать входящий траффик в результате он сократится, но незначительно, и думаю что в результате фактически никакого выигрыша не будет
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Andrius (?), 03-Мрт-03, 14:05
	traffic-shape for download is OK. As much as it can it buffers packets. After some time it drops packets. This way TCP "Window" becomes smaller and "ACK" more seldom. (IMHO) :) interface Ethernet0 <-- download (local) int bandwidth 512 <-- total traffic-shape group 192 420000 10080 10080 1000 ! ! This way you shape all network to 420kbps and leave ~50kbps for your ! critical "10.10.10.111" ! access-list 192 deny ip any host 10.10.10.111 <-- critical IP access-list 192 permit ip any any time-range sheiper1 <-- all other NET time-range sheiper1 periodic weekdays 7:59 to 17:01 !
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от evo (?), 03-Мрт-03, 16:50
	Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны провайдера и со стороны Вашей сети. Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они не откажут. Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только на трафик из своей сети но ни как не в свою сеть. Провайдер наоборот.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от A Clockwork Orange (?), 04-Мрт-03, 14:23
	а что провайдер то кричит, ему то какое дело, ему деньги за это и платят... Для Volume Для чего же тогда trafic-shape оно нужно?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 04-Мрт-03, 15:11
	>Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны >провайдера и со стороны Вашей сети. >Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они >не откажут. >Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только >на трафик из своей сети но ни как не в свою >сеть. >Провайдер наоборот. В корне не согласен. Если я запру на вход некий IP, ни кто на него мне 1Gb трафика не зальет. Логично? Тогда что мешает не убивать холопа, но и жить ему не давать? Речь, образно говоря, идет о создании некой плотины, которая не отправляет поток назад, а регулирует его сдерживая. Таким образом, мы получаем не бурный поток, а аккуратненький ручеек. Пусть юзер качает хоть Гигами, но не за полчаса, а за день-другой. А провайдер недоволе не объемами, атем что наше учреждение полосу иногда занимает гигантскую. И либо провайдер начнет уши подстригать, либо я сам порядок с юзерами наведу. Вопрос стоит в таком ключе.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	15. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от A Clockwork Orange (?), 04-Мрт-03, 16:35
	>>Я думаю тут надо подходить комплексно, то есть регулировать трафик со стороны >>провайдера и со стороны Вашей сети. >>Способов регулирования достаточно много и лучше это обсудить с провайдером, думаю они >>не откажут. >>Это более оптимальный путь, так как Вы можете полноценно оказывать влияние только >>на трафик из своей сети но ни как не в свою >>сеть. >>Провайдер наоборот. >В корне не согласен. Если я запру на вход некий IP, ни >кто на него мне 1Gb трафика не зальет. Логично? Тогда что >мешает не убивать холопа, но и жить ему не давать? Речь, >образно говоря, идет о создании некой плотины, которая не отправляет поток >назад, а регулирует его сдерживая. Таким образом, мы получаем не бурный >поток, а аккуратненький ручеек. Пусть юзер качает хоть Гигами, но не >за полчаса, а за день-другой. >А провайдер недоволе не объемами, атем что наше учреждение полосу иногда занимает Да я купил у провайдера кнала с такой то полосой пропусания, и какое дело и что? какое дело провайдера на сколько канал занят? не понимаю >гигантскую. И либо провайдер начнет уши подстригать, либо я сам порядок >с юзерами наведу. Вопрос стоит в таком ключе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 07-Мрт-03, 13:47
	>>А провайдер недоволен не объемами, атем что наше учреждение полосу иногда занимает > >Да я купил у провайдера кнала с такой то полосой пропусания, и >какое дело и что? какое дело провайдера на сколько канал занят? >не понимаю Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский факт. Из него и надо исходить. Разговоры о провайдере - разговоры в пользу бедных.. Нужно техническое решение с моей стороны. И все..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от LS (?), 07-Мрт-03, 23:37
	>Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский >факт. Из него и надо исходить. Разговоры о провайдере - разговоры в >пользу бедных.. Нужно техническое решение с моей стороны. >И все.. А вот это, Вы, батенька зряя.. Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы, что это правильно? Нет никаких реальных исходных данных - хотя бы как идет работа с провайдером (разумеется только техника - ну ее коммерцию :-))? Может тогда на Ваш вопрос найдется лучший ответ? Все же немного неприятно когда из тебя пытаются вытянуть решение, ничего не говоря (попросту говоря - разводят).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 10-Мрт-03, 18:18
	> >А вот это, Вы, батенька зряя.. > >Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы, >что это правильно? > >Нет никаких реальных исходных данных - хотя бы как идет работа с >провайдером (разумеется только техника - ну ее коммерцию :-))? Вы праву, коммерция - ну ее. :-) Речь идет о ВУЗовской сети. Есть некий головной ВУЗ со своим Центром управления полетами - условный "провайдер". Есть разбросанные по городу ВУЗы. Я админю один из них. "Взаимодействие с "провайдером"" примерно такое - приходит почтой ко мне малява: ваш IP-такой-то в такое-то время занимал гигантсую (входящуюу или исходящуюу) полосу в канале, разобраться, принять меры, доложить! Вот и все взаимодействие. Я ни кого ни на что разводить не имею желания. Я имею желания установить потолок в полосе на вход/выход для каждого IP из моих сетей, так что бы связь была устойчивой для каждого, без потерь пакетов, с мнимальными издержками. Исключение - привилегированные IP (сервера и т.д..). Мое железо - C-5505+ATM+RSFC+FDDI. Железо новое, мной необъезженное, по этому может и формулирую дурацкие запросы.. Если я сам не сделаю ограничений - сделают "уровнем выше" без всяких разборок, от этого пострадают ВСЕ. А потом ломать их на снятие ограничений дело долгое и утомительное..
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от LS (?), 12-Мрт-03, 01:34
	>> >>А вот это, Вы, батенька зряя.. >> >>Здесь я могу прочитать, что Вы хотели сделать, но уверенны ли Вы, >>что это правильно? >> >>Нет никаких реальных исходных данных - хотя бы как идет работа с >>провайдером (разумеется только техника - ну ее коммерцию :-))? > >Вы праву, коммерция - ну ее. :-) >Речь идет о ВУЗовской сети. Есть некий головной ВУЗ со своим Центром > >управления полетами - условный "провайдер". Есть разбросанные по городу >ВУЗы. Я админю один из них. >"Взаимодействие с "провайдером"" примерно такое - приходит почтой ко мне >малява: ваш IP-такой-то в такое-то время занимал гигантсую (входящуюу или > исходящуюу) полосу в канале, разобраться, принять меры, доложить! Вот и >все взаимодействие. >Я ни кого ни на что разводить не имею желания. Я имею >желания установить >потолок в полосе на вход/выход для каждого IP из моих сетей, так >что бы >связь была устойчивой для каждого, без потерь пакетов, с мнимальными >издержками. Исключение - привилегированные IP (сервера и т.д..). >Мое железо - C-5505+ATM+RSFC+FDDI. Железо новое, мной необъезженное, >по этому может и формулирую дурацкие запросы.. >Если я сам не сделаю ограничений - сделают "уровнем выше" без всяких > >разборок, от этого пострадают ВСЕ. А потом ломать их на снятие ограничений > > дело долгое и утомительное.. ну, как говориться, раз пошла такая пьянка... я в этом случае car посоветую - режет трафик в обе стороны, меньше грузит циску. однако это решение "в лоб" - советую присмотреться к высказываниям udlus и evo, поскольку проблему, обозначенную Volume это решить не поможет (если она актуальна - до сих пор непонятно откуда прет "наглый" входящий трафик (на твой маршрутизатор) - из вашей внутреней сети (вузоской) или из вне?)
	Ответить \| Правка \| К родителю #22 \| Наверх \| Cообщить модератору


	26. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от LS (?), 12-Мрт-03, 01:38
	>однако это решение "в лоб" - советую присмотреться к высказываниям udlus и прошу прощения - не udlus,а uldus.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	27. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 12-Мрт-03, 10:20
	>>А потом ломать их на снятие ограничений >> дело долгое и утомительное.. > >ну, как говориться, раз пошла такая пьянка... >я в этом случае car посоветую - режет трафик в обе стороны, >меньше грузит циску. >однако это решение "в лоб" - советую присмотреться к высказываниям udlus и >evo, поскольку проблему, обозначенную Volume это решить не поможет (если она >актуальна - до сих пор непонятно откуда прет "наглый" входящий трафик >(на твой маршрутизатор) - из вашей внутреней сети (вузоской) или из >вне?) Тут надо определиться в терминах. Я считаю входящим (для меня) трафик поступающий на смотрящий наружу интерфейс (ATM) моего роутера. Внутренней сетью я считаю СВОЮ сеть, на которую смотрит внутренний интерфейс роутера (FDDI). Вузовской сетью я называю сеть раскинутую по ВУЗам города. Идет трафик из Парагвая или из соседнего ВУЗа, мне фиолетово - для меня он ВХОДЯЩИЙ. "Наглый" трафик может быть как входящий, так и исходящий. Критерий наглости - гигантская занимаемая полоса. Ее и надо ограничить.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	19. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от LS (?), 07-Мрт-03, 23:54
	>Тут не надо ничего понимать, ситуация ВОТ_ТАКАЯ (см. выше)и это медицинский >факт. Из него и надо исходить. Разговоры о провайдере - разговоры в >пользу бедных.. Нужно техническое решение с моей стороны. >И все.. Ситуация НИКАКАЯ! я в вопросе вижу только то, что Вы хотите сделать (а Вы уверенны, что это правильно?). При этом я не вижу полной ситуации, в которой надо решать этот вопрос. Для примера - откуда качают эти фильмы?: из Вашей локальной сети или Ваш клиент через Вас? Если Вы провайдер - это одно, если стоите на страже отдельной локальной сетки - это другое, если и первое и второе (все догадались :)) - это третье...
	Ответить \| Правка \| К родителю #16 \| Наверх \| Cообщить модератору


	24. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 10-Мрт-03, 18:40
	>Ситуация НИКАКАЯ! я в вопросе вижу только то, что Вы хотите сделать >(а Вы уверенны, что это правильно?). При этом я не вижу >полной ситуации, в которой надо решать этот вопрос. Для примера >- откуда качают эти фильмы?: из Вашей локальной сети или Ваш >клиент через Вас? > >Если Вы провайдер - это одно, если стоите на страже отдельной локальной >сетки - это другое, если и первое и второе (все догадались >:)) - это третье... Фильмы качают ото всюду :-)) Меня интересует лишь канал НАРУЖУ - ВХОД и ВЫХОД.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 10-Мрт-03, 18:25
	>Это более оптимальный путь, так как Вы можете полноценно оказывать >влияние только >на трафик из своей сети но ни как не в свою сеть. У меня на роутере 2 интерфейса, наружный и внутренний. Что мне мешает полноценно оказывать влияния на входящий и исходящий трафик ?????
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	14. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от Monster_C (?), 04-Мрт-03, 15:14
	>traffic-shape for download is OK. As >much as it can it buffers >packets. After some time it drops >packets. This way TCP "Window" >becomes smaller and "ACK" more seldom. (IMHO) :) >-----------SKIP----------- >time-range sheiper1 > periodic weekdays 7:59 to 17:01 >! Спасибо, попробую применить.
	Ответить \| Правка \| К родителю #9 \| Наверх \| Cообщить модератору


	20. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от uldus (?), 08-Мрт-03, 21:46
	>>Входящие пакеты тоже не бесконечным потоком льются, если задержать отправку пакетов с >>подтверждением доставки или начать дропать пакеты, никуда входящий трафик >да? а вы можете именно их задержать? :) или сможете именно их >дропать? Это сводится к задаче шейпинга исходящих пакетов, так как пакеты с подтверждениями уже исходящий трафик. Что касается "именно их", то заполнение полей TCP/IP заголовках никто не отменял, а задержать пакет в очереди или вообще периодически дропать не так сложно и этого вполне хватит для регулирования входящего потока (все вышесказанное справедливо конечно же для TCP).
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	17. "RE: Ограничить ширину полосы для IP."	+/–
	Сообщение от LS (?), 07-Мрт-03, 23:22
	>> >>> >>>входящий траффик (если он из и-нета) ограничивать особого смысла нет >>>а исходящий...я думаю traffic-shaping вам как раз >>>или CBWFQ >> >>А почему нет смысла ограничивать входящий - может, люди сидят, фильмы переписывают? >>Пусть переписывают, но медленно... >>Ведь деньги-то как раз за входящий и платятся. > >правильно, но входящий траффик до вас УЖЕ ДОШЕЛ, он УЖЕ ЗАНЯЛ полосу >пропускания, провайдер его УЖЕ ПОСЧИТАЛ >так есть-ли особый смысл? технически ты прав, но если крендель, который за день выкачивает фильмы пза 30 минут, станет качать их по 12 часов, то думаю, ему это не так интересно будет, со всеми вытекающими последствиями :)....
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	28. "резать входящий трафик МОЖНО! :)"	+/–
	Сообщение от баггзи (?), 17-Мрт-03, 00:13
	для TCP во всяком случае - манипулированием шириной окна. систему сделал, у некоторых стоит, вроде никаких жалоб.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	29. "а 'МОЖНО! :)' тогда мыслями по этому повдоу поделиться?"	+/–
	Сообщение от LS (?), 18-Мрт-03, 03:14
	>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у >некоторых стоит, вроде никаких жалоб.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	30. "можно..."	+/–
	Сообщение от баггзи (?), 18-Мрт-03, 09:43
	>>для TCP во всяком случае - манипулированием шириной окна. систему сделал, у >>некоторых стоит, вроде никаких жалоб. какими еще мыслями? все вроде уже сказано. у TCP-пакета есть параметр "окно" (window), определяющее, сколько октетов информации готова принять сторона, сообщающая window (то есть пакеты с window идут в одну сторону, пакеты с данными - в обратную). при window>MTU отсылается сразу несколько пакетов (например, 64K/1500 ~ 42). Сокращение параметра window до MTU вызовет снижение скорости в avg(window)/MTU раз за счет того, что за тот же промежуток времени отсылается только один пакет. Экспериментально снижение скорости составляет не меньше 10. Остается только считать нагрузку на канал, и если она больше допустимой, менять на лету параметр window в TCP-пакетах, и это снижает нагрузку (до 10 раз). Этого достаточно, чтобы красиво резать трафик - без расхода памяти, загрузки процессора и глюков, возникающих из-за дропанья пакетов в других методах. Недостатки: 1. ограничивает только TCP-составляющую. Впрочем, в подавляющем большинстве случаев именно TCP вызывает значительную загрузку канала. 2. при большой наглости (если желающие перегрузить канал откроют в 10 раз больше потоков, чем обычно) засрать канал таки удастся. решается добавлением дропалки при перегрузке, тогда лишние потоки будут только уменьшать результирующую скорость, и наглецы смиряцца и станут хорошими. У меня есть только реализация под linux в виде пары модулей netfilter (рассчет нагрузки в байт/секунду и изменение окна TCP-пакета). Для прочих ОС и железок - пинайте своих кернелхакеров и фирмварщиков.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. "решение для оригинального вопрошавшего"	+/–
	Сообщение от баггзи (?), 18-Мрт-03, 10:05
	под linux ;) набирается из головы, могут быть баги. ставится width-patch #чайн для ограничения трафика (имя не важно) iptables -N cutter #ежели на всех хватает, то не надо резать, мы не жадные... #жадным следующую строчку не надо iptables -A cutter -m width --bytes=ширина канала в байтах/сек -j RETURN #неприкосновенным не мешать! iptables -A cutter -s привелегированный -j RETURN #сюда идет трафик непривелегинованных ип в случае перегрузки канала #мы его считаем и в случае чего снижаем окно до MTU-100 iptables -A cutter -p TCP -m width --bytes=СколькоМыИмДадим -j TCPWIN --set-win=1400 #ну и домой iptables -A cutter -j RETURN #тк я не стал заморачиваться с connection tracking'ом, а менять window нужно в пакетах, идущих в "обратную сторону", на самом деле ограничивается трафик в обе стороны - и входящий, и исходящий. #направим весь трафик сходить сосчитаться и поправиться iptables -A INPUT -j cutter iptables -A OUTPUT -j cutter
	Ответить \| Правка \| Наверх \| Cообщить модератору