Перейти к содержимому
Калькуляторы

freebsd dummynet большие задержки в пингах

Для шейпа абонов по vpn-pptp используем конструкцию dummynet

 

${IPFW} pipe 20 config bw ${BW_128}Kbit/s mask src-ip 0xffffffff  # bm=128kbit
${IPFW} pipe 22 config bw ${BW_256}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=256kbit
${IPFW} pipe 24 config bw ${BW_512}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=512kbit
${IPFW} pipe 28 config bw ${BW_2M}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=2Mbit
${IPFW} pipe 30 config bw ${BW_4M}Kbit/s mask src-ip 0xffffffff delay -100ms  queue 100  # bm=4Mbit
${IPFW} pipe 32 config bw ${BW_8Mb}Mbit/s mask src-ip 0xffffffff delay -100ms queue 100   # bm=8Mbit

${IPFW} add pipe tablearg all from "table(3)" to any in via  ${VPN_IFACES}

${IPFW} pipe 21 config bw ${BW_128}Kbit/s mask dst-ip 0xffffffff  # bw=128kbit
${IPFW} pipe 23 config bw ${BW_256}Kbit/s mask dst-ip 0xffffffff delay -100ms queue 100  # bw=256kbit
${IPFW} pipe 25 config bw ${BW_512}Kbit/s mask dst-ip 0xffffffff delay -100ms  queue 100 # bw=512kbit
${IPFW} pipe 29 config bw ${BW_2M}Kbit/s mask dst-ip 0xffffffff delay -100ms  queue 100 # bw=2Mbit
${IPFW} pipe 31 config bw ${BW_4M}Kbit/s mask dst-ip 0xffffffff delay -100ms  queue 100 # bw=4Mbit
${IPFW} pipe 33 config bw ${BW_8Mb}Mbit/s mask dst-ip 0xffffffff delay -100ms queue 100  # bw=8Mbit

${IPFW} add pipe tablearg all from any to "table(2)" out via  ${VPN_IFACES}

 

сейчас неско

сейчас несколько абонов подкл непосредственно по ethernet, дописав правил

#vlan170
#${IPFW} add pipe  tablearg all from "table(9)"  to any in via ${eth_inet0_iface}
${IPFW} add  allow all from ${eth_inet0_net} to any in via  ${eth_inet0_iface}
${IPFW} add  allow all from ${eth_inet_net} to any out via  ${inet_if}

#in traffic
${IPFW} add  allow all from any  to ${eth_inet_net} in via ${inet_if}
#vlan170
${IPFW} add pipe tablearg all from any to "table(8)" out via  ${eth_inet0_iface}
${IPFW} add  allow all from any  to ${eth_inet0_net} out via ${eth_inet0_iface}

те используются теже конфиги pipe для шейпа по vlan, что и по vpn

 

но при допустим тарифе в 1мбит по впн - получаем стабильные пинги до 100мс, а по влану прыгующий пинг до 400-500мс

 

почему такое может происходить ?

может какие-нить настройки sysctl поправить ?

Изменено пользователем Mechanic

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

${IPFW} pipe 20 config bw ${BW_128}Kbit/s mask src-ip 0xffffffff # bm=128kbit

${IPFW} pipe 22 config bw ${BW_256}Kbit/s mask src-ip 0xffffffff delay -100ms queue 100 # bm=256kbit

 

Длины очередей слишком большие, для таких малых скоростей нужно уменьшить хотя бы до 20 пакетов. Кроме того нужно установить net.inet.ip.dummynet.io_fast=1.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

очереди поправил, но они не влияют на ситуацию с шейпером по влан, тк используется тругой pipe . с большей скоростью

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы случаем не пускаете трафик последовательно через несколько пайпов? Возможно проблемы с задержками возникают из-за этого. Также стоит избавиться от нагромождения конфигурации на одной машине: vpn-терминатор, вланы, шейпинг. Когда понаворочено много всего, определить источник проблемы гораздо труднее. Для простоты и надежности нужно разносить функционал по отдельным машинам.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

нет, тут же явно видно, что траф идет через разные интерфейсы

подсети для впн использованы серые, и одна /24 белая

для влан используются другие белые /24

попробую отделить вланы от впн

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Данная проблема тут уже обсуждалась - поищите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

помнится читал, никак не думал, что сам столкнусь

сейчас попробую найти

если у кого есть закладка- запостите адрес плиз

 

вот нашел http://forum.nag.ru/forum/index.php?showto...46103&st=40

кстати Вы задавали такой вопрос по задержке, но что-то решения я так и не увидел в посте.

Как Вы разрешили ситуацию с пингами ?

Изменено пользователем Mechanic

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще можно HZ в конфиге ядра попробовать увеличить и пересобрать. Максимум до 4000, больше не надо. По идее, уменьшение гранулярности должно приводить к меньшим задержкам при проходе пакетов через token bucket.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вот мне и ответили

Я же Вам предлагал поразмышлять...

Ну ладно:

 

Гранулярность времени в dummynet'е при стандартном ядре (HZ=1000) 1ms, т.е. 64Kbit/s это 64Bit/ms. В Вашем примере размер пакета 1500 байт

(1472 + 8 + 20 = 1500, a не 1480, как Вы полагаете, но это здесь не Важно), т.е. 1500*8=12Kbit. 12Kbit через трубу с пропускной способностью 64Bit/tick без задержек проехать никак не могут.

 

Можно посчитать, какая должна быть задержка: 12000/64 = 187.5ms в одну сторону. В Вашем примере есть и обратная труба, т.е. задержка

на Ваши пинги должна быть 187.5 * 2 = 375ms.

Знакомая цифра? ;)

Для себя я решил проблему переходом на ng_car.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

перечитывал несколько раз это абзац!

почему при vpn-pptp такой проблемы -нет ?

Используете ng_car+ipfw ,на каждого абона создается нода ?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

перечитывал несколько раз это абзац!

почему при vpn-pptp такой проблемы -нет ?

Используете ng_car+ipfw ,на каждого абона создается нода ?

Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.

Да на каждого абонента создается нода, самописные скрипты на perl.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.

Да на каждого абонента создается нода, самописные скрипты на perl.

И трафик классифицируется наверняка с помощью netgraph tablearg. Скажите, а какие пакетрейты/сколько юзеров в этом случае можно обсчитать на одной машине? Интересно сравнить с dummynet. По сути ng_car -- это очередная реализация token bucket, но в виде ноды Netgraph.
Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

перечитывал несколько раз это абзац!

почему при vpn-pptp такой проблемы -нет ?

Используете ng_car+ipfw ,на каждого абона создается нода ?

Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.

Да на каждого абонента создается нода, самописные скрипты на perl.

к такой же схеме и пытаемся привести, но проблемы с шейпером

буду пробовать нарезать полосу через ng_car

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

подскажите плиз, как реализовывали переход с тарифа на тариф ?

удаляли ноду или переконфигурировали ?

Если возможно покажите пожалуйста скрипт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И трафик классифицируется наверняка с помощью netgraph tablearg. Скажите, а какие пакетрейты/сколько юзеров в этом случае можно обсчитать на одной машине? Интересно сравнить с dummynet. По сути ng_car -- это очередная реализация token bucket, но в виде ноды Netgraph.

 

В самой плохой конфигурации примерно ~150Kpps

 

Вот эта конфигурация - 7.0-RELEASE-p12

# ngctl list
There are 635 total nodes:

 

#ipfw show
02300   netgraph tablearg ip from table(11) to any out via vlan5
02400   netgraph tablearg ip from any to table(10) in via vlan5
02500   netgraph tablearg ip from table(16) to any out via vlan5
02600   netgraph tablearg ip from any to table(15) in via vlan5
02700   netgraph tablearg ip from table(21) to any out via vlan5
02800   netgraph tablearg ip from any to table(20) in via vlan5
02900   netgraph tablearg ip from table(26) to any out via vlan5
03000   netgraph tablearg ip from any to table(25) in via vlan5
03100   netgraph tablearg ip from table(31) to any out via vlan5
03200   netgraph tablearg ip from any to table(30) in via vlan5
03300   netgraph tablearg ip from table(36) to any out via vlan5
03400   netgraph tablearg ip from any to table(35) in via vlan5
03500   netgraph tablearg ip from table(41) to any out via vlan5
03600   netgraph tablearg ip from any to table(40) in via vlan5
03700   netgraph tablearg ip from table(45) to any out via vlan5
03800   netgraph tablearg ip from any to table(46) in via vlan5
65535 328167268897 165734160073033 allow ip from any to any

 

Ну и top:

last pid: 56714;  load averages:  0.55,  0.38,  0.27                                                                                                                                     up 77+00:00:30  08:52:47
83 processes:  5 running, 62 sleeping, 16 waiting
CPU states:  0.0% user,  0.0% nice,  7.7% system,  0.4% interrupt, 91.9% idle
Mem: 26M Active, 234M Inact, 283M Wired, 56K Cache, 214M Buf, 3372M Free
Swap: 2048M Total, 2048M Free

  PID USERNAME  PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
   12 root      171 ki31     0K    16K CPU2   2 1818.6 100.00% idle: cpu2
   13 root      171 ki31     0K    16K CPU1   1 1793.9 100.00% idle: cpu1
   14 root      171 ki31     0K    16K RUN    0 1789.2 99.56% idle: cpu0
   11 root      171 ki31     0K    16K CPU3   3 1195.4 54.94% idle: cpu3
   27 root      -68    -     0K    16K -      3 612.1H 45.06% em2 taskq
   15 root      -44    -     0K    16K WAIT   3 159.2H  1.46% swi1: net

 

Иногда em2 tasq - поднимается до 60%, но я вообще не слежу что там за трафик и прочее.

Если случится em2 tasq - 100%, то:

развести IN/OUT по разным vlan-ам c различными физическими интерфейсами, шейпить out;

Если снова случится em2 tasq - 100%, то:

перезагрузиться с яндекс драйверами по два потока на ядро.

 

Максимально мне удавалось содать 4000 нод.

Вообще есть идея уйти даже ipfw и переписать на ng_bpf + ng_car - но это не скоро будет, знаний пока маловато.

 

Сравнивать с dummynet - ИМХО не стоит в dummynet, там динамические pipe-ы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

подскажите плиз, как реализовывали переход с тарифа на тариф ?

удаляли ноду или переконфигурировали ?

Если возможно покажите пожалуйста скрипт.

Очевидно, что не стоит пересоздавать ноду, если ее можно переконфигурировать.

Скрипт выкладывать смысла нет - поверьте.

Есть модуль самописный Ratelimit.pm и четыре утилиты его использующие, по типу выполняемого действия create/delete/modify/on-boot.

Скрипты писал я - поэтому они написаны из рук вон плохо :)

 

Но если - прям надо, отправлю по почте.

Изменено пользователем Dm1try

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сравнивать с dummynet - ИМХО не стоит в dummynet, там динамические pipe-ы.

Можно насоздавать кучу статических пайпов, а классифицировать с помощью правил pipe tablearg.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

to Dm1try: тк нода создается непосредственно на юзера,соответственно конфигурится скорость по тарифу, по какой причине у вас используется несколько tablearg с разными таблицами и все на 1м интерфейсе ?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По 2-е таблицы (входящий/исходящий) на ТП.

На одном интерфейсе потому, что так смаршрутизированно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

С чего это вдруг статические пайпы должны приводить к тормозам? Тормоза не из-за того что в памяти какие-то лишние пайпы висят. Кстати, постоянное создание/удаление динамических пайпов при недостаточном размере хэша -- тоже одна из причин возникновения задержек. Следует убедиться, что net.inet.ip.dummynet.hash_size превышает число пользователей и увеличить эту переменную до нужного значения.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

по 2 пайпа на юзера, у меня на насе до 1000 абонов крутится, итого получаем 2000 правил в ipfw, тут уже лучше юзать tablearg с динамич правилами

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

по 2 пайпа на юзера, у меня на насе до 1000 абонов крутится, итого получаем 2000 правил в ipfw, тут уже лучше юзать tablearg с динамич правилами

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.