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

kaN5300

Активный участник
  • Публикации

    137
  • Зарегистрирован

  • Посещение

Все публикации пользователя kaN5300


  1. Угу, когда сессия отвалится по тайм-ауту. Или у вас нет ограничений на кол-во сессий с учетки? Тайм-аут <= 60 секунд. Ей богу. Один дисконнект у 1/5 авторизованных абонентов раз в 45 суток не повод для паники.
  2. И вам абоны за такой "сервис" мозг не вынесли? У абонентов происходит обычный реконнект к свободному соседнему серверу. Они ничего не замечают.
  3. Короче, приобрели новый сервак на ксеончике четырехядерном. Поставили 9.0 amd64, обновили до STABLE, убрав из ядра лишние устройства и IPV6. В ipfw сейчас всего три основных правила, через которые льется львиная доля трафика. Таблица с 3k записей используется только в одном правиле из этих трех и с указаничем "in recv igb1". В час пик было 630 туннелей. При этом средний load average 1.0, максимальный 2.0. Максимальный kpps: 38. Начинаем отсчет бесперебойной работы. Аналогичные работы по удалению из ядра ipv6 и ненужных девайсов проведены еще на двух серверах, один из которых успел уже проработать более двух недель без перезагрузок. Всего у нас щас 3 наса под 9.0-STABLE (из них один на i386) и два на 7.4-STABLE i386 с ядром GENERIC. 7.Х работает уже давно и периодичность зависания в среднем реже одного раза в месяц.
  4. Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'. Я вот как раз после оптимизации ipfw начал применять одно правило с ng* в продакшене. Посмотрим как себя поведет система.
  5. У нас кстати тоже квагга используется (0.99.20_3) но она строго к igb0 привязана для общения с L3 коммутаторами и принятия от них маршрутов в локалку. Про нетграф она знать ничего не должна. К моменту ввода ipv6 мы планируем вобще отказаться от ната и туннелирования. Сервера доступа к тому времени переквалифицируются во что-то другое.
  6. <kan5300@nas1>uptime 2:39PM up 12 days, 2:09, 2 users, load averages: 0.52, 0.59, 0.64 Кажется проблема обнаружена! Регулярные ребуты (1.5 ребута за неделю в среднем) происходили изза GENERIC-ядра с активированным по-умолчанию IPv6. Закомментили поддержку всяких ненужных устройств и "#options INET6". Как видно из аптайма, в среду будет две недели непрерывной работы. PS: спасибо Hawk128 за совет
  7. Присматриваем юнипроцессорную конфигурацию для очередного сервера доступа. Заинтересовала технология Data Direct I/O в обновленных ксеонах Пишут что за счет прямой работы NIC с кэшем производительность удастся поднять на 10-20 процентов. При этом никакой дополнительной поддержки со стороны сетевухи или софта не требуется. Про сроки появления на прилавках серии 1ХХХ ничего не известно в то время как на ЯМ уже масса предложений по сериям 2XXX.
  8. 3750 и BGP

    У икса оперативки больше и фичи прикольные вроде второго блока питания хот-свап.
  9. Маркетинг здесь замешан по-любому. Жаль нет сравнительного тестирования для загруженных маршрутизаторов в открытом доступе. У нас на топовом Core i7 при 50% idle на всех ядрах наблюдается подозрительный рост load average. При этом весь тюнинг igb необходимый сделан, очереди грамотно раскидываются по ядрам и т.д. Где-то явно образуется bottleneck и это не nic и не cpu.
  10. 3750 и BGP

    У нас 3750X к трем пирам подключено. Совокупный трафик доходит до 1.5 Гбит. Маршрутов принято < 8k. Работает шустро и стабильно.
  11. Пришло письмо от Роскомнадзора с предложением провести предупредительные мероприятия, направленные на защиту несовершеннолетних детей от информации причиняющей вред их здоровью (436-ФЗ, который пока не вступил в силу) и о проделанной работе отчитатья. Кто что думает по этому поводу?
  12. Придумали комплексное решение в виде ddwrt+opendns. Юзер покупает dir-400 и заказывает услугу "внешний ip-адрес". После чего отдает нам роутер под настройку. dd-wrt умеет блокировать p2p (проверяли, работает) и несколько url по регулярным выражениям (тоже проверяли). Создается учетка для opendns где выбираются группы для ограничения. Можно это всё дополнить KIS или бесплатным аналогом.
  13. И еще вопрос. Посоветуйте железку для end user'а, которая на L7 могла бы резать торренты и работать с ACL-ами по URL. Сам пока еще в рынок таких устройств не вникал, но спрос уже идет.
  14. Кто занимался подробным исследованием софта для РК. Что можете посоветовать? У нас заключен договор с касперычем на перепродажу их софта. Могли бы предлагать клиентам KIS в составе которого вроде как уже есть какие средства РК.
  15. Регламентирует. Перечень - на сайте Минюста. Но порева там нет, ибо никто не обащался в суд с просьбой заблочить порево в конкретном месте. Алле, в правовом государстве живем или как? Пора и стоит делать УСЛУГУ "несколько более чистый Интернет", за социально разумные деньги ;) С соответствующим юридическим и техническим обвесом. И обсчетом ;) Прошу указать ссылку. Не нашел =(
  16. Мне жаль их клиентов... Самый главный вопрос состоит в том что влась не регламентирует конкретный перечень ресурсов для блокировки.
  17. Всем привет! Сейчас складывается такая ситуация, что наши поставщики, которые нам ранее продавали сервера доступа (самопал на 1U / Core i7) заявляют о дефиците верхних i7 (Gulftown) в связи с падающим спросом и таком же дефиците i7 (Sandy Bridge-E) в связи с ограниченными поставками. Решили надёргать железок по поставщикам и собрать самим. Сразу возникает два вопроса: 1. Нормальная система охлаждения. Пассивный медный радиатор типа такого http://mdata.yandex.net/i?path=b1113223922_img_id8941922418757641336.jpg Под нужный сокет найти не удалось и к тому же, как я понимаю, просто закрепить не достаточно. Надо еще чтоб медные трубки уходили куда-то в систему продува БП. Где взять совместимые компоненты? 2. Мамка будет обычная десктопная форм-фактора mini-ATX или просто ATX. Подойдет ли райзер с PCI-X к планке расширения на корпусе чтобы засунуть сетевуху или легко может оказаться что всё "поедет"?
  18. Следует частоту этих сбросов выявить, может в этом и есть причина. С l2tp или pppoe никогда не работал, зато к пятой ветке mpd вобще никаких претензий нет.
  19. Вобщем я переработал секцию свою вот так: 10000 4093424 4164152915 Wed Mar 7 15:54:55 2012 allow ip from any to not me in recv igb1 10001 280390 71526402 Wed Mar 7 15:54:55 2012 allow ip from table(3) to any out xmit igb1 10005 7719146 5372732262 Wed Mar 7 15:54:55 2012 allow ip from any to any via ng* Последней строкой открываем трубу для всех ng-нод, первой строкой разрешаем входящий трафик на внешний интерфейс для всех адресов назначения кроме тех, которые назначены непосредственно на igb1 и второй строчкой делаем рестрикции для пользователей с отрицательным балансом отфильтровывая их еще перед nat-трансляцией. Как видно по счетчикам, table3 с 5к записями используется в том месте, где количество совпадений минимально. Вроде оптимизировать эту часть уже некуда. Этим постом я запускаю новый отчет бесперебойной работы сервера доступа. количество установленных ppp соединений, т.е на каждом c 7.3 по ~900, на 9.0 ~600, хотя dns все насы отдает равномерно Времени больше суток прошло? Может быть юзеры специально дисконнектятся от 9.0 так как ощущают лаги в работе (если они есть).
  20. Что означает - пик количества сессий? Количество авторизованных абонентов или установленных tcp-соединений? vmstat просто показывает прерывания.
  21. net.link.ether.inet.proxyall=1 Вот за счет этого белые pptp адреса видят инет. Дело в том, что маршрутизации никакой нету. Достаточно весь трафик с наса направить на стандартный шлюз из этой же подсети. Можно конечно поизвращаться и сделать DMZ, но такой вариант у нас обкатан годами и всем устраивает.
  22. В этом плане всё нормально, NAS с бордером в одной подсети, активные туннели белые через прокси-арп видны на циске. С этим проблем нет.
  23. Про внешних я забыл и только щас вспомнил. На насе установлен белый IP. Нас выполняет шейпинг, нат, pptp, netflow. Буду перестраивать на ng* завтра утром. Пока всё вернул взад.
  24. Сомневаюсь, что load average или еще что подскочит так что будет заметно на глаз. Меня волнует прежде всего стабильность работы, по этому спустя пару перезагрузок при текущем конфиге попробую указать ng* в своих правилах.