Пример того как можно ограничить скорость на интерфейсе:#!/bin/sh
kldload ng_ether
kldload ng_carngctl -f- <<-EOF
mkpeer re0: car lower lower
name re0:lower re0_car
connect re0: re0_car: upper upper
msg re0_car: setconf { upstream={ cbs=8192 ebs=65535 cir=100000 greenAction=1 yellowAction=1 redAction=2 mode=2 } downstream={ cbs=8192 ebs=65535 cir=1000000 greenAction=1 yellowAction=1 redAction=2 mode=2 } }
EOF
Если считать что к re0 у нас подключен клиент, то upstream это трафик от клиента в инет,
downstream - трафик из инета к клиенту.cir - скорость в битах в секунду (в мане опечатка)
mode=2 - это RED
цифры для cbs/ebs взяты с потолка. Рекомендации по поводу этих
параметров можно поискать в инете по ключевым словам random early detection
можно тут посмотреть например
http://www.icir.org/floyd/REDparameters.txt
URL: http://ospf-ripe.livejournal.com/2567.html
Обсуждается: http://www.opennet.me/tips/info/1516.shtml
Параметры RED в ng_car фиксированные и не настраиваются. Описание cbs/ebs можно читать в мануалах циски. cbs при shape рекоментуется порядка 4-8К, ebs не используется.Для скоростей более 5-10Мбит/с может быть оправдано применение rate-limit (mode=3) вместо shape для экономии ресурсов. При этом рекомендуемый cbs - объем трафика за секунду, ebs - объем трафика за полторы секунды.
А смысл этого, если есть pipe/altq?
>А смысл этого, если есть pipe/altq?Pipe и altq это весьма мощные и точные инструмент, однако они по определению жестко привязаны к обработке IP трафика фаерволом (ipfw или pf).
Netgraph же по определению не имеет жестких структур и позволяет на уровне ядра строить любые конфигурации из имеющихся составных частей. Модуль ng_car - это еще один кубик в этот конструктор. Сам по себе он предельно прост и имеет стандартный интерфейс, что позволяет использовать его ведзе, где требуется ограничение скорости передачи, вне зависимости от контекста. Он может работать с чем угодно, от IP до езернетных или PPP фреймов, или вообще с абстрактного потоком байтов.
Лично я использую связку ng_bpf+ng_car под управлением mpd5 для дифференцированного по типу трафика ограничения скорости PPPoE подключений. Простая замена связки ipfw+pipe на эквивалентную связку ng_bpf+ng_car при 500 активных интерфейсах и 50Мбит/c трафика дала двухкратное снижение загрузки роутера за счет избавления от обхода длинного списка ipfw правил. И это еще в режиме shape. Если же перевести ng_car в режим rate-limit, его ресурсоемкость станет вообще нулевой, на уровне нескольких арифметических операций на пакет.
Скажите, а это можно использовать на ng интерфейсах которые создаёт mpd?.. В примере так понимаю использовался физический.
>Скажите, а это можно использовать на ng интерфейсах которые создаёт mpd?.. В
>примере так понимаю использовался физический.Можно, но вот так, руками, этого делать не стоит, сложно. У свежих mpd есть встроенная поддержка ng_car.
pfctl: vlan37: driver does not support altq
Впрочем, Цискины сабинтерфейсы тоже не умеют traffic-shape. :) police умеют, а traffic-shape -- нет. :)
> Впрочем, Цискины сабинтерфейсы тоже не умеют traffic-shape. :) police умеют, а traffic-shape -- нет. :)SB'шные ios'ы умеют (это те что с ISG)
Потому как нужно применять altq на физический интерфейс
altq on bge0 cbq bandwidth 100Mb queue { default_int, test_in, test_out}
queue default_int cbq(default)
queue test_in bandwidth 5Mb cbq(ecn)
queue test_out bandwidth 5Mb cbq(ecn)pass in on vlan222 from <customers> to any queue test_in
pass out on vlan222 from <customers> to any queue test_out