Jump to content
Калькуляторы

ingress shaping: IMQ vs IFB

IMQ удобнее в использовании, но требует наложения патчей. А IFB есть в ядре.

Лучше - шейпить прямо на eth-интерфейсах и на отдельной машине)

Share this post


Link to post
Share on other sites

IMQ удобнее в использовании, но требует наложения патчей. А IFB есть в ядре.

Лучше - шейпить прямо на eth-интерфейсах и на отдельной машине)

кстати, в одной из соседних веток рекомендовали шейпить на bridge (на freebsd).

а реально ли такое сделать на линуксе?

Share this post


Link to post
Share on other sites

кстати, в одной из соседних веток рекомендовали шейпить на bridge (на freebsd).

а реально ли такое сделать на линуксе?

Конечно реально, почему нет?

Share this post


Link to post
Share on other sites

Не хотел плодить темы, по этому решил написать сюда - есть стенд с Debian на котором пытаюсь поднять необходимую конфигурацию:

1. Из нескольких интерфейсов каналы должны соединяться в один

2. Пользователи пока что за НАТом

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

 

Для простоты понимания процессов, стенд имеет только 2 интерфейса, eth1 - смотрит в локалку, eth0 - смотрит в мир.

Нужно порезать интернет согласно полосы в обе стороны (upload/download) и оставить локалку не тронутой.

 

Пробовал сделать на ifb, но netfilter не маркирует пакеты согласно ID пользователя. u32 - работает только для исходящего (со стороны пользователя) трафика, потому что входящий dst не равен пользовательскому IP адресу изза НАТа. Как быть? Желательно чтоб решение было производительным.

Share this post


Link to post
Share on other sites

Пробовал сделать на ifb, но netfilter не маркирует пакеты согласно ID пользователя. u32 - работает только для исходящего (со стороны пользователя) трафика, потому что входящий dst не равен пользовательскому IP адресу изза НАТа. Как быть? Желательно чтоб решение было производительным.

Чтобы было масштабируемое решение, нужно разнести шейпинг и NAT на отдельные машины, а маршрутизацию вланов перевести на L3-коммутатор.

Edited by photon

Share this post


Link to post
Share on other sites

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

 

либо локальный трафик заворачивать весь на отдельный ifb где не использовать шейпера, а пропускать всё как есть

Share this post


Link to post
Share on other sites

А несколько интерфейсов в сторону клиентов или в сторону интернета?

Если я правильно понял, и в сторону клиентов, то зачем там вообще объединение трафика на одном интерфейсе - повесьте по шейперу на всех клиентских интерфейсах и все. Локалку не ограничивать можно одним правилом на шейпере, для этого тем более не нужен ifb.

Share this post


Link to post
Share on other sites

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.