NiTr0

1) у вас еженедельно вырезают кабели? 2) Актуализация по косвенным признакам (типа мак-адреса, мигрировавшего с порта А на порт Б) при случаях форс-мажора - для вас некошерно? 3) Сколько абонентов, не использовавших свой пароль более N времени (скажем, более 2-3 месяцев), его вспомнит? Сколько из абонентов потеряло/выкинуло свой договор, т.к. он им не нужен? Объясните мне, накой заставлять каждого абона при подключении нового устройства либо даже вообще просто так, при простое более N времени, поднимать договора и вбивать свои логины-пароли, когда прекрасно можно обойтись без этого? И кто из крупняка занимается таким мазохизмом? Даже у киевстара такого почему-то нет...

Удобство пользователя в первую очередь, снижение нагрузки на саппорт тупыми вопросами "ой, а я пароль забыл" во вторую очередь, исключение пользования коллективной халявой в третью очередь. Визуальное отслеживание кабеля либо идентификация по косвенным признакам (мак-адресу и т.п.), опять же с последующим сопоставлением абона и порта. К слову, подобные акты вандализма не такие уж и частые явления. Единичные случаи уж никак не стоят создавания абонентам головняка. Ибо если есть 2 прова, и у первого из них инет работает сразу же, стоит включить комп, а второй - ставит всяческие туннели, а еще хуже - кривые софтины-авторизаторы, либо при включении нужно запускать браузер и вводить где-то логин-пароль, когда пользователь хочет просто по скайпу пообщаться - при прочих равных абоненты будут бежать от второго прова к первому. Ибо первый повернут к абонентам лицом, второй - совершенно другим местом. Ладно, если нет тех. возможности авторизации по порту - это еще понятно. Но намеренно создавать абонентам лишние сложности, потому что не можете обеспечить порядок в своем кабельном хозяйстве - идиотизм ИМХО.

Как все печально однако у вас в сети... Повторю еще раз краткую схему: есть привязка абонент-порт. Есть кабели с бирками, на каждой бирке указан номер квартиры. Есть технический контроль, уже по факту, попыток авторизаций, и сообщение любых подозрительных случаях (к примеру, появление на порту мак-адреса, висевшего до этого на соседнем порту этого свича). Есть диспетчер, который анализирует подобные сообщения, сопоставляет их с проведенными работами, и при необходимости (к примеру, зафиксированное событие было после проведения работ) высылает монтажника с заданием выяснить, кто куда включен, при выявлении несоответствия - вносит изменения в таблицу включений абонов и пишет рапорт начальнику о несанкционированном переключении абонента предыдущей бригадой, работавшей на узле. Есть начальник, который разбирается с рапортом, вызывает на ковер монтажников и при необходимости дежурившего в ту смену диспетчера, выясняет, кто из них виновен, и наказывает. 1-2 инцидентов для самого дубового монтажника будет достаточно, чтобы усвоить: тыкать кабель куда ни попадя, не сообщив об этом диспетчеру, нельзя. Абоненты довольны, сеть под контролем, заведомо известно, в каком порту вставлен определенный абонент и из какого порта отключать абона если он не пользуется более услугой. Потому повторяю еще раз вопрос: накой в этой схеме авторизация?

А какой % будет отключившихся, из тех, у кого "акция" окончилась? Особенно если будут в ЧНН проблемы со скоростью из-за перегрузки внешних каналов? Если на обычном пакете у конкурентов будут лучшие условия и стабильное качество?

А накой 4 планки, когда есть 3 канала контроллера памяти на каждом из процов (т.е. оптимально ставить 6 плашек, либо для однопроцессорного - 3 плашки)? В сервер можно поставить до 36 дисков. Написано в описании.

Памяти 4 гига скорее всего маловато будет, если начнется проверка файловой системы (для 6ТБ ext3 надо уже более 2 гигов). Установка одной плашки на платформу, поддерживающую 3 канала контроллера памяти - вообще редкий бред. О аппаратном контроллере тоже можно спорить - целесообразность обычно сомнительна, плюсы не всегда перевешивают минусы.

И не только там - приват24 (и любая карточка приватбанка), думаю, и многие другие банки такое поддерживают...

На каком основании разбираться? Будет постановление суда о ограничении чего-либо/передаче каких-либо данных по нарушителю/etc - придется что-то решать, в остальных случаях - слать их нафиг прямым текстом, или в игнор.

Отнюдь. Среднестатистический абонент в случае "подключение ограничено" тут же в саппорт звонит. К слову, вон в соседнем топике сошедший с ума роутер-мыльница ложил пппое у всех абонов, включеных в свич. А какая разница, сколько портов-то? Есть порт, есть абонент, включеный однозначно в определенный порт. Накой огород городить, не объясните? Гимор клиенту создавать? Или от того, что техперсоналу внятно объяснить не в силах, что порт, в который включен абонент, не может быть сменен просто так? Да любой тазик. Ну или какая-то киска 3550/3560 с ip unnumbered, если они вам предпочтительнее. Да. Абоненту пофиг, у него и исходящие, и входящие соединения прекрасно работают, ип при "реконнекте" (отсутствии активности на протяжении некоего периода) меняется. В чем собссно отличие от присвоения адреса интерфейсу? Неужто только в том, что абонент не может посмотреть в свойствах подключения, какой у него ип, и для этого придется (о, ужас!) открывать браузер и идти на некий сайт? А на чем еще л3 агрегацию делаете, как не на девайсах с ip unnumbered? Или есть л3 железки дешевле б/у кисок 3550/3560? Опять же - накой агрегировать везде на л3, когда проще все тянуть в ядро/крупный узел агрегации (не на 5 домов, а хотя бы на район)? Поднял фейковый пппое либо впарил соседушке бэкдор, и вечный праздник - инетом обеспечен пожизненно

Роутеры бывает забавно пучит...

Т.е. - если нужно, скажем, осуществление снятия денег и в ядре, и в вебке - и в ядре код дублируется,и в вебке код дублируется? А если вебка на другом языке писана - что, все библиотеки перепиливать? Ужс... Ядро - это ядро, оно осуществляет все операции с БД и т.п. Вебка/софтина/CLI/etc - отдельная сущность, в общем случае - не обязательно из "доверительной зоны" кода (банально для секюрности системы, особенно если она является модулем для некой CMS), которая должна общаться с ядром, а не с БД напрямую. В такой схеме и вебку сменить элементарно (у кого-то, к примеру, страничка на джумле/DLE, у кого-то - на питоне писаная личная CMS с кучей плюшек, у кого-то - CMS на яве или еще какое извращение), и сделать несколько ядер биллинга - на том же перле/питоне, либо для высоконагруженных систем - на С/С++, и к каждому из вариантов ядра будет крутиться одна и та же веб-морда без особых проблем.

К слову, существуют в природе биллинговые системы, у которых ядро и веб-морда не склеены в единый неделимый комок, а общаются между собой по какому-то из вариантов RPC (XMLRPC к примеру)?

Это примерная статистика. Ибо у нас пппое юзается для доступа в инет, а локалка - благодаря раздаваемым по дхцп маршрутам, как-то кол-во проблем можем сравнить. Зачем авторизировать как-либо при однозначной идентификации абонента по порту? Повторюсь, выявление ошибок сотрудников - это задача не авторизации, а последующего анализа логов и генерации уведомлений при подозрительных ситуациях (к примеру, миграция мака с одного порта на другой). И потом уже их рассматривать - если мак на постоянно поселился на другом порту и перед этим на узле присутствовали сотрудники, давать по рукам за несанкционированное переключение в другой порт и править настройки. Есть такое дело, хотя это актуально для железок возрастом лет 7+. С пптп все еще более печально - дуалкор 1.8ггц под виндами более 50 мбит не вывозит Получится, при желании. Пара примеров: 1) DHCP + /32 маршрут на абона на шлюзе + OSPF с трансляцией static маршрутов, абону выдается подсеть равная AS, включается proxyarp 2) lISG с натом 1:1

Однако 5 проблем, или 50 - есть разница же? В общем-то отменяет. Т.к. известно, в какой порт какой абонент включен - накой еще что-то проверять? Ну а технологические проверки по косвенным признакам (миграция мака и т.п.), для выявления и наказания виновника ошибочного включения (прощелкавшего клювом диспетчера либо же монтажана, самовольно поигравшегося кабелями), проходят прозрачно для абона.

Неужели ни у кого из абонов не выскакивало волшебной 720-й ошибки, которая возникает от чего удобно (один из примеров - прерванная установка дров на сетевуху из-за подвисания процесса), и в общем случае решается только переустановкой оси? А пофиг, что не умеют. Один клиент за аткой точкой прекрасно будет работать. Без необходимости поднимать туннель и т.п. Однако проблем с туннелями по причине проблем на стороне абонента намного больше, чем проблем с DHCP - факт. Основной "практический опыт" для вас будет заключаться в перенастройке оборудования клиентов, приучиванию их к необходимости запуска соединения каждый раз и ответе на вопрос "а какого хрена, если раньше и так работало?", а потом - разъяснению толпам абонов, перебивших себе винду, по ошибке вбивших не тот логин, стерших пароль (или со сбившимся паролем из-за бага винды - бывает вроде иногда слетает сам по себе), куда ткнуть мышкой и как ввести пароль по новой, и где искать логин-пароль если договор после заключения сразу же постелили котику в лоток, а еще - отсеять тех, кто действительно является владельцем учетки, от их соседей, косящих бод забывчивых абонентов с целью выведать пароль и посидеть в инете на халяву. Это так, далеко не полный перечень того, к чему вы стремитесь. Проблемы не странные, а вполне себе предсказуемые и общеизвестные. Заключаются в глюкавости некоторых железок и недоделанности осей от M$, благодаря чему геморроя в общей сложности от PPPoE больше, чем от обычного IPoE. Ни разу такого не было. Со стороны сервера-то проблем никаких. Проблемы - с тем, что у клиентов с туннелями неприятности случаются намного чаще, чем с обычным DHCP. + далеко не каждый роутер на жирном пакете сможет сотку по пппое выжать, о пптп вообще молчу. Нет, это вы как раз зоопарк на ровном месте разводите. Ибо в придачу к уже существующей авторизации абонента по порту пытаетесь лепить еще и авторизацию по логину-паролю, непонятно накой. А если при этом хотите еще и управляемую сеть низвести до неуправляемой помойки, где каждый желающий может легко и непринужденно просниффить пароль соседа и пользоваться инетом на халяву - это вдвойне печально. Повторюсь, проблемы с туннелями возникают в разы чаще, чем проблемы с дхцп. Роответственно, штат саппорта нужно будет увеличить в несколько раз. И кол-во недовольных клиентов тоже в несколько раз возрастет. Хотя, как говорится, каждый сам п№%?ец своего счастья. Мы собираемся уходить от пппое на полностью управляемое железо и IPoE, хотя бы в районах с большой плотностью абонов. Хотите наоборот - ваше право. Только логике это не поддается.

А накой геморрой везде наживать-то? Вон, по вафле больше пары мегабит абонам реально нельзя раздавать - так что, по всей сети ставить такие же тарифы? Не стоит лепить костыли там, где и без них прекрасно работает. Портал авторизации, авторизация средствами самих точек доступа (да-да, многие умеют радиус-авторизацию), и т.п., ну или же туннели только на отдельных участках (т.е. только на вафлях). К слову, туннели никоим образом не должны отменять какую-либо авторизацию на самой AP. Иначе получается рай для пионернетов, перепродающих тот же укртелекомовский инет через вашу AP, либо (если настроен isolated режим и пионерам халява обломится) периодические неведомые глюки из-за по какой либо причине неработающих абонов (не оплатили/отключились/etc), у которых вирусня весело флудит udp пакетами.... При дхцп абоненту ничего не надо вводить. Включил комп и все, интернет есть. А вот пппое настроить, когда винда подбита, или файрвол/антивирь блочит, или еще что - это печально. Как-то работает. Только вот готовьтесь расширить с ходу штат саппорта вдвое-втрое. А если еще и быстрый перевод всех на туннели - к тому же рассчитывайте на изрядно испорченную репутацию и маты клиентов, и авральный режим работы в первые несколько месяцев (5000 злых клиентов, у которых внезапно перестал работать интернет - это очень печально). Угу. Или рвутся по причине кривого файрвола, или еще каких софтовых проблем. А еще точки доступа часто туннели не умеют. И прочие "прелести".

Тут люди думают, как бы от туннелей вообще нах отказаться, дабы упростить жизнь и себе, и саппорту, и клиентам, а отдельные герои наоборот, полностью управляемую сеть с полноценной и однозначной идентификацией абона по порту включения норовят перевести на туннели... Тоска по старой-доброй медной сети на управляемых мыльницах, что ли?

Скрипт мониторинга радиуса и рестарта в помощь. Сделали в свое время, когда rlm_perl был нестабилен еще. В последние более чем год не срабатывал ни разу, кроме как при потере БД (оно-то и понятно, база отвалилась - радиус не авторизирует). Не защищенный от чего??? Причем биллинг к насу? rlm_perl в помощь. Видно же, тазик ваш не справляется, LA более 10-15 - это уже катастрофа, а у вас до 50 (!) доходит. Апгрейдить железо либо переключаться на rlm_perl. У нас цифры в несколько раз больше, сервер биллинга и сервер БД едва на 10% в ЧНН загружен. Бред (с) 1) Пользуйте нормальную ось, в том же линуксе при ядреном пптп загрузка проца что от пптп, что от пппое одинаковая 2) пппое прекрасно параллелится, без каких-либо плясок с бубном. Просто ставятся N серверов, кто первый ответил - к тому клиент и коннектится. Да, к абиллсу есть ессно претензии (идеального софта не бывает), но они совершенно другого рода

Дык в том-то и дело, что такая система мало кому нужна. Завязанная на куче проприетарщины типа визио, с большим, но далеко не всегда нужным функционалом... Мы свою систему потихоньку строгаем, в виде эдакого учебно-промышленного проекта, на котором заодно обучаем одного студента правильному кодингу - пусть это дольше и времени занимает больше в итоге, чем написание лично, но в итоге есть все шансы помимо системы получить еще и человека, который будет ее обслуживать и допиливать, причем делать это качественно и с соблюдением стандартов, в отличие от фрилансеров. В общем-то, в первом приближении система уже вполне может заменить стандартный набор экселевских табличек разварок. Осталось код привести к правильному виду, добавить журналирование, впилить импорт из гуглокарт/CSV и потестировать - и можно начинать работать с ней, попутно дорабатывая прочие полезные фичи типа трассировки волокон кабеля. Потом уже openlayers крутить... А по поводу лайт-версии - при ограничении в 50 узлов ее явно никто не купит. Т.к. 50 узлов вполне себе спокойно ведутся в экселе, без какого-либо напряга. 100-200 - тут уже да, возникает вопрос о документировании в чем-то более серьезном, а средняя сеть, которая сможет купить фулл версию - это минимум 500+ узлов при FTTB.

Статистика примерно следующая: 1-1.5 мбита в ЧНН на онлайн абона, онлайн - 50% из оплативших, т.е. ~0.5-0.7 мбит на рыло. Если вводить резко новые тарифы - может быть 1-2 месяца нештатного потребления трафика, по причине "ого, анлим, надо весь интернет выкачать". Но по мере засирания винтов у хомячков - трафик вернется к тем же ~0.5-0.7 мбит на рыло. Для минимизации пикового потребления можно вводить тарифы с дневной/ночной скоростью, и т.п., хотя актуальны будут только в первое время.

Ну в педивикии всяческие к.т.н. и прочие любители сферических коней в вакууме часто любят сравнивать яйца с легкими... Подумайте на досуге, почему AMD перешла от шустрой EV6 (64бит, 400 МГц) на медленный гипертранспорт (HT 1.0 - 16бит, 800 МГц) в свое время, и почему это не принесло сколь-либо заметной просадки производительности. А еще подумайте, что было бы, если бы инженеры AMD надумали в каком-то из офисных процов вынести северный мост в отдельный кристалл, соединенный по HT с ядрами. Мсье мастер включать фантазию на ходу, да...

Какой такой весомый? Подросла теоретическая пропускная способность за счет дуплексности (причем - никак не на порядок, как кто-то утверждал), и при этом в 2 раза выросла латентность... Тут скорее наличие L3 кеша сыграло роль, а не замена одного тормоза на более другой.

Ура, до вас дошло. Поделите 2.93 на 2 (ибо тактовая частота - 2.93 ГГц, частота обмена данными по шине - в 2 раза больше ибо DDR), и получите 1.47 Гтранзакций/сек в каждую из сторон. Чкча не читатель, чукча писатель? Интел вообще упразднила FSB (Front Side Bus, шину между мостом с контроллером памяти, и ядрами ЦП). И сделала QPI - аналог АМДшного гипертранспорта - исключительно для связи проца с периферией. И высокая скорость от этой шины не требовалась - по ней какбы никто с памятью обмениваться не собирался. Ну и мимоходом эту же шину влепила между ядрами и северным мостом в сверхбюждетный clarkdale по принципу "а почему бы и нет, для офиса и так сойдет, хомячки схавают". И только некоторые индивидуумы, гоняющиеся за мегагерцами и мегабайтами, а не за реальной производительностью, считают использование одной шины между ядрами и северным мостом вместо другой, с близкими характеристиками, гигантским прорывом...

Итак, читаем вместе, по буквам: Потому еще раз задаю вам вопрос: вы L3 форвардинг пакета, с прохождением его по всем цепочкам, от тупого ретрансмита отличить можете, или нет? Что же, разжую как для детского сада, если вы не поняли глупость вашего вопроса. QPB (FSB) - 64 бита, 1 трансфер за такт, 1.33 GT/s для указанной корки QPI - 40 бит, 1 трансфер за 4 такта (ибо атомарный блок данных - flow control unit - 80 бит, шина - 20 бит), частота обмена по шине - 2.93x2 ГГц, т.е. 5.97GT/s на физическом уровне, но 1.47GT/s на "канальном" уровне. Огромная разница с 1.33GT/s, да...

Чукча не читатель, чукча писатель, да? Форвардинг от тупого ретрансмита отличить можете, не? Или для к.т.н. любая передача пакетов - форвардинг? И опять же, где вы там нашли хоть одно упоминание о обмене через оба интерфейса? Повторяю еще раз вопрос: что вам даст знание кол-ва передач данных в секунду, если минимальный размер передаваемых данных - 64 бита независимо от ширины шины CPU-NB? Операция заполнения строки кеша, как и операция записи данных в модуль памяти - атомарная, невозможно записать половину строки кеша, или половину ячеек памяти по данному адресу.