Назад | Перейти на главную страницу

Linux Traffic Control: как установить приоритеты трафика с помощью моста и qdisc?

Я пытаюсь установить приоритеты трафика через программный мост на базе Linux в моей сети. Когда я генерирую трафик локально (на машине, на которой установлен мост), трафик распределяется правильно. Однако «удаленный» трафик (от других узлов, проходящих через мост) не имеет приоритета (одинаковое распределение полосы пропускания для всех отправителей). Может кто знает почему?

Мост настроен для сетевого адаптера I350 следующим образом (Linux 5.1.8-1-MANJARO # 1 SMP PREEMPT вс, 9 июня 20:44:14 UTC 2019 x86_64 GNU / Linux):

brctl addbr br0
ip link set dev enp1s0f0 promisc on
ip link set dev enp1s0f1 promisc on
ip link set dev enp1s0f2 promisc on
ip link set dev enp1s0f3 promisc on

brctl addif br0 enp1s0f0
brctl addif br0 enp1s0f1
brctl addif br0 enp1s0f2
brctl addif br0 enp1s0f3

ip link set dev br0 up

tc qdisc del dev enp1s0f0  root
tc qdisc add dev enp1s0f0  root prio
tc qdisc del dev enp1s0f1  root
tc qdisc add dev enp1s0f1  root prio
tc qdisc del dev enp1s0f2  root
tc qdisc add dev enp1s0f2  root prio
tc qdisc del dev enp1s0f3  root
tc qdisc add dev enp1s0f3  root prio

ip addr add 192.168.1.1/24 dev br0

UDP-трафик создается с помощью iperf3 и путем установки поля TOS соответствующим образом, например.

Low-Prio Sender: iperf3 -c 192.168.1.140 -u -b 100m -S 0x2 -p 5201 -t 30
Hi-Prio Sender : iperf3 -c 192.168.1.140 -u -b 100m -S 0x0 -p 5202 -t 30

Prio map остается с настройками по умолчанию: priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Приоритезация работает для удаленного трафика, если я явно классифицирую трафик:

tc filter add dev enp1s0f1 parent 1: protocol ip prio 10 u32 match ip dst 192.168.1.140 match ip dport 5201 0xffff flowid 1:1
tc filter add dev enp1s0f1 parent 1: protocol ip prio 20 u32 match ip dst 192.168.1.140 match ip dport 5202 0xffff flowid 1:2

но не с настройками по умолчанию .... Может быть, это проблема уровня 2 / уровня 3?

Я прочитал исходный код мостового планировщика и планировщика очереди prio. И у меня есть результаты:

  • Prio qdisc использует skb->priority поле для классификации пакетов с помощью priomap.
  • По умолчанию skb-priority поле не заполняется для транзитных кадров L2.
  • Итак, правильный способ - добавить классификатор к каждому порту моста, чтобы классифицировать кадры по полю ToS / DSCP.
  • По умолчанию priomap выглядит как 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1.
  • Такое же сопоставление ToS с полосой очереди может быть выполнено с помощью классификатора (дескриптор корневого qdisc 1:0, поэтому дочерние классы будут иметь classid из диапазона 1:1 - 1:3):
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x00 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x02 classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x04 classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x06 classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x08 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x0a classid 1:3
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x0c classid 1:1
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x0e classid 1:1
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x10 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x12 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x14 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x16 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x18 classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x1a classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x1c classid 1:2
tc filter add dev eth0 parent 1: protocol ip flower ip_tos 0x1e classid 1:2

А пока мне удалось найти решение :)

Мост Linux (brctl) работает как устройство уровня 2.

Маркировка TOS является частью IEEE P802.1p (который принадлежит IEEE_802.1Q) и принадлежит заголовку IP (https://en.wikipedia.org/wiki/IEEE_802.1Q)

Поскольку мост Linux работает на уровне 2, кажется, что он игнорирует это поле. (однако, согласно модели OSI https://en.wikipedia.org/wiki/OSI_model 802.1Q принадлежит Уровню 2) Следовательно, все пакеты были направлены в один и тот же класс qdisc (в моем классе настройки 1: 2) Я понял это с помощью следующей команды:

tc -s -s -d c ls dev enp1s0f1

который позволяет вам наблюдать очереди для разных классов qdisc во время выполнения. Позже мой «удаленный» трафик был запланирован как трафик из класса 1: 2 с другими потоками (например, «локальные» потоки с машины, на которой установлен мост), что привело к правильным результатам в некоторые варианты использования ..... так что будьте осторожны! ;)

Что сработало для меня, так это мост между сетевыми соединениями с прокси-ARP (то есть обеспечение уровня 3, https://wiki.debian.org/BridgeNetworkConnectionsProxyArp)

Сначала активируйте переадресацию IP и прокси-сервер.

echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 > /proc/sys/net/ipv4/ip_forward

а затем добавьте маршруты к вашим узлам:

ip ro add <node IP>/32 dev <local interface>

пример:

    ip ro add 192.168.1.12/32 dev enp1s0f0