форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Ограничить ширину полосы для IP."
Сообщение от Monster_C on 28-Фев-03, 17:22  (MSK)
Задача вобщем такая. Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы на вход/выход для всех IP, кроме привилегированных. А то канал отдельные несознательные личности забивают. Железо: C-5505+ATM+RSFC. Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что лучше - недавно я с Цисками работать начал. Помогите советом плиззз.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

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

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

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

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

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

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

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

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

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

	9. "RE: Ограничить ширину полосы для IP."
	Сообщение от Andrius on 03-Мрт-03, 14:05  (MSK)
	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 !
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

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

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

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

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

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

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

	26. "RE: Ограничить ширину полосы для IP."
	Сообщение от LS on 12-Мрт-03, 01:38  (MSK)
	>однако это решение "в лоб" - советую присмотреться к высказываниям udlus и прошу прощения - не udlus,а uldus.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

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

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

	14. "RE: Ограничить ширину полосы для IP."
	Сообщение от Monster_C on 04-Мрт-03, 15:14  (MSK)
	>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 >! Спасибо, попробую применить.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

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

	28. "резать входящий трафик МОЖНО! :)"
	Сообщение от баггзи on 17-Мрт-03, 00:13  (MSK)
	для TCP во всяком случае - манипулированием шириной окна. систему сделал, у некоторых стоит, вроде никаких жалоб.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

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

	30. "можно..."
	Сообщение от баггзи on 18-Мрт-03, 09:43  (MSK)
	>>для 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-пакета). Для прочих ОС и железок - пинайте своих кернелхакеров и фирмварщиков.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	31. "решение для оригинального вопрошавшего"
	Сообщение от баггзи on 18-Мрт-03, 10:05  (MSK)
	под 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
		Рекомендовать в FAQ | Cообщить модератору | Наверх

21. "RE: Ограничить ширину полосы для IP."
Сообщение от Lorky on 10-Мрт-03, 12:56  (MSK)
>Задача вобщем такая. >Есть локальная сеть порядка 500 IP. Необходимо ограничить потолок полосы >на вход/выход для всех IP, кроме привилегированных. А то канал отдельные >несознательные личности забивают. >Железо: C-5505+ATM+RSFC. >Я вижу возможности в Шейпинге и Рэйт-лимит, но не могу врубиться, что >лучше - недавно я с Цисками работать начал. >Помогите советом плиззз. Рабочий конфиг: роутер под Linux SlackWare 8.1 PII-350/64Mb Ram/Hdd 6Gb сетка на 35 компов ядро собрано с поддержкой CBQ скрипт Павла Голубева ( http://freshmeat.net/projects/cbq.init ) iproute2 (tc и ip) режится ИСХОДЯЩИЙ трафик на каждый IP причем динамически, тк стоит управляющий демон, который выставляет нужную скорость для каждого IP по указаниям с пульта управления :) система установки скорости тривиальна до бзобразия, файлики с кофигурацими скорости канала на каждый IP, после чего один раз запускается Голубевский скрипт - cbq start пример конфигурационного файлика: DEVICE=eth1,100Mbit,10Mbit //Описание интерфейса где будет происходит шейп, в моем случее это локальная карточка RATE=128KBit     //максимальная выделяемая скорость WEIGHT=12Kbit   // хз что такое на всегда должна быть =RATE/10 PRIO=5          //приоритет обработки RULE=172.18.1.5 //собственно IP на который навешиваем ограничения скорости все это работает уже два года, жалоб нет. Основная проблема - мое нежелание запихнуть в загрузку ограничитель скорости для всех и сразу, а то если линукс валится все прутся в инет по бешенному пока не проснется упровляющий демон. Темы по поводу ограничения ВХОДЯЩЕГО трафика, под моей конфигурацией это можно решить только установкой еще одного физического роуера и резать на нем. И Вообще зачем резать Входящий трафик, ведь он уже приехал на гейт, а вы его резать, нужно резать только ИСХОДЯЩИЙ, получится, то что запросы на получение будут просто медленно проходить, соответственно источник будет медленно отвечать. По UDP данный набор режет тоже и правельно. ЗЫ: щас вроде появилось продолжение CBQ под названием TBQ
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	32. "RE: Ограничить ширину полосы для IP."
	Сообщение от Домовенок on 24-Янв-04, 14:25  (MSK)
	>И Вообще зачем резать Входящий трафик, ведь он уже приехал на гейт, >а вы его резать, нужно резать только ИСХОДЯЩИЙ, получится, то что >запросы на получение будут просто медленно проходить, соответственно источник будет медленно отвечать. По UDP данный набор режет тоже и правельно. Прочитал я ваши мнения, но так и не понял всех кто утверждает что не надо резать входящий. Смотрите НЕ режем: Ушло от меня 600 байт запроса (Х пакетов) [исходящий] в ответ закачивается что-нибудь в огромных количествах и в итоге за N секунд я получил многа много Мегабайт входящего ... вы меня не ограничили по исходящиму. режем входящий: Ушло от меня 600 байт запроса (те же Х пакетиков) [исходящий] в ответ начинает так же как и в прошлый раз закачиваться что-нибудь в огромных количествах и в итоге за N секунд я получил НАМНОГО МЕНЬШЕ Мегабайт входящего ... Т.е. Заплатили за тот же периодж времени меньше денюшков. А почему так ? А вот потому что входящий начинаеться только после ответов сервера готовых принять их ... т.е.: Сервер извне посылает N пакетиков траффика... когда ваш сервер ответит что принял их успешно - посылаются следующие, а если ответит с задержкой? Правильно, за то же время вы получите от сервера извне намного меньше пакетов! Тут немного там немного, а в куче дают хороший результат .... $$$$$$$$ :) Поправьте если я не прав?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.