Ограничение пропускной способности интерфейса с tc под Linux

8

У меня есть роутер linux, который имеет интерфейс 10GBe снаружи и связанный Gigabit Ethernet интерфейс внутри.

В настоящее время у нас есть бюджет на 2 Гбит / с. Если мы превысим этот показатель более чем на 5% в среднем за месяц, то с нас будет взиматься вся пропускная способность 10 Гбит / с. Довольно шаг вверх в долларовом выражении.

Итак, я хочу ограничить это до 2 Гбит / с на интерфейсе 10 ГБе.

Фильтр TBF может быть идеальным, но этот комментарий вызывает беспокойство.

На всех платформах, кроме Alpha, он способен формировать до 1 Мбит / с нормального трафика с идеальной минимальной нагрузкой, отправляя данные точно с настроенными скоростями.

Должен ли я использовать TBF или какой-либо другой фильтр, чтобы применить эту скорость к интерфейсу и как мне это сделать. Я не понимаю приведенный здесь пример: Traffic Control 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 использует bps = байт в секунду. Я думаю, что в игру вступают взрыв и лимит, но как бы вы выбрали разумные числа для достижения желаемой скорости?

Это не ошибка. Я проверил это, и он дал скорость, близкую к 256К, но не совсем так.

РЕДАКТИРОВАТЬ

После большого чтения и тестирования я пришел к выводу, что TBF не подходит из-за задействованной пропускной способности. Независимо от настроек, которые я пробовал, я не мог получить TBF для обеспечения пропускной способности> ~ 50 Мбит / с. Согласно lartc.org/lartc.pdf, метод RED лучше подходит для формирования полосы пропускания> 100 Мбит / с, поэтому я попытаюсь использовать это.

Однако, выбирая значение для min (т.е. Средний размер очереди, при котором маркировка становится возможной). Пример приведен так:

Вы должны установить минимальное значение, рассчитав максимально допустимую задержку в очереди, которую вы хотите, и умножить ее на свою пропускную способность. Например, на моем канале ISDN со скоростью 64 кбит / с мне может потребоваться базовая задержка в очереди 200 мс, поэтому я установил минимальное значение 1600 байт.

Как бы вы выбрали максимально допустимую задержку в очереди? Пример для 64 кбит / с.
Что было бы приемлемо для 2Гбит / с?

— Matt
источник

2

Вы должны выбрать приемлемую задержку в очереди в зависимости от типа трафика.
- Например, для голосовой очереди более 200 мс - это уже проблема.
- Хотя наличие буфера 500 мс для трафика ftp / torrent не является большой проблемой.
Задержка в очереди / стратегия - это вопрос типа трафика, а не скорости интерфейса. Например, VOIP, возможно, вообще не должен стоять в очереди. К сожалению, документация по tc RED не очень понятна, вам лучше прочитать некоторую информацию по RED на сайте Juniper / Cisco и применить эти знания к tc.

— Alex_www
источник

1

Как рассчитывается скорость 256 Кбит / с? В этом примере 32 000 бит / с = [32 000] байтов в секунду.

Да, математика там верна. Если вы видите число, близкое к 256 КБ, возможно, оно немного ниже. Откуда вы измеряете это число? Если ваш браузер загружен или что-то подобное, они не учитывают издержки заголовков пакетов, а tcучитывают все.

— Джефф Ферланд
источник

Хорошая точка зрения. Я использовал iperf.

— Мэтт

1

По моему опыту, qdisc TBF легко может ограничить полосу пропускания до 1 Гбит / с, поэтому я предполагаю, что она также будет масштабироваться до 2 Гбит / с. Тем не менее, вам, вероятно, понадобится реальный процессор для этой работы, а не какой-нибудь пограничный маршрутизатор. Что-то вроде 4 ГГц i3 наверняка будет достаточно.

Попробуйте что-то вроде

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 (например, linux-lowlatency-hwe-*пакет Ubuntu ), иначе система может не обработать все эти пакеты.

Смотрите также: https://networkengineering.stackexchange.com/a/54404/36597

— Микко Ранталайнен
источник

Спасибо. Я забыл об этом вопросе. Я нашел ответ, и у меня был сценарий, который это сделал. Но я покинул компанию и не могу опубликовать решение сейчас. Однако да, я считаю, что это был TBF, который я использовал, и да, маршрутизатор был быстрым сервером xeon.

— Мэтт