У меня есть Linux-маршрутизатор с интерфейсом 10GBe снаружи и подключенными Gigabit Ethernet-интерфейсами внутри.
В настоящее время у нас есть бюджет на 2 Гбит / с. Если мы превысим эту ставку в среднем более чем на 5% за месяц, то с нас будет взиматься плата за всю пропускную способность 10 Гбит / с. В долларовом выражении это большой шаг вперед.
Итак, я хочу ограничить это 2 ГБит / с на интерфейсе 10 ГБe.
Фильтр TBF может быть идеальным, но этот комментарий вызывает беспокойство.
На всех платформах, кроме Alpha, он может формировать до 1 Мбит / с нормального трафика с идеальной минимальной пакетностью, отправляя данные точно с настроенной скоростью.
Должен ли я использовать TBF или какой-либо другой фильтр для применения этой скорости к интерфейсу, и как мне это сделать. Я не понимаю приведенный здесь пример: HOWTO по управлению трафиком
В частности, «Пример 9. Создание TBF 256 Кбит / с»
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
tc qdisc add dev eth0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps
Как рассчитывается скорость 256 Кбит / с? В этом примере 32000 бит / с = 32 Кбайт в секунду. Поскольку tc использует бит / с = байт в секунду. Я предполагаю, что в игру вступают всплески и лимиты, но как бы вы подбирали разумные числа, чтобы достичь желаемой скорости?
Это не ошибка. Я тестировал это, и он дал скорость, близкую к 256 КБ, но не совсем такую.
РЕДАКТИРОВАТЬ
После большого количества чтения и тестирования я пришел к выводу, что TBF не подходит из-за задействованной полосы пропускания. Какие бы настройки я ни пробовал, я не смог заставить TBF обеспечить пропускную способность> ~ 50 Мбит / с. Согласно lartc.org/lartc.pdf, метод RED лучше подходит для формирования пропускной способности> 100 Мбит / с, поэтому я попытаюсь его использовать.
Однако, выбирая значение для min (т.е. средний размер очереди, при котором маркировка становится возможной). Приведенный пример таков:
Вы должны установить минимальное значение, рассчитав максимальную допустимую базовую задержку при организации очереди, которую вы хотите, и умножить ее на вашу пропускную способность. Например, на моем ISDN-канале 64 Кбит / с мне может потребоваться базовая задержка очереди 200 мс, поэтому я установил min на 1600 байт.
как бы вы выбрали максимально допустимую базовую задержку при организации очереди? Пример для 64 Кбит / с.
Что было бы приемлемо для 2 Гбит / с?
Вы должны выбрать приемлемую задержку очереди в зависимости от типа трафика.
Задержка / стратегия организации очереди - это вопрос типа трафика, а не скорости интерфейса. Например, VOIP, возможно, вообще не стоит ставить в очередь. К сожалению, документация tc RED не очень ясна, вам лучше прочитать некоторую информацию RED на сайте Juniper / Cisco и применить эти знания к tc.
По моему опыту, qdisc TBF легко может ограничить пропускную способность до 1 Гбит / с, поэтому я предполагаю, что он также будет масштабироваться до 2 Гбит / с. Однако для этой работы вам, вероятно, понадобится настоящий ЦП, а не какой-нибудь пограничный маршрутизатор начального уровня. Что-то вроде i3 4 ГГц наверняка хватит.
Попробуйте что-нибудь вроде
tc qdisc add dev "$DEV" root handle 1: \
tbf rate "$UPLINK_RATE" burst "$UPLINK_BURST" latency "$TBF_LATENCY"
где
DEV="$(ip route | grep "^default " | grep -Po "(?<=dev )[^ ]+")"
UPLINK_RATE="2000Mbit"
UPLINK_BURST="6500"
TBF_LATENCY="14ms"
Обратите внимание, что для использования TBF с низкой задержкой может потребоваться ядро PREEMPT (например, Ubuntu linux-lowlatency-hwe-* package), или система может не обработать все эти пакеты.
Смотрите также: https://networkengineering.stackexchange.com/a/54404/36597
Как рассчитывается скорость 256 Кбит / с? В этом примере 32 000 бит / с = [32 000] байтов в секунду.
Да, там математика верна. Если вы видите число, близкое к 256k, вероятно, оно немного ниже. Откуда вы измеряете это число? Если это загрузка вашего браузера или что-то подобное, они не учитывают накладные расходы на заголовки пакетов, но tc считает все.