Jump to content
Калькуляторы

bomberman

Активный участник
  • Content Count

    224
  • Joined

  • Last visited

Posts posted by bomberman


  1. Если я верно понял, то 6500 у вас просто агрегирует, vlan-ы с домов, на которых в свою очередь стоят коммутаторы доступа L2, и отправляет их на БРАС-ы.

    Так то о чём, вы говорите - делается на уровне доступа. Т.е. на тех коммутаторах, куда подключаются абоненты. У zyxel - Port Isolation. Далее если на БРАС-е не разрешено им общяться в vlan-е то видеть они будут только интерфейс, который их терминирует, т.е. сам БРАС.

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

     

    Обратиться к внедренцам/продаванам. Открыть кейс в Juniper.

  3. Боже, 400 евро за что?

     

    Поломать вам малину и выложить в открытый доступ то что написал для себя?

     

    Там ровно половина от того что есть у вас и я за это ничего не хочу.

    Но проблема всё та же - это НЕ готовое решение.

    Хотя и разгребает Q-in-Q без создания сабов, само вколачивает роуты, ойпи и маки в ядро - откуда их цапает всё что надо.

    мониторит клиентов arping`ом, авторизирует по произвольному пакету, имеет белые списки сайтов (доступных при блокировки).

    Встроенный dhcp сервер. пилю балансировку/резервирование.

    Вчера доделал аналог бриджа для менеджмент влана - нужyо если коммутатор агрегации не умеет selective QinQ ;(

    ещё всякая чепуха по мелочи. ;)

    Идей много. Но это побочная деятельность в свободное время, начинавшаяся как хобби.

     

    P. S.: Да-да это всё модуль ядра. user-space прокси осталась только для связи с биллингом ;) Хотя по сути можно просто генерить текстовичок который будет перечитываться модулем. Сам иду в торону TCP сессии между модулем и биллингом.

     

    Любопытно. Выкладывайте, коль можете...

    Если это проект, можно отдельной темой форума.

  4. Оно та оно , я видел это , а вот куда паять та там я не нашел что то..

    Тут набор драйверов с описанием, в том числе с физическим соеденением. Зависит от железки индикатора.

    Что именно нужно сделать ??

    Трудно сказать без указания модели камеры. В любом случае погуглите как подключается Ваша камера (модель) во FreeBSD

  5. После подключения камер как ее смонтировать , требуется ли драйвера?

    требуется. Он и создаст ноду для доступа к камере.

    какие программы

    VLC, можно motion

    И еще такой вопрос, в настройках есть служба LCDproc.....

    ТЫЦ... Оно?

  6. Порежте кабель соседу. Можно ещё на кусочки, и аккуратно сложить кучкой перед его дверью.

    А вообще, что вы предъявите? Вы ж по сути на свой страх и риск тянули. Ну вот. Вам не повезло.

    WiFi поставить, нельзя?

  7. Раскидать абонентов между этими брасами нельзя?

    Почему это скорость доложна увеличиться в 2 раза? потому что БРАС-а 2?

    Схема, что Вы педлагаете больше резервирование, чем то что Вам нужно.

  8. Неверно. С тем же успехом можно в фотошопе рисовать.

    Извольте, чего же Вам тогда нужно от этого софта? Чтоб в наборе и модели оборудования присутствовали?

    Если я верно понял, то нарисовать соеденения, и скрывать/отоюражать группы элементов на картинке, чего слоями и можно добиться....

  9. Подскажите, никто с таким не сталкивался?

    Допустим есть у меня программа для составления схем.

    Открываю я в этой программе схему сети, выбираю переключателем L1 — и рисуется схема физических соединений (оборудование, интерфейсы, кабели).

    Переставляю переключатель на L2 — и схема детализуется, линии кабелей превращаются в «трубы», внутри которых нарисованы VLAN, на транковых интерфейсах эти VLAN коммутируются.

    Переставляю переключатель на L3 — и схема абстрагируется, теперь на ней только L3 интерфейсы и (возможно) L2-каналы, с нарисованными потоками маршрутизации.

     

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

    Про NOC-проект я в курсе и с интересом слежу, но ему пока до такого далеко, да и он под инвентаризацию заточен, а не под схемы.

     

    Если верно понял задачу, просто нарисовать схему соеденения, осмелюсь предложить Dia. Схему соеденения рисовать - вполне, как по мне, приемлемо в ней. Много примитивов. Есть слои. Рисуйте на слоях нужные дополнения для основы. Включайте/выключайте слои, печатайте, конвертируйте в pdf для хранения, и тд... А дальше всё зависит от полёта художественной фантазии.

  10. Ну если проблема в большенстве своём только в общяге, то может стоит подключить общягу, как таковую, на индивидуальных условиях. Чтоб и Вам было выгодно, и общяжным небло смысла плодить подобные схемы?

  11. И вобще долой безлимитки! Пусть платят за каждый принятый/отправленный гигабайт!

    И подключать только после личного собеседования с руководством, и предъявления плана по использованию услуги на ближайшие 5 лет ))))

  12. и не производить коммерческую деятельность через сети Оператора без

    дополнительного согласования

    Вот Я например понял ещё и как запрет, производить покупки/продажи, через ваш канал связи, к которому я подключился и плачу за него деньги. Т.е. покупаю у Вас трафик, и услугу... Да Вы мне ещё и ограничиваете объём трафика, и разрешаете подключать только одно устройство!!!!

    В прочем с ограничением - ваше право, точнее ваше предоставление услуги - НО Я КАК ПОТРЕБИТЕЛЬ против. (пусть даже если я и не расходую весь объём, всё же легче и привлекательнее если тебя не ограничивают).

    Что касается подключения одного устройства - подключил я NAT, и расскажите мне что я не одно устройтво подключил...

    В общем почитав такой договор я вероятнее всего уйду к конкурентам у которых такого идиотизма не будет.

    ИМХО. Не стоит такой фигнёй страдать. Ведь получаемый от Вас канал всё равно не раздаст многим. Рано или поздно горе провайдер, столкнётся с нехваткой скорости. И абонентам его проще будет подключиться к Вам, и получать гарантированно скорость, по цене, может чуть больше.

  13. Чудесная система какая то. Ну в прочем, вы в праве творить что хотите.

    Думаю в таком случае разумнее будет следить за тем, сколько по ремени "качающий" использует по максимуму свой менее приоритетный класс, и если это время превышает определённый лимит, то значит "ему нужно" и он отправляется в более быстрый класс. Ибо иначе как вы пймёте, что ему " это нужно"?

    А в сторону понижения приоритета, так же само.

  14. А можете подсказать, как запустить некое событие если у клиента изменился мак?

    Если речь о Option82, и Вы клиента можете идентифицировать не только по mac-у, то Вам нужно при получении запроса настроек, смотреть от какого mac-а пришёл этот запрос, основываясь на option82, и если MAC в базе для этой option82, отличается от MAC-а с которого прилетел запрос с этой option82, выполнять какое либо действие....

  15. photon Почему бы и нет, если Вам это ближе. Я бы так и поступил. К тому же лишний опыт. :)

    Вот было б исключительно ещё RPC прикрутить к нему, раз уж на Python. Благо там это реализуется весьма не сложно. Ну или сделать это как ДЗ для интузиастов. Удобно было бы управлять шейпером извне.

  16. photon

    НУ я пологаю, что будет единственное понятие "класс по умолчанию". Предлагаю ещё ввести такое понятие, как spec_net, например. Трафик этих сетей будет попадать в класс который имеет определённую скорость. К примеру:

    - трафик внутри сети/определённые сегменты (скорость одна) - класс (spec_net)

    - при подключении абонента, трафик заворачивается в список по умолчанию.

    - при его заведении (абонента к примеру в биллинг), его трафик убирается из "по умлчанию", и делится между "spec_net" и личным классом (тариф).

    Т.е. класс "По умолчанию", оставить как какой то промежуточный или "default"...

     

    Что то подобное, только без умолчания, сейчас делаю из Вашего скрипта. + воспользовался патчем от Петрович-2012 , немного переработав. :)

     

    да, к стате, простите что забегаю вперёд, когда ориентировочно патч можно ждать, может вся моя работа будет бесполезной ))))))

  17. photon Приглянулся Ваш скрипт. Хорошая работа. :)

    Скажите, небыло ли где патча для случая когда не нужно шейпить трафик вовсе для определённых сегментов, а весь отдельный тарифик шейпить в соответствии с тарифом. Потребовалась такая возможноть.

    Если я правильно вижу её реализацию, это будет выглядеть как:

    класс со скоростью интерфейса.

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

    Реализация не самая красивая, но других вариантов не вижу, для случая, когда нельзя отроутить тот трафик, который не нужно шейпить.