Cramac Опубликовано 13 апреля, 2012 (изменено) · Жалоба сервер то у нас держит, только вопрос в том где теряются lcp из за чего клиенты и дропаются...а так на нашем онлайне (400-450) ЦПУ грузится на 0-1% только при включении ndsad от UTM цпу прыгает до 20-30% на другой коллектор(модуль иптайбл) пока не перейти из за невозможности считать на ппп интерфейсах (из цепочки форвард нетфлоу шлет с адресом локальным а не выданным по ппп) единственное не делал такого /sbin/ethtool -A eth2 autoneg off rx off /sbin/ethtool -A eth3 autoneg off rx off /sbin/modprobe igb IntMode=2,2,2,2 RSS=0,0,0,0 сейчас только увеличил очереди: /sbin/ifconfig eth2 txqueuelen 10000 /sbin/ifconfig eth3 txqueuelen 10000 Еще кстати писали про драйвера: # ethtool -i eth2 driver: igbversion: 2.1.0-k2 firmware-version: 1.2-1 bus-info: 0000:01:00.0 Изменено 13 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 13 апреля, 2012 (изменено) · Жалоба сервер то у нас держит, только вопрос в том где теряются lcp из за чего клиенты и дропаются...а так на нашем онлайне (400-450) ЦПУ грузится на 0-1% только при включении ndsad от UTM цпу прыгает до 20-30% на другой коллектор(модуль иптайбл) пока не перейти из за невозможности считать на ппп интерфейсах (из цепочки форвард нетфлоу шлет с адресом локальным а не выданным по ппп) единственное не делал такого /sbin/ethtool -A eth2 autoneg off rx off /sbin/ethtool -A eth3 autoneg off rx off /sbin/modprobe igb IntMode=2,2,2,2 RSS=0,0,0,0 сейчас только увеличил очереди: /sbin/ifconfig eth2 txqueuelen 10000 /sbin/ifconfig eth3 txqueuelen 10000 Еще кстати писали про драйвера: # ethtool -i eth2 driver: igbversion: 2.1.0-k2 firmware-version: 1.2-1 bus-info: 0000:01:00.0 уходить надо вам от ndsad, ip_netflow у нас из форварда выдаёт по ip ppp интерфейса, может в биллинге не правильно настроено, должно выдавать по внутренним ip из диапазона 172.х.х.х, если нат используете Изменено 13 апреля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 13 апреля, 2012 (изменено) · Жалоба то что от него надо уходить было понятно в самом начале его использования... в биллинге(utm5) у нас прописаны ИП типо 192.168.x.x(он же выдается при подключении по ппп) локальные у них адреса из 10.10. или 172.20. если прописать в биллинге ИП равный локальному ИП, то ппп не поднимается (accel) в итоге после теста ip_netflow в биллинг попадает трафик типо интернет 10.10.х.х(172.20.) и наоборот П.С. Но пробовали как с ндсад так и без него, потери одинаковы лцп и он видимо не особо влияет на работу. Изменено 13 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 13 апреля, 2012 · Жалоба то что от него надо уходить было понятно в самом начале его использования... в биллинге(utm5) у нас прописаны ИП типо 192.168.x.x(он же выдается при подключении по ппп) локальные у них адреса из 10.10. или 172.20. если прописать в биллинге ИП равный локальному ИП, то ппп не поднимается (accel) в итоге после теста ip_netflow в биллинг попадает трафик типо интернет 10.10.х.х(172.20.) и наоборот П.С. Но пробовали как с ндсад так и без него, потери одинаковы лцп и он видимо не особо влияет на работу. довольно странно. у нас ipt_netflow настроен как в любой интернет инструкции и работает, у вас биллинг на NAS стоит, или отдельно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 13 апреля, 2012 · Жалоба отдельно. ipt-netflow я вообще не настраивал, загрузил модуль >modprobe ipt_NETFLOW destination=10.10.10.6:9996 добавил правило >iptables -A FORWARD -j NETFLOW и на этом все, в биллинге смотрел, трафика типо 192.168.х.х в инет и обратно нет. форвардс в иптайблс у меня выглядит пока так: ACCEPT all -- 192.168.3.149 anywhere ACCEPT all -- anywhere 192.168.3.149 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 13 апреля, 2012 · Жалоба отдельно. ipt-netflow я вообще не настраивал, загрузил модуль >modprobe ipt_NETFLOW destination=10.10.10.6:9996 добавил правило >iptables -A FORWARD -j NETFLOW и на этом все, в биллинге смотрел, трафика типо 192.168.х.х в инет и обратно нет. форвардс в иптайблс у меня выглядит пока так: ACCEPT all -- 192.168.3.149 anywhere ACCEPT all -- anywhere 192.168.3.149 если его установили правильно то должен работать, проверить можно на сервере iptables -L -n -v | grep NETFLOW, трафик сразу должен показать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 13 апреля, 2012 · Жалоба урезали правила в iptables до десятка правил, все остальное запихнули в ipset (было 1600 правил, получилось 2 и 800 ip в ipset) Посмотрим как пойдет. iptables -L -n -v | grep NETFLOW показывал трафик, нетфлоу шлет в биллинг, но шлет не то что нужно, может и то что нужно но в биллинге надо делать манипуляции...в общем с нетфлоу на потом все... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 13 апреля, 2012 · Жалоба Посоветую использовать tcpdump при отладке сетевого взаимодействия, весьма серьёзно сокращает время. А что за биллинг? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 апреля, 2012 · Жалоба уменьшение правил тоже не помогло. Биллинг НетАп UTM5 (нетап.ру) Остается только tcpdump`ом снимать трафик на сервере и зеркалить порт абонентов, чтоб высмотреть ходят лцп и куда. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 14 апреля, 2012 (изменено) · Жалоба а биллинг с сервером у вас общается через отдельную подсеть, или же через абонентскую в конфигурационном файле utm.cfg netflow_address=0.0.0.0 netflow_port=9996 Изменено 14 апреля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 апреля, 2012 (изменено) · Жалоба отдельная подсеть/влан так же сам сервер в 1 влане (10.10.10.1) а клиенты в других (10.10.1-9.) Изменено 14 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 14 апреля, 2012 (изменено) · Жалоба отдельная подсеть/влан так же сам сервер в 1 влане (10.10.10.1) а клиенты в других (10.10.1-9.) а на физическом уровне на отдельных сетевых, иначе счастья на видать, если вы используете vlan, то тут правила надо писать с учётом vlan, советую разделить сети, или вам жалко портов на коммутаторе. Изменено 14 апреля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 апреля, 2012 · Жалоба физически биллинг с сервером общается через одну и туже сетевую (eth2) Но смысл его вешать на отдельную еще сетевую? там трафика мало идет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 14 апреля, 2012 (изменено) · Жалоба физически биллинг с сервером общается через одну и туже сетевую (eth2) Но смысл его вешать на отдельную еще сетевую? там трафика мало идет. первое безопасность билинга, второе прерывания стого на нужных интерфейсах третье проще писать iptables на входящие и исходящие соединения четвёртое виден форвард с одного интерфейса на другой у нас к примеру 3 разных подсети eth1 инет (можно vlan1 сделать) 197.0.0.1/21 eth2 клиенты (можно vlan2 сделать)10.200.0.1/16 eth3 биллинг (можно vlan3 сделать) 192.254.0.1/24 для доспупа к личному кабинету статический маршрут прописан Изменено 14 апреля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 апреля, 2012 · Жалоба все это хорошо, но пока проблема в другом и хочется ее для начала решить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 апреля, 2012 (изменено) · Жалоба Что то распределял прерывания как по инструкции вышескинутой, в итоге имею: т.е. если смотреть cat /proc/interrupts с задержкой 5-10-30 сек, счетчики бегут там где положено. Но если посмотреть на следующий/через день, по всем ядрам заполняются счетчики причем больше чем там где он бежит смотря с задержкой. Что то не так сделал? П.С. Может стоит поковырять параметры сетевой через ethtool? смущает некоторые строки в : # netstat -sIp: всего пакетов принято 1073316163 82435 с неверными заголовками 1058 с неверными адресами 3142667200 перенаправлено 0 входящих пакетов отклонено входящих пакетов доставлено: 1976793976 запросов отправлено: 1237121505 исходящих пакетов сброшено: 2 фрагментов сброшено после тайм-аута: 62079 требуется повторных сборок: 476679967 пакетов пересобрано удачно: 234800253 пакетов пересобрано неудачно: 6862431 фрагментов получено удачно: 248572618 фрагментов неудачно: 5888582 фрагментов создано: 499532924 Изменено 14 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 14 апреля, 2012 · Жалоба Что то распределял прерывания как по инструкции вышескинутой, в итоге имею: т.е. если смотреть cat /proc/interrupts с задержкой 5-10-30 сек, счетчики бегут там где положено. Но если посмотреть на следующий/через день, по всем ядрам заполняются счетчики причем больше чем там где он бежит смотря с задержкой. Что то не так сделал? П.С. Может стоит поковырять параметры сетевой через ethtool? смущает некоторые строки в : # netstat -sIp: всего пакетов принято 1073316163 82435 с неверными заголовками 1058 с неверными адресами 3142667200 перенаправлено 0 входящих пакетов отклонено входящих пакетов доставлено: 1976793976 запросов отправлено: 1237121505 исходящих пакетов сброшено: 2 фрагментов сброшено после тайм-аута: 62079 требуется повторных сборок: 476679967 пакетов пересобрано удачно: 234800253 пакетов пересобрано неудачно: 6862431 фрагментов получено удачно: 248572618 фрагментов неудачно: 5888582 фрагментов создано: 499532924 Одна очередь на оно ядро, у вас на всех ядрах, прерывания в rc.local запиши и при перезагрузке они встанут на места, примерно так echo 1 > /proc/irq/29/smp_affinity echo 1 > /proc/irq/33/smp_affinity echo 1 > /proc/irq/40/smp_affinity echo 1 > /proc/irq/44/smp_affinity echo 2 > /proc/irq/30/smp_affinity echo 2 > /proc/irq/34/smp_affinity echo 2 > /proc/irq/41/smp_affinity echo 2 > /proc/irq/45/smp_affinity echo 4 > /proc/irq/31/smp_affinity echo 4 > /proc/irq/35/smp_affinity echo 4 > /proc/irq/42/smp_affinity echo 4 > /proc/irq/46/smp_affinity echo 8 > /proc/irq/32/smp_affinity echo 8 > /proc/irq/36/smp_affinity echo 8 > /proc/irq/43/smp_affinity echo 8 > /proc/irq/47/smp_affinity /sbin/sysctl -p Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 14 апреля, 2012 (изменено) · Жалоба я так раскидал после установки сетевой на уже работающем, и после этого не перезагружался. Смысл в том что если сидеть мониторить cat /proc/interrupts то все работает как задумывалось, 1 прерывание на 1 ядро. Но вот на след день зайду, и по всем ядрам счетчики вырастают. Мониторил так: watch --interval=1 'grep eth /proc/interrupts' П.С. в процессах висит /usr/sbin/irqbalance его наверное надо убить? Изменено 14 апреля, 2012 пользователем Cramac Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 14 апреля, 2012 (изменено) · Жалоба я так раскидал после установки сетевой на уже работающем, и после этого не перезагружался. Смысл в том что если сидеть мониторить cat /proc/interrupts то все работает как задумывалось, 1 прерывание на 1 ядро. Но вот на след день зайду, и по всем ядрам счетчики вырастают. Мониторил так: watch --interval=1 'grep eth /proc/interrupts' только после перезагрузки прерывания встанут на места, вручную вводить на работающем сервере вилами писано, irqbalance вообще даже ставить не стоит, вот у вас и косяк вылазит Изменено 14 апреля, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 15 апреля, 2012 · Жалоба П.С. в процессах висит /usr/sbin/irqbalance его наверное надо убить? Естественно, с его убивания любой тюнинг и нужно начинать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 15 апреля, 2012 · Жалоба избавились от всей нагрузки на сервер, потери лцп так и остались. Думается что проблема в клиентах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
info83 Опубликовано 28 апреля, 2012 · Жалоба избавились от всей нагрузки на сервер, потери лцп так и остались. Думается что проблема в клиентах. Как такое может быть, что проблема в клиентах. У нас до accel-ppp стоял Cisco 7200 никаких проблем не было. Мы перешли на accel, из за шейпера (htb). И счас примерно за час 90 обрывов: root@ppp:~# tail -f /var/log/accel-ppp/accel-ppp.log | grep lcp [2012-04-28 09:05:32]: warn: ppp85: lcp: no echo reply [2012-04-28 09:06:20]: warn: ppp51: lcp: no echo reply [2012-04-28 09:06:24]: warn: ppp202: lcp: no echo reply [2012-04-28 09:10:04]: warn: ppp74: lcp: no echo reply Обратно на Cisco перейти уже никак не получится... Тут даже не vlan-ах дела. Пробовал без vlan все равно такие же проблемы. Так то у нас на машине поднят порядка 300 vlan (абонентские). Не знаю ка насчет FreeBSD, говорят там стабильней работает. Кто нибудь подскажет, есть ли в FreeBSD аналог htb, фильтрация по портам (чтоб торрент урезать и т.д.). Заранее благодарю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 1 мая, 2012 · Жалоба дайте нам циску проверить, тогда точно будет видно в чем дело :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
info83 Опубликовано 2 мая, 2012 · Жалоба дайте нам циску проверить, тогда точно будет видно в чем дело :) Хм у тебя такая же проблема. Или решил его? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
info83 Опубликовано 2 мая, 2012 · Жалоба Думаю можно преодолеть данную проблему. Так как зависшие сессии можно определить через биллинг - если долгое время нету (скажем 15 мин) активности, то считаем сессию зависшим и биллинг запускает скрипт - кот. обрывает сессию. А для этого в accell-ppp надо убрать проверку lcp. Но в моем случае есть проблема. Можно ли оборвать сессию не через snmp, а через telnet, netcat и т.д. Написал: echo "terminate if $1" | nc -q0 127.0.0.1 2000 но сессия не обрывается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
