iproute2 /sbin/tc: дропается часть трафика
Здравия всем!
И опять у меня возникла проблема с задолбавшим уже pptp :) только теперь при работе совместно с шейпером tc. Ситуация следующая: pptp сервер, к нему коннектится клиент, при поднятии интерфейса на оный через скрипт /etc/ppp/ip-up навешивается правило шейпера
/sbin/tc qdisc add dev $1 handle ffff: ingress /sbin/tc filter add dev $1 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate 512kbit burst 120k drop flowid :1 /sbin/tc qdisc add dev $device root handle 1: htb default 10 r2q 10 /sbin/tc class add dev $device parent 1:1 classid 1:10 htb rate 1024kbit ceil 1024kbit burst 120k
при закачке чего либо скорость шейпится как надо, но если паралельно запустить пинг (приоритетов трафика не настраивал) то видно, что пакеты теряются. Да и pptp на сервере сыпет в лог такую байду:
pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138278 (expecting 1138277, lost or reordered) pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138279 (expecting 1138277, lost or reordered) pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138280 (expecting 1138277, lost or reordered) pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138281 (expecting 1138277, lost or reordered) pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138282 (expecting 1138277, lost or reordered) pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138283 (expecting 1138277, lost or reordered) pptp[26783]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 1138284 (expecting 1138277, lost or reordered)
гугление (да и здравая логика тоже) подсказало, что это теряются куски пакетов и пакеты приходят не того размера. которого ожидалось. А задача состоит в том, чтобы трафик не дропался, а так сказать "придерживался", ну чтобы небыло такой уж откровенной потери пакетов. Есть уверенность, что косяк в шейпинге: если снимаю его, то все становится ок. Подскажите плиз, какое из правил кривое?
P.S. Просьба не отправлять в гугл - только что оттуда, и не спихивать на чтение man'ов - снабжен ими в достатке, но еслиб мог разобраться сам - не писал бы сюда
Спасиб заранее всем кто поможет!
- Для комментирования войдите или зарегистрируйтесь
Ну подкиньте хоть одну идею,
Ну подкиньте хоть одну идею, если не жалко :)
Это вполне нормальная
Это вполне нормальная реакция. Пакеты не помещаются в буфер очереди и дропятся. Это естественное положение вещей.
Помнится prio преподаватель в универе нам объяснял как ведро с дыркой, сколько воды в него не лей, сквозь дырку она будет течь с определенным расходом зависящим, в бОльшей мере, от размера дырки в ведре. А что если в ведро перелить воды, объяснять не надо.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
"Придерживать" трафик
"Придерживать" трафик невозможно. Можно только дропать. Если у канала есть ширина, то придерживать трафик в надежде, что его станет меньше нельзя - пользователь будет думать, что трафик проходит и слать еще больше. Можно только дропать, чтоб пользователь увидел, что больше не лезет и снизил скорость.
Зато есть разные политики
Зато есть разные политики дропа.
Да, приоритеты трафика
Да, приоритеты трафика настраивать надо. А задавший вопрос сказал, что их он не настраивал.
Да... Каэш печально, что оно
Да... Каэш печально, что оно так... Но раз вы говорите, что приоретизация трафика поможет сгладить эту проблему, то посоветуйте если можно какие нибудь статьи и доки, иллюстрирующие какой нибудь простейший пример приоретизации, чтобы хоть в общих чертах осмыслить как оно все работает и понять, "с какого края" начинать читать маны по tc :)
tc qdisc add dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 100
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 4000kbit ceil 4000kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:100 htb rate 256kbit ceil 4000kbit prio 3
tc qdisc add dev eth0 parent 1:10 handle 10: sfq
tc qdisc add dev eth0 parent 1:11 handle 11: sfq perturb 5
tc filter add dev eth0 parent 1:0 protocol ip prio 0 u32 match ip protocol 1 0xff flowid 1:10 <--- приоритет пингам
tc qdisc add dev eth4 root handle 1: htb default 100
tc class add dev eth4 parent 1: classid 1:1 htb rate 4000kbit
echo 1
tc class add dev eth4 parent 1:1 classid 1:10 htb rate 512kbit ceil 4000kbit prio 1
tc class add dev eth4 parent 1:1 classid 1:100 htb rate 512kbit ceil 4000kbit prio 1
echo 2
tc qdisc add dev eth4 parent 1:10 handle 10: sfq perturb 5
tc filter add dev eth4 parent 1:0 protocol ip prio 0 u32 match ip protocol 1 0xff flowid 1:10