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

Настройка сетевых служб, маршрутизации, фаерволлов. Проблемы с сетевым оборудованием.
Правила форума
Убедительная просьба юзать теги [code] при оформлении листингов.
Сообщения не оформленные должным образом имеют все шансы быть незамеченными.
lutik
мл. сержант
Сообщения: 75
Зарегистрирован: 2007-04-24 13:56:23
Откуда: Odessa

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

Непрочитанное сообщение lutik » 2007-08-22 11:26:56

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

Дайте плз. общую информацию по след. вопросу.
Имеется роутер 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

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

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

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2460 рублей (8 CPU, 8Gb RAM, 2x500Gb HDD, RAID 3ware 9750):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Аватара пользователя
schizoid
подполковник
Сообщения: 3228
Зарегистрирован: 2007-03-03 17:32:31
Откуда: Украина, Чернигов
Контактная информация:

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

Непрочитанное сообщение schizoid » 2007-08-22 11:46:29

а это не подходит?
http://rrv.firstvds.ru/wiki/index.php/QoS_FreeBSD
ядерный взрыв...смертельно красиво...жаль, что не вечно...

lutik
мл. сержант
Сообщения: 75
Зарегистрирован: 2007-04-24 13:56:23
Откуда: Odessa

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

Непрочитанное сообщение lutik » 2007-08-22 12:09:18

schizoid писал(а):а это не подходит?
http://rrv.firstvds.ru/wiki/index.php/QoS_FreeBSD
пасиб. почитаю.
чесно говоря идея с altq нравится больше, потому как DUMMYNET есть надстройка над шедулером пакетов с сетевой подсистеме, а altq и есть альтернативный шедулер (по крайней мере по коду его примерно так выходит)..
тоесть с altq должно быстрее работать.
к тому же где-то читал что pf щас более интенсивно развивается, но всеравно спасибо.

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

lutik
мл. сержант
Сообщения: 75
Зарегистрирован: 2007-04-24 13:56:23
Откуда: Odessa

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

Непрочитанное сообщение lutik » 2007-08-22 15:58:54

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

значит все еще 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
сержант
Сообщения: 228
Зарегистрирован: 2007-04-09 12:17:50
Откуда: Из капусты

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

Непрочитанное сообщение OSBoy » 2007-08-22 16:45:07

lutik писал(а):существует эффект так называемого "горла" - когда пакеты из 100Мбит ethernet должны идти в, ну скажем 128Кбит, синхронный канал. Понятно что лишнее нужно дропить.
lutik писал(а):но не видел об упоминмнии полей приоритета пакета а сильно нужно голосовой трафик выделить
или может не там читаю??
Всё же, имхо, смотри второй пост! :wink:

dip
проходил мимо
Сообщения: 1
Зарегистрирован: 2007-08-25 14:58:55

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

Непрочитанное сообщение dip » 2007-08-25 15:29:52

имеется горло 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
стреляли...
Сообщения: 35068
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

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

Непрочитанное сообщение Alex Keda » 2007-08-25 22:43:34

честно говоря не понимаю - чем dummynet не устраивает?
Убей их всех! Бог потом рассортирует...

lutik
мл. сержант
Сообщения: 75
Зарегистрирован: 2007-04-24 13:56:23
Откуда: Odessa

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

Непрочитанное сообщение lutik » 2007-08-27 10:39:06

lissyara писал(а):честно говоря не понимаю - чем dummynet не устраивает?
хороше быть Лисом админом -> подчиненный и начальник в одном лице. Никто моск не парит.
Есть у мну начальство которое и вырабатывает стратегию изделия. Кроме того, openBSD интересная система и вполне возможно что когда нибудь (мое мнение) или даже в скором будущем (возможное мнение начальства) может осуществится миграция туда.
dip писал(а):канал конечно не большой, думаю про VoIP можно забыть на время.
да канал это тестовый, его конфижить до любой ширины (4Mb max) с любым шагом можно.
dip писал(а): У себя на данный момент посредством 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
стреляли...
Сообщения: 35068
Зарегистрирован: 2004-10-18 14:25:19
Откуда: Made in USSR
Контактная информация:

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

Непрочитанное сообщение Alex Keda » 2007-08-27 11:15:18

lutik писал(а):
lissyara писал(а):честно говоря не понимаю - чем dummynet не устраивает?
хороше быть Лисом админом -> подчиненный и начальник в одном лице. Никто моск не парит.
у меня тоже есть начальство.
Убей их всех! Бог потом рассортирует...

KaiZz
проходил мимо

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

Непрочитанное сообщение KaiZz » 2008-04-03 0:00:18

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

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

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

Аватара пользователя
freeman
лейтенант
Сообщения: 734
Зарегистрирован: 2007-03-18 5:13:25

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

Непрочитанное сообщение freeman » 2008-06-05 9:16:41

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