Mechanic Опубликовано 25 сентября, 2009 (изменено) · Жалоба Для шейпа абонов по 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 поправить ? Изменено 25 сентября, 2009 пользователем Mechanic Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 25 сентября, 2009 (изменено) · Жалоба ${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. Изменено 25 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 25 сентября, 2009 · Жалоба очереди поправил, но они не влияют на ситуацию с шейпером по влан, тк используется тругой pipe . с большей скоростью Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 25 сентября, 2009 (изменено) · Жалоба Вы случаем не пускаете трафик последовательно через несколько пайпов? Возможно проблемы с задержками возникают из-за этого. Также стоит избавиться от нагромождения конфигурации на одной машине: vpn-терминатор, вланы, шейпинг. Когда понаворочено много всего, определить источник проблемы гораздо труднее. Для простоты и надежности нужно разносить функционал по отдельным машинам. Изменено 25 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 25 сентября, 2009 · Жалоба нет, тут же явно видно, что траф идет через разные интерфейсы подсети для впн использованы серые, и одна /24 белая для влан используются другие белые /24 попробую отделить вланы от впн Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 27 сентября, 2009 · Жалоба Данная проблема тут уже обсуждалась - поищите. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 27 сентября, 2009 (изменено) · Жалоба помнится читал, никак не думал, что сам столкнусь сейчас попробую найти если у кого есть закладка- запостите адрес плиз вот нашел http://forum.nag.ru/forum/index.php?showto...46103&st=40 кстати Вы задавали такой вопрос по задержке, но что-то решения я так и не увидел в посте. Как Вы разрешили ситуацию с пингами ? Изменено 28 сентября, 2009 пользователем Mechanic Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 сентября, 2009 (изменено) · Жалоба Еще можно HZ в конфиге ядра попробовать увеличить и пересобрать. Максимум до 4000, больше не надо. По идее, уменьшение гранулярности должно приводить к меньшим задержкам при проходе пакетов через token bucket. Изменено 28 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 28 сентября, 2009 · Жалоба Ну вот мне и ответили Я же Вам предлагал поразмышлять...Ну ладно: Гранулярность времени в 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 28 сентября, 2009 · Жалоба перечитывал несколько раз это абзац! почему при vpn-pptp такой проблемы -нет ? Используете ng_car+ipfw ,на каждого абона создается нода ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 28 сентября, 2009 · Жалоба перечитывал несколько раз это абзац!почему при vpn-pptp такой проблемы -нет ? Используете ng_car+ipfw ,на каждого абона создается нода ? Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.Да на каждого абонента создается нода, самописные скрипты на perl. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 сентября, 2009 (изменено) · Жалоба Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.Да на каждого абонента создается нода, самописные скрипты на perl. И трафик классифицируется наверняка с помощью netgraph tablearg. Скажите, а какие пакетрейты/сколько юзеров в этом случае можно обсчитать на одной машине? Интересно сравнить с dummynet. По сути ng_car -- это очередная реализация token bucket, но в виде ноды Netgraph. Изменено 28 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 28 сентября, 2009 · Жалоба перечитывал несколько раз это абзац!почему при vpn-pptp такой проблемы -нет ? Используете ng_car+ipfw ,на каждого абона создается нода ? Мы не используем VPN и прочие PPxxx. Статические внешние IP-адреса.Да на каждого абонента создается нода, самописные скрипты на perl. к такой же схеме и пытаемся привести, но проблемы с шейперомбуду пробовать нарезать полосу через ng_car Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 28 сентября, 2009 · Жалоба подскажите плиз, как реализовывали переход с тарифа на тариф ? удаляли ноду или переконфигурировали ? Если возможно покажите пожалуйста скрипт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 29 сентября, 2009 · Жалоба И трафик классифицируется наверняка с помощью 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-ы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 29 сентября, 2009 (изменено) · Жалоба подскажите плиз, как реализовывали переход с тарифа на тариф ?удаляли ноду или переконфигурировали ? Если возможно покажите пожалуйста скрипт. Очевидно, что не стоит пересоздавать ноду, если ее можно переконфигурировать. Скрипт выкладывать смысла нет - поверьте. Есть модуль самописный Ratelimit.pm и четыре утилиты его использующие, по типу выполняемого действия create/delete/modify/on-boot. Скрипты писал я - поэтому они написаны из рук вон плохо :) Но если - прям надо, отправлю по почте. Изменено 29 сентября, 2009 пользователем Dm1try Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 29 сентября, 2009 (изменено) · Жалоба Сравнивать с dummynet - ИМХО не стоит в dummynet, там динамические pipe-ы. Можно насоздавать кучу статических пайпов, а классифицировать с помощью правил pipe tablearg. Изменено 29 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 30 сентября, 2009 · Жалоба куча статич пайпов приведет к тормозам системы, а использование динамич- пока непонятный вопрос с пингами при малых скоростях (...возможно не умею готовить..) to Dm1try: тк нода создается непосредственно на юзера,соответственно конфигурится скорость по тарифу, по какой причине у вас используется несколько tablearg с разными таблицами и все на 1м интерфейсе ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dm1try Опубликовано 30 сентября, 2009 · Жалоба По 2-е таблицы (входящий/исходящий) на ТП. На одном интерфейсе потому, что так смаршрутизированно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 сентября, 2009 (изменено) · Жалоба куча статич пайпов приведет к тормозам системы, а использование динамич- пока непонятный вопрос с пингами при малых скоростях (...возможно не умею готовить..) С чего это вдруг статические пайпы должны приводить к тормозам? Тормоза не из-за того что в памяти какие-то лишние пайпы висят. Кстати, постоянное создание/удаление динамических пайпов при недостаточном размере хэша -- тоже одна из причин возникновения задержек. Следует убедиться, что net.inet.ip.dummynet.hash_size превышает число пользователей и увеличить эту переменную до нужного значения. Изменено 30 сентября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 30 сентября, 2009 · Жалоба по 2 пайпа на юзера, у меня на насе до 1000 абонов крутится, итого получаем 2000 правил в ipfw, тут уже лучше юзать tablearg с динамич правилами Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 30 сентября, 2009 · Жалоба по 2 пайпа на юзера, у меня на насе до 1000 абонов крутится, итого получаем 2000 правил в ipfw, тут уже лучше юзать tablearg с динамич правилами 2000 пайпов с развитым ветвлением сильной избыточной нагрузки не дадут... у меня вон по 10000 динамических пайпов крутится, и жив пока. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...