Ограничение траффика

[lutik]

Доброго дня уважаемым.

Дайте плз. общую информацию по след. вопросу.
Имеется роутер FreeBSD6.2 с разноскоросными интерфейсами ( маршрутизирует из ethernet в E1 ). При работе в таком режиме существует эффект так называемого "горла" - когда пакеты из 100Мбит ethernet должны идти в, ну скажем 128Кбит, синхронный канал. Понятно что лишнее нужно дропить. Пытался организовать сей дроп в драйвере сетевого устройства - не эфективно, из-за наличия фрагментированых пакетов, когда отбрасываются фрагменты, требуется повторная пересылка и тд.. Короче траффик либо растет немеряно, либо вовсе все умирает.

Поиски навели на ALTQ+pf, токма курение манов никак не можне дать ответ на три главных вопроса

1) Сможет ли такая связка сделать разумный дроп с учетом фрагментации пакетов (нету в altq wred-а тока red)
2) Можно ли создать правила, жестко задающие приоритет пакетов поддержания соединения ppp наивысшим
3) В идеале хотелось бы приоритетность траффика иметь ( VoIP video ssh и тд) тоесть QoS хочется. Сможет ли такая тулза обеспечить??

Кернел с altq собрал. первая проба была на pf с таким конфигом

ext_if = "ng0"

altq on $ext_if cbq bandwidth 64Kb queue{ std_q, pri_q }
queue std_q bandwidth 80% priority 1 qlimit 48 cbq(default rio ecn)
queue pri_q bandwidth 20% priority 7 qlimit 2 cbq(borrow)

#pass out on $ext_if inet proto icmp keep state
#pass out on $ext_if keep state queue(std_q)
pass out on $ext_if keep state

вроде как работает (правда пока неудовлетворительно).

Вобщем подскажите плз. в правильном ли направлении двигаюсь??

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[schizoid]

а это не подходит?
http://rrv.firstvds.ru/wiki/index.php/QoS_FreeBSD

[lutik]

а это не подходит?
http://rrv.firstvds.ru/wiki/index.php/QoS_FreeBSD

пасиб. почитаю.
чесно говоря идея с altq нравится больше, потому как DUMMYNET есть надстройка над шедулером пакетов с сетевой подсистеме, а altq и есть альтернативный шедулер (по крайней мере по коду его примерно так выходит)..
тоесть с altq должно быстрее работать.
к тому же где-то читал что pf щас более интенсивно развивается, но всеравно спасибо.

Вообще хотелось бы услышать мнение использовавших связку из первого поста..
сравнить так сказать

[lutik]

Появились вот первые конкретные вопросы.

значит все еще FreeBSD6.2 кернел с altq.

имеется горло ether 100Mbit/s -> serial 64kBit/s --> ppp Cisco

pf настроен так (пока простейший вариант для ознакомления)

ppp_if = "ng0"

altq on $ppp_if cbq bandwidth 60Kb queue{ std_q }
queue std_q qlimit 50 cbq(default red ecn)
pass out on $ppp_if queue(std_q)

правил никаких нет - просто ограничение полосы

простенький тест - через роутер идет ping -s 8192 10.0.0.2
где 10.0.0.2 - адрес на втором конце ppp соединения (cisco)

картина наблюдается такая

Код: Выделить всё

8200 bytes from 10.0.0.2: icmp_seq=5661 ttl=254 time=4147.789 ms
8200 bytes from 10.0.0.2: icmp_seq=5663 ttl=254 time=4167.064 ms
8200 bytes from 10.0.0.2: icmp_seq=5667 ttl=254 time=4011.392 ms
8200 bytes from 10.0.0.2: icmp_seq=5673 ttl=254 time=3758.091 ms
8200 bytes from 10.0.0.2: icmp_seq=5674 ttl=254 time=3868.187 ms
8200 bytes from 10.0.0.2: icmp_seq=5675 ttl=254 time=3977.251 ms
8200 bytes from 10.0.0.2: icmp_seq=5678 ttl=254 time=3913.838 ms
8200 bytes from 10.0.0.2: icmp_seq=5679 ttl=254 time=4022.945 ms
8200 bytes from 10.0.0.2: icmp_seq=5680 ttl=254 time=4131.804 ms
8200 bytes from 10.0.0.2: icmp_seq=5683 ttl=254 time=3950.212 ms

тоесть вроде как пакеты действительно отбрасываются.
Но на циске в дебаге видно такое (самый типичный пример)

Код: Выделить всё

*Aug 22 13:48:04.934: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]  ->> 1
*Aug 22 13:48:05.134: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:05.334: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:05.534: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:05.734: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:05.846: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 824 link[ip]
*Aug 22 13:48:05.846: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504            ->> 2
*Aug 22 13:48:05.850: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:05.850: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:05.850: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:05.850: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:05.850: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 824
*Aug 22 13:48:06.042: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]  ->> 3
*Aug 22 13:48:06.242: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:06.442: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:06.642: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:06.846: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:07.046: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:07.246: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:07.358: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 824 link[ip]
*Aug 22 13:48:07.554: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:07.754: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:07.954: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:08.154: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:08.266: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 824 link[ip]
*Aug 22 13:48:08.466: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]   ->> 4
*Aug 22 13:48:08.666: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:08.866: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:09.066: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:09.266: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 1504 link[ip]
*Aug 22 13:48:09.378: Se0/1/0:1 PPP: I pkt type 0x0021, datagramsize 824 link[ip]
*Aug 22 13:48:09.378: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504              ->> 5
*Aug 22 13:48:09.382: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:09.382: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:09.382: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:09.382: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 1504
*Aug 22 13:48:09.382: Se0/1/0:1 PPP: O pkt type 0x0021, datagramsize 824

1-2 нормально отработанные запрос/ответ
3 получаются фрагменты пакета без окончания или без начала и отбрасываются
4 начало нерезанного пакета
5 отклик

тоесть в канале было 13-ть!!!!!!!!!!!!!!!!!!!! фрагментов которые заведомо не несли в себе полезной инфы, но pf их пропустил.
этож ахереть можно.. или это неизбежно..
просветите малограмотного.

и второй вопрос - в http://house.hcn-strela.ru/BSDCert/BSDA ... l#pf-queue прочитал

Код: Выделить всё

Правила основаны на заголовках пакетов сетевого и транспортного уровней модели OSI (см. OSI). Наиболее часто используемые критерии — адреса источника и назначения, номера портов источника и назначения, протоколы.

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

[OSBoy]

существует эффект так называемого "горла" - когда пакеты из 100Мбит ethernet должны идти в, ну скажем 128Кбит, синхронный канал. Понятно что лишнее нужно дропить.

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

Всё же, имхо, смотри второй пост!

[dip]

имеется горло ether 100Mbit/s -> serial 64kBit/s --> ppp Cisco

канал конечно не большой, думаю про VoIP можно забыть на время. У себя на данный момент посредством ALTQ и PF огранизовал такую схему:

локальная сеть <-> cервер <-> ADSL модем <-> ISP

На интерфейсе, который смотрит в локальную сеть, огранизовал классификацию и приоритизацию входящего трафика. Полосу разделил на LAN и WAN, последней в свою очередь дал максимальный приоритет и ограничил скорость до ширины канала, разделив её поровну на пользователей с возможностью borrow.

На виртуальном pppoe интерфейсе, как было из начально остался приоритезированный и классифицированный исходящий трафик. Здесь как раз и огранизовывался QoS, жаль конечно, что в PF нет такого как в IPTables дополнения layer-7, которое неплохо определяет P2P трафик, но бороться всё-же удаётся с помощью TOS меток, которые в PF назначаются queue (que_def,que_prio).

Схему выбрал такую, так как не вышло на одном интерфейсе организовать распределение входящего и исходящего трафика в очереди, хотя пробовал долго и усердно. Но в литературе описано, что такое исполнима и даже запихнуть трафик проходящий через другой интерфейс в очередь, на совсем другом интерфейсе. В iptables понралось система, когда в моём случае, трафик идущий с локальной сети в интернет, физически и програмно проходит по всем интерфейсам, и на любом промежуточном интерфейсе им можно управлять. В PF такого не заметил, даже с включеный параметром set state-policy if-bound.

Насчёт фрагментации, всё это решается с помощью самого PF, там есть нормализация трафика (scrub). С его помощью вы сможите сделать все нужные вам задачи. Насчёт red, ALTQ имеет значительно больше параметров и множество из низ остаются не документированы, особенно в русских переводах...

[Alex Keda]

честно говоря не понимаю - чем dummynet не устраивает?

[lutik]

честно говоря не понимаю - чем dummynet не устраивает?

хороше быть Лисом админом -> подчиненный и начальник в одном лице. Никто моск не парит.
Есть у мну начальство которое и вырабатывает стратегию изделия. Кроме того, openBSD интересная система и вполне возможно что когда нибудь (мое мнение) или даже в скором будущем (возможное мнение начальства) может осуществится миграция туда.

канал конечно не большой, думаю про VoIP можно забыть на время.

да канал это тестовый, его конфижить до любой ширины (4Mb max) с любым шагом можно.

У себя на данный момент посредством ALTQ и PF огранизовал такую схему:
локальная сеть <-> cервер <-> ADSL модем <-> ISP

На интерфейсе, который смотрит в локальную сеть, огранизовал классификацию и приоритизацию входящего трафика. Полосу разделил на LAN и WAN, последней в свою очередь дал максимальный приоритет и ограничил скорость до ширины канала, разделив её поровну на пользователей с возможностью borrow.

На виртуальном pppoe интерфейсе, как было из начально остался приоритезированный и классифицированный исходящий трафик. Здесь как раз и огранизовывался QoS, жаль конечно, что в PF нет такого как в IPTables дополнения layer-7, которое неплохо определяет P2P трафик, но бороться всё-же удаётся с помощью TOS меток, которые в PF назначаются queue (que_def,que_prio).

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

и еще вопрос.. как подбирали длинну очереди??
У меня на графиках ПОЛОСА_ПРОПУСК = f(t, traf_in) имеются сильные всплески, хотя задержка вроде небольшая.

[Alex Keda]

честно говоря не понимаю - чем dummynet не устраивает?

хороше быть Лисом админом -> подчиненный и начальник в одном лице. Никто моск не парит.

у меня тоже есть начальство.

[KaiZz]

Парень юзай altq, dummynet сосёт
А ответ на твой вопрос подробно описан в мане

Код: Выделить всё

Интерфейс ng_iface поддерживает особенность управления полосой пропускания ALTQ. Как - когда-либо, ng_iface - особый случай, так как это не физический интерфейс с ограниченной полосой пропускания. Нельзя повернуть ALTQ на ng_iface, если последний соответствует некоторой tunneled связи, например. PPPoE или PPTP. В этом случае ALTQ должен формироваться на интерфейсе, который используется, чтобы передать скрытые пакеты. В случае, если, когда Ваш граф заканчивается с некоторой последовательной линией, или синхронной или модем, тогда ng_iface - правильное место, чтобы включить ALTQ. 

[freeman]

Можно поподробнее с этого места ?
Есть rl0 скажем с неназначенным IP соединённая с ADSL модемов работающим бриджем и соотв. при поднятии PPPoE сессии получаем интерфейс tun (я так понимаю "прямой" родственник ng). Так что на rl0 можно altq включать или на tun ?