Jump to content

Recommended Posts

Posted (edited)

Стою перед нелегким выбором: использовать ли на линукс роутерах для шейпинга входящего трафика ifb или же imq. и у того и у другого есть и плюсы, и минусы.

задача - шейпить входящий от клиентов трафик в при схеме влан на пользователя.

итак:

IMQ:

+ гибкая интеграция с iptables (на imq девайс можно завернуть не веть трафик, а только часть), нет проблем с метками MARK

+ корректно работает при наличии NAT

- не включено в текущее ядро, и, видимо, не будет включено

- нужно патчить ядро и iptables

IFB

+ часть ядра начиная с 2.6.16, ничего пачтить не надо, работает из коробки

+ заявляется, что кода меньше, он чище, и т.п. чем в IMQ, и типа идеологически более правильно

- при ingress shaping стоит ДО netfilter, отсюда ряд проблем:

- не понимает iptables MARK (трафик заворачивается до того как пометится)

- проблемы с NAT (веь трафик идет на NAT ip)

----

сейчас использую IFB на debian etch. nat нужен, mark тоже. есть мысли перейти на IMQ. у кого есть какие соображения по теме? стОит ли?

также вопрос стабильности IMQ волнует очень.

Edited by Мартен
Posted (edited)

IMQ тоже работает очень стабильно. Причем давно, так как разработка достаточно древняя.

IFB у себя нормально запустить не смог, правда не очень-то и хотел.

Одного не понимаю, зачем при схеме влан на пользователя они вообще нужны, когда можно спокойно развесится по интерфейсам ?

Edited by Kirya
Posted
IMQ тоже работает очень стабильно. Причем давно, так как разработка достаточно древняя.

IFB у себя нормально запустить не смог, правда не очень-то и хотел.

Одного не понимаю, зачем при схеме влан на пользователя они вообще нужны, когда можно спокойно развесится по интерфейсам ?

может, вы и правы, но мне удобнее показалось повесить шейпер на вход аплинка, по правилу на юзера, чем на каждом интерфейсе клиентском создавать свой. так и полосой можно гибче рулить, кому-то приоритет поставить повыше и т.п.
У меня работает IFB. Проблем не ощущаю, есть NAT.
ifb у меня тоже работает и тоже проблем не ощущаю, за исключением озвученных выше нюансов.

как правильно подружить шейпинг входящего трафика с помощью ifb на том же интерфейсе, на котором есть нат? я пока разумной схемы не нашел

Posted

IMQ тоже работает очень стабильно. Причем давно, так как разработка достаточно древняя.

IFB у себя нормально запустить не смог, правда не очень-то и хотел.

Одного не понимаю, зачем при схеме влан на пользователя они вообще нужны, когда можно спокойно развесится по интерфейсам ?

может, вы и правы, но мне удобнее показалось повесить шейпер на вход аплинка, по правилу на юзера, чем на каждом интерфейсе клиентском создавать свой. так и полосой можно гибче рулить, кому-то приоритет поставить повыше и т.п.

У тебя сейчас через FWMARK трафик идет ?

Что ты не можешь реализовать без IMQ/IFB ? Шейпер на общий канал ?

Какая политика ? HTB ?

Posted (edited)
У тебя сейчас через FWMARK трафик идет ?

Что ты не можешь реализовать без IMQ/IFB ? Шейпер на общий канал ?

Какая политика ? HTB ?

значит так:

есть

роутер; аплинк интерфейс eth0; на eth0 вешается ifb. входящий на eth0 далее роутится по клиентским вланам;

на ifb дисциплина htb

хочется:

приоритеты на воип; резать полосы анлимщикам; трафик юриков ставить приоритетом над физиками;

отдельным низким приоритетом локальный трафик.

как решаю сейчас:

входящий воип вылавливаю по src ip (криво, знаю, хочу fwmark)

исходящий воип - по fwmark, проблем нет

входящий локальный - как выловить не ясно, fwmark не повесить

исходящий локальный - проблем нет

ситуация сильно усложнится, если захочется в схему добавить NAT

--

как решить все это с помощью IMQ ясно, но терзали сомнения по поводу надежности. больше вроде не терзают.

как сделать красиво с ifb пока не понятно.

вот собственно такой ход мыслей. склоняюсь к использованию IMQ

Edited by Мартен
Posted (edited)
значит так:

есть

роутер; аплинк интерфейс eth0; на eth0 вешается ifb. входящий на eth0 далее роутится по клиентским вланам;

на ifb дисциплина htb

хочется:

приоритеты на воип; резать полосы анлимщикам; трафик юриков ставить приоритетом над физиками;

отдельным низким приоритетом локальный трафик.

как решаю сейчас:

входящий воип вылавливаю по src ip (криво, знаю, хочу fwmark)

исходящий воип - по fwmark, проблем нет

входящий локальный - как выловить не ясно, fwmark не повесить

исходящий локальный - проблем нет

ситуация сильно усложнится, если захочется в схему добавить NAT

--

как решить все это с помощью IMQ ясно, но терзали сомнения по поводу надежности. больше вроде не терзают.

как сделать красиво с ifb пока не понятно.

вот собственно такой ход мыслей. склоняюсь к использованию IMQ

    id=$(echo $2|tr -d p)
    id=$((${id}+100))
    buffer=$((${3}/8*2))
    rate=$((${3}*${koeftx}/100))
    upburst=$((${3}*${koeftx}/100/8*60/1024))
    peakrate=$((${3}*10))
    $TC class add dev ifb0 classid 1:${id} parent 1: htb rate ${rate}bit quantum 1600

    #TODO: "red" qdisc

    if [[ "${QDISCTX}" == "sfq" ]]; then
        $TC qdisc add dev ifb0 parent 1:${id} handle ${id}: sfq perturb 5
        QDISCTXDONE=1
    fi

    if [[ "${QDISCTX}" == "fifo" ]]; then
        $TC qdisc add dev ifb0 parent 1:${id} handle ${id}: bfifo limit ${buffer}
        QDISCTXDONE=1
    fi

    if [[ -z "${QDISCTXDONE}" ]]; then
        $TC qdisc add dev ifb0 parent 1:${id} handle ${id}: bfifo limit ${buffer}
    fi


    $TC filter add dev ifb0 protocol ip pref ${id} parent 1: handle ${id} fw classid 1:${id}
    $TC qdisc del dev $2 ingress 1>/dev/null 2>/dev/null
    $TC qdisc add dev $2 ingress

    $TC filter add dev $2 parent ffff: protocol ip prio 10 u32 \
      match u32 0 0 flowid 1:1 \
      action ipt -j MARK --set-mark ${id} \
      action mirred egress redirect dev ifb0

Это из одного из шейперов

$2 - может быть VLAN, в моем случае pppNNN

Edited by nuclearcat
Posted

всем спасибо за ответы.

остановился на IMQ, правда пришлось повозиться с патчами на iptables (хотелось корректно собрать deb пакет с патчем, это оказалось сложнее чем думал), но оно того стоит.если кому интересно как делал, пишите.

сейчас тестирую, все нравится.

Posted

а все-таки, зачем вешать шейпер на убогий ingress, если есть ifb/IMQ ?

они вроде для того и сделаны, чтобы был один _общий_ HTB, например, на

egress ifb0, а на egress всех реальных интерфейсов - перенаправление на ifb0

 

У IMQ есть один серьезный минус - такое впечатление, что баг с локальным трафиком из

 

http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/...w_stable_is_IMQ

 

так и не исправили.

Posted
а все-таки, зачем вешать шейпер на убогий ingress, если есть ifb/IMQ ?

они вроде для того и сделаны, чтобы был один _общий_ HTB, например, на

egress ifb0, а на egress всех реальных интерфейсов - перенаправление на ifb0

а как с натом быть в этом случае? ifb на egress стоит уже после ната. метить каждого юзера mark'ом? не выход.
У IMQ есть один серьезный минус - такое впечатление, что баг с локальным трафиком из

 

http://wiki.nix.hu/cgi-bin/twiki/view/IMQ/...w_stable_is_IMQ

 

так и не исправили.

там говорится про 2.6.7

до сих пор не поправили? 8|

надо попробовать смоделировать ситуацию да проверить.

Posted

Чейчас у меня ядрышко 2.6.20, но вообще '-A POSTROUTING -j IMQ --todev 0' работает уже без проблем уже более года. Я даже и не знал об этой проблеме...

Posted

а ежели в IMQ загонять лишь трафик пришедший с аплинка (в случае, если нужно разрезать полосу аплинка между юзверями) - ни какого локального трафика с сервера не должно туда попать.

  • 1 year later...
Posted

ну вот, почти 2 года стабильного полета с IMQ на 2.6.18 (Debian Etch). Пришла пора переползать на Lenny (2.6.26.2) и соответственно, новые проблемы. Патч linux-2.6.26.8-imq-test2.diff не кладется на дебиновские сорцы. Немного напильника и все наложилось. Если кому надо - модифицированный патч во вложении.

Новое ядро в бою пока погонять не успел, но о результатах постараюсь отписать.

linux_2.6.26.8_imq_test2_lenny.diff.gz

  • 5 months later...
Posted

Вот и у меня возникла необходимость в ограничении ingress трафика на ppp интерфейсах. Сделал через полисинг с drop - работает мягко говоря плоховато (что собственно и ожидалось). Буду пробовать IMQ на Lenny (2.6.26-1-686).

 

2Мартен - как результаты? Еще было бы неплохо посмотреть, как оно настроено :)

Posted (edited)
если это шейпинг ВПНов то с ifb решается просто в лоб.
Да, впн надо шейпить, порядка 500 штук. Как я понял, создается виртуальный интерфейс, командой

action mirred egress redirect dev ifb0

трафик с pppХХХ заворачивается на него и пишутся tc правила для ifb0.

Шейпить ррр требуется с разными скоростями. Для каждого рррХХХ делается ifbХХХ и там режется или всё скидывается в один общий ifb0 и там фильтрами выделяется трафик отдельных впн и режется? И еще нат актуален.

Edited by Gaspar
Posted

Для каждого рррХХХ делается ifbХХХ и там режется

а смысл тогда в ifb? исходящий с ppp к клиенту можно и без ifb пошейпать на этом же ppp, а входящий в ppp шейпается на смотрящем в мир интерфейсе как исходящий с этого интерфейса тоже без ifb

Posted
Для каждого рррХХХ делается ifbХХХ и там режется или всё скидывается в один общий ifb0 и там фильтрами выделяется трафик отдельных впн и режется?
Особо интересно, какой из вариантов производительнее.

 

p.s. Первый варианта однозначно легче реализовать.

Posted (edited)

Вопрос изначально стоял в шейпинге именно ingress трафика и в добавок ко всему с натом, с egress всё ясно и уже давно работает. Шейпинг исходящего с аплинк интерфейса трафика уживается с натом на этом же аплинк интерфейсе? Может есть пример реализации?

Edited by Gaspar
  • 2 months later...
  • 7 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.