LINUX.ORG.RU
Форум — Admin  

tc шейпинг и преоритезация


0

0

Доброго времени суток! Есть такая задача: преоритезировать
общий трафик, уходящий в внешний канал. Преоритезация для каждой подсети
не делается, а используется правило шейпирования конечных классов sfq.
Подскажите пожалуйста, как это лучше организовать, если кто с этим
сталкивался. Схема того как мне видится этот процесс ниже. Там же правила tc.
Как можно организовать узел filter на схеме, или же есть какие-то
более простые варианты?

http://x.caver.ru/s.txt (схема тут)

tc qdisc del dev eth1 root 2> /dev/null > /dev/null
tc qdisc del dev eth1 ingress 2> /dev/null > /dev/null
tc qdisc add dev eth1 root handle 1: htb default 1:12
tc c a dev eth1 parent 1: classid 1:1 htb rate 20mbit burst 6k
tc class a dev eth1 parent 1:1 classid 1:2 htb rate 1024kbit 2048kbit burst 6k prio 1
tc class a dev eth1 parent 1:1 classid 1:3 htb rate 2048kbit 10mbit burst 6k prio 2
tc class a dev eth1 parent 1:1 classid 1:4 htb rate 2048kbit 18mbit burst 6k prio 3
tc class a dev eth1 parent 1:1 classid 1:5 htb rate 128kbit 18mbit burst 6k prio 4
tc class a dev eth1 parent 1:5 classid 1:10 htb rate 6000kbit ceil 18mbit
tc class a dev eth1 parent 1:5 classid 1:11 htb rate 6000kbit ceil 18mbit
tc class a dev eth1 parent 1:5 classid 1:12 htb rate 6000kbit ceil 18mbit
tc qdisc a dev eth1 parent 1:10 handle 10: sfq perturb 10
tc qdisc a dev eth1 parent 1:11 handle 11: sfq perturb 10
tc qdisc a dev eth1 parent 1:12 handle 12: sfq perturb 10
tc f a dev eth1 parent 1:0 protocol ip prio 10 u32 match ip dst 192.168.0.0/24 flowid 1:10
tc f a dev eth1 parent 1:0 protocol ip prio 10 u32 match ip dst 192.168.1.0/24 flowid 1:11
tc f a dev eth1 parent 1:0 protocol ip prio 10 u32 match ip dst 192.168.2.0/24 flowid 1:12

Возможно ли сделать, чтобы если на пример, по сети проходит пакет с
протоколом icmp он перебрасывался из 1:5 в 1:1 , или если порт 1723
происходил переброс из 1:5 в 1:2?


Ответ на: комментарий от mikki

Это и так курю невыдыхая 3 день. В какую сторону смотреть то. Мож свежий взгляд нужен просто.

gich
() автор топика
Ответ на: комментарий от gich

Это был ответ на вторую часть вопроса. Перебрасывать пакет из 1.5 в 1.1 не нужно и нельзя. Можно сразу классифицировать пакет в 1.5 добавлением соответствующего правила перед классификацией по адресам.

mikki
()
Ответ на: комментарий от mikki

#!/bin/bash

#«Очищаем» интерфейс eht1
/sbin/tc qdisc del dev eth1 root handle 1: htb default 15
#Создаем заново дисциплину и указываем дефолтный класс
/sbin/tc qdisc add dev eth1 root handle 1: htb default 15
#Создаем общий для клиентов класс
/sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 10Mbit ceil 10Mbit

#Создаем корневой класс клиента
/sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbit

#Создаем 4 подкласса для каждого из видов трафика
/sbin/tc class add dev eth1 parent 1:10 classid 1:11 htb rate 1kbit ceil 512kbit prio 1
/sbin/tc class add dev eth1 parent 1:10 classid 1:12 htb rate 1kbit ceil 512kbit prio 2
/sbin/tc class add dev eth1 parent 1:10 classid 1:13 htb rate 1kbit ceil 512kbit prio 3
/sbin/tc class add dev eth1 parent 1:10 classid 1:14 htb rate 1kbit ceil 512kbit prio 4

#Создаем дисциплины шейпирования для конечных классов
/sbin/tc qdisc add dev eth1 parent 1:11 handle 11: sfq perturb 10
/sbin/tc qdisc add dev eth1 parent 1:12 handle 12: sfq perturb 10
/sbin/tc qdisc add dev eth1 parent 1:13 handle 13: sfq perturb 10
/sbin/tc qdisc add dev eth1 parent 1:14 handle 14: sfq perturb 10

Создаем 4 фильтра, для каждого из видов трафика
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst 192.168.2.2/32 match ip protocol 1 0xff flowid 1:11
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 2 u32 match ip dst 192.168.2.2/32 match ip protocol 17 0xff flowid 1:12
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 192.168.2.2/32 match ip protocol 6 0xff match ip sport 80 0xffff flowid 1:13
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 4 u32 match ip dst 192.168.2.2/32 flowid 1:14

Вот такое сделать не проблема. Другой вопрос, что в данном случае преоритезация траффика от клиента. А как сделать чтобы после преоритезации от клиента, делалась преоритезация общего канала?

gich
() автор топика
Ответ на: комментарий от gich

>Вот такое сделать не проблема. Другой вопрос, что в данном случае преоритезация траффика от клиента. А как сделать чтобы после преоритезации от клиента, делалась преоритезация общего канала?

Почти первая строчка из LARTC, TC умеет шейпить только исходящий трафик. Отсюда вывод, приоритезировать надо _также_ и трафик на выходе из внешнего/внутреннего интерфейса.

gh0stwizard ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin