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

motorhunter

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

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

  • Посещение

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


  1. Бизнес-процессы как таковые, можно сказать, отсутствуют (или они стихийные). Если система позволит их отладить - будет очень хорошо. Руководство готово, инициатива от него и исходит.
  2. Vanger_, спасибо, посмотрим эти системы. Sonne, если не секрет, какая система понравилась? Интеграцию системы с биллингом, наверное, можно и не делать. Просто сделаем самостоятельно всплывающее по звонку окошко с номером и информацией об абоненте, а в этом окне кнопка - "Открыть заявку" со ссылкой на систему. Manmensweetsender, пока тоже склоняемся к тому, чтобы самостоятельно написать, просто подумалось - вдруг уже что-то достойное есть и можно не изобретать велосипед? Поэтому и решил узнать, как обстоят дела у коллег-провайдеров.
  3. Доброго времени суток! Небольшой провайдер решил отладить работу службы техподдержки и ремонтных бригад. Сейчас всё общение между абонентским отделом, операторами техподдержки и ремонтниками сводится к телефонным звонкам и использованию самописной базы заявок, которая не устраивает своим функционалом. Хочется следующего: - оператору техподдержки в момент прихода звонка должна отображаться карточка абонента с данными из биллинга (баланс, тариф, блокировка), текущая открытая заявка и история заявок этого абонента (если есть). Хорошо бы иметь возможность в один клик открыть заявку с приложением записи разговора. - оператор должен иметь возможность работы с заявками – создавать, комментировать, прикреплять файлы и т.п. - ремонтники должны иметь возможность видеть список текущих заявок, комментировать их и указывать затраченное на работу время. - система должна уметь предоставлять статистику, отчеты. - вся работа – через web. - дополнительные плюшки вроде отправки SMS клиентам (не обязательно). Существуют ли сейчас готовые системы, позволяющие выполнять этот функционал? Рассматриваем как open-source, так и платные (типа Mango CRM), локальные или облачные. Понятно, что любую систему придётся как минимум интегрировать с биллингом, с этим проблем нет. Вопрос в том, что будет сложнее – допилить что-то готовое или написать своё? А что Ваша компания использует для решения подобных задач? Поделитесь, если не сложно. Хочется понять, куда двигаться.
  4. Вроде бы у Zyxel есть то, что нужно. Выдержка из описания MES3500-24:
  5. Напишу и я отзыв. Мы обратились в IP4Market с целью продажи наших объектов, которые довольно долго не могли продать. Нам подобрали покупателя, согласовали устраивающую нас цену и механизм оплаты, заключили договор. Нам сообщили что данные работы обычно занимают около 1-2 недель. В нашем случае ситуация была нестандартная, скорее исключительная, много новых нюансов возникло уже в процессе начала работ и они заняли 2,5 месяца! IP4Market отстоял нашу позицию перед RIPE, который задавал очень много дополнительных вопросов и требовал очень много разных документов, ну и плюс всячески тянул с ответами. Реально была проделана очень большая работа, на которую они сами изначально не рассчитывали. Ребята из IP4Market довели дело до конца и перевод ресурсов был успешно осуществлён! Благодарим за проявленную гибкость, терпение, настойчивость и профессионализм! Желаем удачи и рекомендуем к сотрудничеству.
  6. А кто тогда вставляет патч-корды в серверной, если инженеры все на удалёнке?
  7. Продам оптические мультиплексоры ML-FM-8E1-GE. - 8 портов E1; - 1 порт GigabitEthernet; - два порта SFP для подключения к ВОЛС (резервируют друг друга). Имеется 2 штуки. Отправим через ТК. Предложения прошу в ЛС.
  8. Есть сеть PI /20 на продажу. 1200 т.р., продаем без НДС. Нал/безнал.
  9. Интересно, для каких добропорядочных целей могут потребоваться белые адреса сроком на месяц? Почему-то на ум сразу приходят разовые акции типа рассылки спама, организации сетевых атак, перебора паролей или накрутки какого-либо голосования... Ну и по теме - продаю PI /20. Пишите в ЛС.
  10. Куплю PI и AS ipv4

    Есть PI /20 на продажу. Предложения в ЛС.
  11. Описание автономной системы заполнено корректно (AS создавал LIR, сами мы LIRом не являемся), я просто вырезал ненужную информацию (о чем честно написал). Спасибо за ответы. Конечно, переключения ещё не было, именно для того, чтобы сделать правильно, и был задан вопрос.
  12. pppoetest, будьте любезны, объяснитесь.
  13. Доброго времени суток! Ситуация такая - имеем AS, PI и стык с одним аплинком по BGP. Аплинку анонсируем свои сети, принимаем дефолт. При этом у нашей AS в RIPE DB прописаны такие строки (лишнее вырезано): aut-num: ASXXXX import: from ASYYYY action pref=20; accept ANY export: to ASYYYY announce ASXXXX ASXXXX - наша автономная система, ASYYYY - аплинк. Стоит задача переключиться на другого аплинка (при этом старый стык убрать). У него, естественно другая AS. Должен ли я прописать соответствующие строки import/export для автономной системы нового аплинка в RIPE DB (и убрать текущие)? Или же и без этого стык заработает? Проверяется ли как-то соответствие реальных анонсов BGP на стыках операторов с указанными в RIPE DB? Кто это делает, каков механизм? Поясните, пожалуйста, хотя бы в двух словах, или подскажите, где об этом можно почитать.
  14. Вот он - http://shop.nag.ru/catalog/02092.Cisco/07122.7200-7300/01958.c7301 Судя по изображению, питание от сети 220 В.
  15. Diman_xxxx, странно, что у Вас такая загрузка CPU большая. Вот наш 3845:
  16. Б/у, конечно. Ещё такой вопрос - в 7200 серии прошивку с любыми возможностями так же, как в 3800, можно заливать самостоятельно? Не требуется никаких лицензий покупать?
  17. Spinaker, спасибо за информацию! Думаю, 7301 и гигабит осилит... Теперь бы ещё графики работы 7201 в подобных условиях увидеть. Действительно, нашел 7201 в продаже дешевле, в пределах 90к. vurd, ASR, конечно, хорошо, но пока избыточно и дороговато.
  18. Сам удивляюсь, однако графикам верю. Статистика аплинка трафик подтверждает, загрузку CPU проверял в консоли - тоже не обманывает. На PC не хочется заморачиваться, железку считаю надежней.
  19. Доброго времени суток, коллеги. Прошу совета, сам немного запутался. Ситуация такая - имеем в качестве бордера Cisco 3845 и одного аплинка, от которого принимаем по BGP дефолт и анонсим свои сети. В часы пик входящего трафика порядка 550 Мбит/с (исходняк - раза в 2 меньше, при этом 60-70 kpps в каждую сторону). Также используется RIP между роутером и серверами доступа. Никаких ACL нет, NATа нет. Есть поток NetFlow на биллинг. При всём этом загрузка процессора составляет 50-60% в час пик. Хочется подключить второго аплинка и расширить общую полосу трафика, скажем, до 1 Гбита/с. Думаю, что 3845 уже не справится. Начал подбирать замену из б\у цисок в магазине НАГа. Присмотрел вроде как сначала 3945, но дороговато. Потом нашел 7201, он уже дешевле, и, судя по таблицам производительности, должен гиг вытянуть. Однако рядом с ним продается 7301, который, если верить спекам Cisco, должен вытягивать 1Mpps при 500 Мбитах/с. Цена его намного привлекательней - 40к против 180к за 7201. С одной стороны, понимаю, что 7301 рассчитан на 500 Мбит/с, а нам хотелось бы гигабит. С другой - про 3845 в тех же таблицах производительности вообще написано - 256 Мбит/с, 500 kpps. Однако у нас он загружен вдвое больше (по трафику), и при этом нареканий нет. Вот и хочется узнать - будет ли 7301 так же переваривать трафик до 1Г, или же он имеет какие-то принципиальные отличия от 3800 серии, которые не позволят ему так работать? Ещё момент - при подключении второго оператора придется держать 2 FV, которых сейчас нет, и которые создадут дополнительную нагрузку. К сожалению, я ни разу не сталкивался с приёмом FV и не могу оценить, как это повлияет на производительность. Ну и поток netflow тоже вырастет. Подскажите, как быть? Брать 7301 (очень привлекает цена) в надежде, что справится, или раскошеливаться на 7201 или что-то ещё? Может, кто-то использовал 7301, поделитесь, каковы его реальные способности.
  20. Проводя аналогию с языками программирования - можно всё писать в машинных кодах (ну или на ассемблере), зачем всяких языков высокого уровня наплодили? Да ещё не абы каких, а Visual...
  21. Некоторые вещи намного удобнее настраивать через графический интерфейс. Например, есть у нас ASA с кучей объектов и сотней правил. В консоли тяжеловато бывает настраивать такое. А в ASDM всё наглядно и структурировано. Причем можно настроить не только правила, но и другие вещи, типа Faileover'а. Удобно смотреть графики загрузки и логи в реальном времени. Почему такое не сделать и для коммутаторов?
  22. Какая может быть норма трафика на безлимите? Сколько скачал (на своей скорости) - всё его.
  23. А чем плохи тарифы с посуточным списанием? Почему они менее выгодны, по сравнению с тарифами со списанием абонентской платы раз в месяц? У нас абонентская плата списывается каждый день в размере АП/кол-во дней в месяце (биллинг сам рассчитывает). Если абонент уходит в минус, для включения ему достаточно положить на счет такую сумму, чтобы баланс стал положительным (хоть +1 р.).
  24. Доброго дня. С недавних пор начали предоставлять услугу L2 VLAN для соединения филиалов организаций, разбросанных по городу. В связи с этим встал вопрос - чем и как мониторить состояние каналов? Пока что идей ровно две - отслеживать трафик на портах, подключенных к конечным потребителям, и количество МАС-адресов на них. Однако это не даёт полной картины. Допустим, абонент может отключить своё оборудование с одной из сторон канала (например, выключить ПК на ночь или на выходные), тогда, естественно, ни трафика, ни маков не будет на порту, однако сказать, что канал упал, нельзя. Или же может зависнуть конвертер (не всегда абонент включен напрямую в порт умника - иногда от коммутатора до абонента идет оптический линк через медиаконвертеры), и с точки зрения оператора картина будет такой же - нет трафика и маков, но здесь уже нужно фиксировать падение VLAN'а и бегом менять конвертер. Или же третий случай - где-то заменили промежуточный коммутатор, но забыли прописать нужный VLAN, в итоге МАС-адреса на абонентских портах фиксируются, трафик тоже будет (входящий), но канал опять-таки не работает... А в итоге при выставлении счета нужно будет учесть время простоя, что при текущем положении дел не представляется возможным. Подскажите выход :) Поделитесь, какими средствами вы наблюдаете за предоставляемыми L2-каналами.