forum.opennet.ru

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

Оглавление

OpenNews: Улучшенное конфигурирование ipfw, opennews (??), 26-Июн-08, (0) [смотреть все]

Упростить настройку ipfw очень просто достаточно всего лишь заменить его pf , Аноним (-), 17:08 , 26-Июн-08, (1) //

сам больше 2х лет использовал pf, пока не столкнулся с проблемой динамического с, parad (??), 17:28 , 26-Июн-08, (3) //

Фильтрация по маске пакета - это что Удобный интерфейс для редактирования прави, Осторожный (?), 21:51 , 26-Июн-08, (13) //

Это я сканкретизировал часть задачи, которую недавно приходилось решать, - а име, parad (??), 22:23 , 26-Июн-08, (16)

нет gt оверквотинг удален Ха А что именно нужно сделать-то Какая стоит конкре, Осторожный (?), 00:27 , 27-Июн-08, (20)

Я и говорю - pf лучше подойдет для простых правил В том, что вы написали сра, parad (??), 09:41 , 27-Июн-08, (27)

Ну почему для простых-то Хоть в pf, хоть в ipfw написать можно ЛЮБЫЕ правила В, Осторожный (?), 23:50 , 27-Июн-08, (33)

Вообще divert был придуман в FreeBSD чтобы как-то сделать natdИ является скорее , Осторожный (?), 00:34 , 27-Июн-08, (21)

Защита от рассылки спама из клиентских сетей - проверяет, чтобы все smtp подключ, parad (??), 09:22 , 27-Июн-08, (26)

если не секрет, можно узнать как Вы это делаете , lithium (ok), 10:29 , 27-Июн-08, (29)

не секрет при подключении на 25 порт подключения заварачиваются на divert сокет, parad (??), 15:08 , 27-Июн-08, (31)

Я делаю проще и тупее1 25 порт наружу запрещен только mailserver может слать п, Осторожный (?), 23:39 , 27-Июн-08, (32)

так сделано у 90 провайдеров START TLS приравнивается к прохождению аутентифик, parad (??), 13:38 , 28-Июн-08, (34)

gt оверквотинг удален , Осторожный (?), 17:29 , 28-Июн-08, (35)
1 SMTP AUTH шлет пароль открытым текстом Это опасно Насчет этого надеюсь вопро, Осторожный (?), 17:33 , 28-Июн-08, (36)

А что то поумнее сказать - , Dima (??), 17:27 , 26-Июн-08, (2) //

к вам это тоже относится и ко мне относится в общем стена там ----пошли , trey (?), 17:33 , 26-Июн-08, (4)

в статье анахронизмы вперемешку с откровенными ошибками это вообще шедевр браво, rage (??), 17:56 , 26-Июн-08, (5) //

Криво выражено, но по сути верно Вешать шейпинг на вход - полностью логически э, nuclight (ok), 22:08 , 03-Июл-08, (38)

Единственное, что не смог сделать с natd - keep-state правило , drTr0jan (?), 18:04 , 26-Июн-08, (6) //

http nuclight livejournal com 124348 html http www opennet ru opennews art , nuclight (ok), 22:01 , 03-Июл-08, (37)

до кучиhttp michurin com ru bsd-ipfw shtmlрассказ для тех, кто не знает, что т, Аноним (7), 18:57 , 26-Июн-08, (7)
Блин, режет глаз слово ложить И опечатки И вообще Вся тема про недостаток , Sem (ok), 18:57 , 26-Июн-08, (8) //

_Шейпить_ входящий трафик _нельзя_ Его можно только _резать_ Это альфа, Andrew Kolchoogin (?), 20:21 , 26-Июн-08, (11) //

Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, , Sem (ok), 20:42 , 26-Июн-08, (12) //

Потому что Его можно только заполисить Не передать на дальнейшую обработку, Andrew Kolchoogin (?), 22:31 , 26-Июн-08, (18)

входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обр, Осторожный (?), 21:57 , 26-Июн-08, (14) //

Нет C Фарид Вагапов, если тут еще хоть кто-то помнит, кто это такой Я, Andrew Kolchoogin (?), 22:29 , 26-Июн-08, (17)

Вот зуб не надо По дороге между источником ping-ом и firewall многое может случи, Осторожный (?), 00:43 , 27-Июн-08, (23)

Угу, или не справиться мой TCP IP-стек посылать пакеты с такой скоростью, чтобы , Andrew Kolchoogin (?), 10:17 , 27-Июн-08, (28)

Бгы гыОграничивать можно только то что УЖЕ пришло Ограничивать скорость попадан, mFF (?), 11:49 , 04-Июл-08, (39)

gt оверквотинг удален Андрей прав Все нижепишущие прочтите разницу между Poli, migosm (?), 22:20 , 26-Июн-08, (15) //

gt оверквотинг удален Ну послал, так послал Но раз не указал, куда идти, т, Sem (??), 11:54 , 27-Июн-08, (30)

Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени , Eugen Konkov (?), 01:46 , 09-Май-09, (41)

тяжко-то как живётся юзверям bw 8Kbytes, z1nkum (ok), 19:06 , 26-Июн-08, (9)
все это хорошо, только нарезать четко плавно каналы не говоря уже о распределен, grayich (??), 19:34 , 26-Июн-08, (10)
Мдя, бывает У ipfw уже кучу лет есть ряд полезных фич типа verrevpath, versrcrea, Myc (??), 22:32 , 26-Июн-08, (19) //

Лучший способ убить border router router enPassword router conf trouter config , Andrew Kolchoogin (?), 00:35 , 27-Июн-08, (22) //

Аргументы и факты Cisco давно рекомендует использовать эту фичу и выполняется о, Аноним (-), 09:16 , 27-Июн-08, (25)

В результате дропаются DHCP-запросы которые идут с адреса 0 0 0 0 to 255 255 255, Осторожный (?), 00:49 , 27-Июн-08, (24)

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

8. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Sem (ok), 26-Июн-08, 18:57

Блин, режет глаз слово "ложить". И опечатки. И вообще...
Вся тема про недостаток ALTQ мягко говоря спорная. Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических целях. И фраза про разделение входящего канала поровну - технически не грамотная. Можно создать иллюзию придерживая часть трафика, но к каналу это не имеет отношения.

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

11. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Andrew Kolchoogin (?), 26-Июн-08, 20:21

> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
> целях.
    _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
    Это "альфа" и "омега" всего управления трафиком в TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да пожалуйста, хоть сто раз. Канал у вас по входу как на полке был, так на полке и останется  (это я в вашу сторону "ping -f" пустил :).
    Да, можно влиять на вход, шейпя исход: TCP -- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
    И до тех пор, пока такие вот безграмотные статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали по объявлениям".
    :-\

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

12. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Sem (ok), 26-Июн-08, 20:42

>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
>    _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только криво это и с трудом можно придумать этому оправдание. О чем и речь.

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

18. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Andrew Kolchoogin (?), 26-Июн-08, 22:31

> Под входящим тут имеется в виду не тот трафик, который идет в
> интерфейс, а тот, который пришел, но еще не передан на обработку.
> Почему его "_нельзя_" зашейпить?
    Потому что. Его можно только заполисить. Не передать на дальнейшую обработку, если он транзитный. Но _каналам_ твоим от этого ни горячо, ни холодно.
> Можно.
    Нельзя.
> Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
    Речь о безграмотности автора статьи. :)

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

14. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Осторожный (?), 26-Июн-08, 21:57

>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических
>> целях.
>
>    _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_.
входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обработку
- например в локальную сеть
>
>
>    Это "альфа" и "омега" всего управления трафиком в
>TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да
>пожалуйста, хоть сто раз. Канал у вас по входу как на
>полке был, так на полке и останется  (это я в
>вашу сторону "ping -f" пустил :).
тем не менее твои входящие ping можно ограничить по скорости
- с какой скоростью они будут попадать на мой интерфейс
>[оверквотинг удален]
>    Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
>    И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
>    :-\
ха-ха

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

17. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Andrew Kolchoogin (?), 26-Июн-08, 22:29

> тем не менее твои входящие ping можно ограничить по скорости
> - с какой скоростью они будут попадать на мой интерфейс
    Нет. (C) Фарид Вагапов, если тут еще хоть кто-то помнит, кто это такой.
    Я зуб даю с пломбой, что мои пинги будут попадать на твой интерфейс ровно с той скоростью, с которой я их посылаю. Не быстрее, и не медленнее.
    Это они в твой TCP/IP-стек могут не попадать. Но _каналу_ от этого легче не станет. Dixi.

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

23. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Осторожный (?), 27-Июн-08, 00:43

>> тем не менее твои входящие ping можно ограничить по скорости
>> - с какой скоростью они будут попадать на мой интерфейс
>
>    Нет. (C) Фарид Вагапов, если тут еще хоть
>кто-то помнит, кто это такой.
>
>    Я зуб даю с пломбой, что мои пинги
>будут попадать на твой интерфейс ровно с той скоростью, с которой
>я их посылаю. Не быстрее, и не медленнее.
Вот зуб не надо.
По дороге между источником ping-ом и firewall многое может случиться
- например их может drop-нуть или задержать проходящий роутер.
>
>    Это они в твой TCP/IP-стек могут не попадать.
>Но _каналу_ от этого легче не станет. Dixi.
Каналу легче не станет, но про канал речи и не было вовсе.

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

28. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Andrew Kolchoogin (?), 27-Июн-08, 10:17

>> Я зуб даю с пломбой, что мои пинги
>> будут попадать на твой интерфейс ровно с той скоростью, с которой
>> я их посылаю. Не быстрее, и не медленнее.
> Вот зуб не надо.
> По дороге между источником ping-ом и firewall многое может случиться
> - например их может drop-нуть или задержать проходящий роутер.
Угу, или не справиться мой TCP/IP-стек посылать пакеты с такой скоростью, чтобы выложить _мой_ канал на полку. :)
Разумеется, имелся в виду ping flood с directly-connected router'а.

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

39. "Улучшенное конфигурирование ipfw" +/–

Сообщение от mFF (?), 04-Июл-08, 11:49

>тем не менее твои входящие ping можно ограничить по скорости
>- с какой скоростью они будут попадать на мой интерфейс
>
Бгы гы
Ограничивать можно только то что УЖЕ пришло.
Ограничивать "скорость попадания на твой интерфейс" можно только на вышестоящем роутере.
Почитал бы ты что-нибудь о защите от DDOS-атак что ли.

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

15. "Улучшенное конфигурирование ipfw" +/–

Сообщение от migosm (?), 26-Июн-08, 22:20

>[оверквотинг удален]
>    Да, можно влиять на вход, шейпя исход: TCP
>-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью,
>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>
>
>    И до тех пор, пока такие вот безграмотные
>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>по объявлениям".
>
>    :-\
Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.

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

30. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Sem (??), 27-Июн-08, 11:54

>[оверквотинг удален]
>>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить.
>>
>>
>>    И до тех пор, пока такие вот безграмотные
>>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали
>>по объявлениям".
>>
>>    :-\
>
>Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.
Ну послал, так послал! :) Но раз не указал, куда идти, то иду куда могу и читаю:
"More specifically, traffic shaping is any action on a set of packets (often called a stream or a flow) which imposes additional delay on those packets such that they conform to some predetermined constraint (a contract or traffic profile)."
"Traffic policing is the distinct but related practice of packet dropping and packet marking."

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

41. "Улучшенное конфигурирование ipfw" +/–

Сообщение от Eugen Konkov (?), 09-Май-09, 01:46

> управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь.
Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс.
В 99% случаев говоря "хочу зашейпить вход" кому-то, имеют ввиду "проходящий трафик" мимо роутера.
т.е. зашейпить вход клиенту - это означает зашейпить на выходе из роутера или на входе в роутер.
ipfw может шейпить этот трафик без проблем, а ALTQ только на выходе.
ситуация есть LAN 192.168.1.0/24, 192.168.2.0/24 которые доступны через rl1 и rl2 роутера.
На роутере запущен OSPF и трафик к этим сетям динамически уходит через rl1 или через rl2 в зависимости он загрузки каналов или друхих прочих факторов, которые нам не известны.
ipfw легко можно зашейпить трафик к этим сетям собирая пакеты на входе в роутер (rl0):
ipfw pipe 1 config bw 512Kbit/s mask dst-ip 0xffffff00
ipfw add 1 pipe 1 all from any to 192.168.1.0/24 in recv rl0
ipfw add 1 pipe 1 all from any to 192.168.2.0/24 in recv rl0
И нас не заботит через какой интерфейс/интерфейсы пойдет пакет дальше.
Реализовать в ALTQ такое невозможно, т.к. на rl2 и rl1 это две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик к LAN's будет уходить через rl1 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl2 на скорость 384Кбит/с. А так как трафик будет распределятся между двумя каналами каким-то случайным образом, то я вообще не представляю как можно сделать такое с помощью ALTQ.
В догонку:
http://www.nabble.com/altq-td18171872.html#a23453905

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

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

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

Партнёры:

Хостинг:

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

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

8. "Улучшенное конфигурирование ipfw"	+/–
Сообщение от Sem (ok), 26-Июн-08, 18:57
Блин, режет глаз слово "ложить". И опечатки. И вообще... Вся тема про недостаток ALTQ мягко говоря спорная. Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических целях. И фраза про разделение входящего канала поровну - технически не грамотная. Можно создать иллюзию придерживая часть трафика, но к каналу это не имеет отношения.
Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Andrew Kolchoogin (?), 26-Июн-08, 20:21
	> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических > целях. _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_. Это "альфа" и "омега" всего управления трафиком в TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да пожалуйста, хоть сто раз. Канал у вас по входу как на полке был, так на полке и останется (это я в вашу сторону "ping -f" пустил :). Да, можно влиять на вход, шейпя исход: TCP -- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. И до тех пор, пока такие вот безграмотные статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали по объявлениям". :-\
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Sem (ok), 26-Июн-08, 20:42
	>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических >> целях. > > _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_. Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только криво это и с трудом можно придумать этому оправдание. О чем и речь.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Andrew Kolchoogin (?), 26-Июн-08, 22:31
	> Под входящим тут имеется в виду не тот трафик, который идет в > интерфейс, а тот, который пришел, но еще не передан на обработку. > Почему его "_нельзя_" зашейпить? Потому что. Его можно только заполисить. Не передать на дальнейшую обработку, если он транзитный. Но _каналам_ твоим от этого ни горячо, ни холодно. > Можно. Нельзя. > Только криво это и с трудом можно придумать этому оправдание. О чем и речь. Речь о безграмотности автора статьи. :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Осторожный (?), 26-Июн-08, 21:57
	>> Возможно кому то и захочется шейпить входящий трафик, но только в очень экзотических >> целях. > > _Шейпить_ входящий трафик _нельзя_. Его можно только _резать_. входящий траффик можно шейпить, если он уже пришел, он еще не отдан далее на обработку - например в локальную сеть > > > Это "альфа" и "омега" всего управления трафиком в >TCP/IP-сетях. Распоряжаться можно только _своей_ жо... ой, то есть, управлять можно >только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. >Да хоть весь вход пакетным фильтром в /dev/null сливайте -- да >пожалуйста, хоть сто раз. Канал у вас по входу как на >полке был, так на полке и останется (это я в >вашу сторону "ping -f" пустил :). тем не менее твои входящие ping можно ограничить по скорости - с какой скоростью они будут попадать на мой интерфейс >[оверквотинг удален] > Да, можно влиять на вход, шейпя исход: TCP >-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, >превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. > > > И до тех пор, пока такие вот безграмотные >статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали >по объявлениям". > > :-\ ха-ха
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	17. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Andrew Kolchoogin (?), 26-Июн-08, 22:29
	> тем не менее твои входящие ping можно ограничить по скорости > - с какой скоростью они будут попадать на мой интерфейс Нет. (C) Фарид Вагапов, если тут еще хоть кто-то помнит, кто это такой. Я зуб даю с пломбой, что мои пинги будут попадать на твой интерфейс ровно с той скоростью, с которой я их посылаю. Не быстрее, и не медленнее. Это они в твой TCP/IP-стек могут не попадать. Но _каналу_ от этого легче не станет. Dixi.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Осторожный (?), 27-Июн-08, 00:43
	>> тем не менее твои входящие ping можно ограничить по скорости >> - с какой скоростью они будут попадать на мой интерфейс > > Нет. (C) Фарид Вагапов, если тут еще хоть >кто-то помнит, кто это такой. > > Я зуб даю с пломбой, что мои пинги >будут попадать на твой интерфейс ровно с той скоростью, с которой >я их посылаю. Не быстрее, и не медленнее. Вот зуб не надо. По дороге между источником ping-ом и firewall многое может случиться - например их может drop-нуть или задержать проходящий роутер. > > Это они в твой TCP/IP-стек могут не попадать. >Но _каналу_ от этого легче не станет. Dixi. Каналу легче не станет, но про канал речи и не было вовсе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Andrew Kolchoogin (?), 27-Июн-08, 10:17
	>> Я зуб даю с пломбой, что мои пинги >> будут попадать на твой интерфейс ровно с той скоростью, с которой >> я их посылаю. Не быстрее, и не медленнее. > Вот зуб не надо. > По дороге между источником ping-ом и firewall многое может случиться > - например их может drop-нуть или задержать проходящий роутер. Угу, или не справиться мой TCP/IP-стек посылать пакеты с такой скоростью, чтобы выложить _мой_ канал на полку. :) Разумеется, имелся в виду ping flood с directly-connected router'а.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от mFF (?), 04-Июл-08, 11:49
	>тем не менее твои входящие ping можно ограничить по скорости >- с какой скоростью они будут попадать на мой интерфейс > Бгы гы Ограничивать можно только то что УЖЕ пришло. Ограничивать "скорость попадания на твой интерфейс" можно только на вышестоящем роутере. Почитал бы ты что-нибудь о защите от DDOS-атак что ли.
	Ответить \| Правка \| К родителю #14 \| Наверх \| Cообщить модератору


	15. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от migosm (?), 26-Июн-08, 22:20
	>[оверквотинг удален] > Да, можно влиять на вход, шейпя исход: TCP >-- протокол с подтверждением приема, PUSH'и не будут идти со скоростью, >превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. > > > И до тех пор, пока такие вот безграмотные >статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали >по объявлениям". > > :-\ Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	30. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Sem (??), 27-Июн-08, 11:54
	>[оверквотинг удален] >>превышающей скорость ACK'ов. Но это _частный_ случай. UDP так не пошейпить. >> >> >> И до тех пор, пока такие вот безграмотные >>статьи будут появляться в Интернете, будут жить системные администраторы класса "набрали >>по объявлениям". >> >> :-\ > >Андрей прав. Все нижепишущие прочтите разницу между Policing и Shaping. Ну послал, так послал! :) Но раз не указал, куда идти, то иду куда могу и читаю: "More specifically, traffic shaping is any action on a set of packets (often called a stream or a flow) which imposes additional delay on those packets such that they conform to some predetermined constraint (a contract or traffic profile)." "Traffic policing is the distinct but related practice of packet dropping and packet marking."
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Улучшенное конфигурирование ipfw"	+/–
	Сообщение от Eugen Konkov (?), 09-Май-09, 01:46
	> управлять можно >только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_. >Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь. Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс. В 99% случаев говоря "хочу зашейпить вход" кому-то, имеют ввиду "проходящий трафик" мимо роутера. т.е. зашейпить вход клиенту - это означает зашейпить на выходе из роутера или на входе в роутер. ipfw может шейпить этот трафик без проблем, а ALTQ только на выходе. ситуация есть LAN 192.168.1.0/24, 192.168.2.0/24 которые доступны через rl1 и rl2 роутера. На роутере запущен OSPF и трафик к этим сетям динамически уходит через rl1 или через rl2 в зависимости он загрузки каналов или друхих прочих факторов, которые нам не известны. ipfw легко можно зашейпить трафик к этим сетям собирая пакеты на входе в роутер (rl0): ipfw pipe 1 config bw 512Kbit/s mask dst-ip 0xffffff00 ipfw add 1 pipe 1 all from any to 192.168.1.0/24 in recv rl0 ipfw add 1 pipe 1 all from any to 192.168.2.0/24 in recv rl0 И нас не заботит через какой интерфейс/интерфейсы пойдет пакет дальше. Реализовать в ALTQ такое невозможно, т.к. на rl2 и rl1 это две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик к LAN's будет уходить через rl1 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl2 на скорость 384Кбит/с. А так как трафик будет распределятся между двумя каналами каким-то случайным образом, то я вообще не представляю как можно сделать такое с помощью ALTQ. В догонку: http://www.nabble.com/altq-td18171872.html#a23453905
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору