:) Я понимаю вашу логику.
Только я понимаю и логику руководителя. Он отнюдь не инженер и не специалист. И он не сможет понять кто тут прав, а кто виноват. Но у Cisco есть имя — это vendor и все прочее — а специалист — всего лишь специалист. Вы бы кому больше поверили, когда у вас обнаружилась плавующая ошибка (например каждый 10-100 звонок на АТС обрывался) — инженеру или cisco?
А что касается Cisco TAC у меня есть с ними свой опыт и, обычно, я просто обхожу ситуацию, когда вижу, что TAC-овец неспособен ее решить. Но в ситуации, что я описываю, у меня не было выбора. Этот тикет сменил трех инженеров (потому что первые два не особо понимали в чем вообще проблема), а третьего я получил после эскалации, и то, даже раз пришлось поговорить с начальником этого инженера. Спасибо что напомнили, пойду и я о себе напомню им.
:) Спасибо за открытие страшных тайн.
Давно знаком с Cisco TAC и пользуюсь им.
Только как это решает вопрос ответственности?
Cisco TAC не выплатит организации деньги, потерянные на простое из-за ошибок программистов Cisco, или из-за ошибок Cisco TAC-а. Или у вас, таки выплачивает? Если так, то нужно идти за чеком в Cisco, потому как пошел уже 4-й месяц решения проблемы неработоспособности cisco phone proxy feature на cisco asa firmware 8.4.x+. После многочасового общения и демонстрации работоспособности cisco asa phoneproxy на ASA 8.2.x, и неработоспособности той же конфигурации на cisco asa phoneproxy 8.4.x инженер Cisco TAC на третьем месяце общения таки решила передать дело разработчикам (а проблема таки в том, что они теряют правильный номер порта при открытии дырки в firewall-е). Теперь я вот уже второй месяц кормлюсь обещаниями, что вот-вот проблему исправят. Надо кстати опять позвонить, послушать следующий срок, когда мне таки что-то предоставят. Последний срок было до конца марта.
И это все за деньги заказчика, теряя время специалистов заказчика. Какая-то извращенная форма садизма :) При том что прежнее решение на asterisk просто работало :) Ну или можно еще на infratel посмотреть — тоже у нас работает без особых проблем.
Хм. Я, конечно же, не могу судить про ваш опыт. Но мой опыт работы показывает, что начальник редко задумывается и хочет лезть разбираться в ситуацию, когда что-то не работает. Виноватым назначается специалист что настраивает и «нечего оправдываться что cisco/whatever глючит»
Нести ответственность будет тот же, кто и в несвободно распостраняемом ПО — специалист, который это ПО настраивает. А что, есть какие-то еще варианты?
Ни разу не видел как бы Cisco брала на себя ответственность за какие-то ошибки своих программистов/поддержки/менеджеров. Возможно в других компаниях не так — не знаю.
1. Это хорошо. В данном случае я под курсами имел ввиду сертификацию, единую на весь мир, где специалистов учат «правильным» и, главное, одинаковым решениям, как надо настраивать этот софт.
Лично мое мнение — астериск — конструктор, из которого можно сделать все что угодно. Но:
1. Решение нестандартное, курсов нет, книжек нет, служба сопровождения должна быть умная. Документация на систему — хорошая.
2. Если нужно подключить много-много пользователей, скажем несколько тысяч — я не представляю как всем этим рулить на астериске
3. Я не представляю как на астериске сделать reliability? Ну там много серверов, распределение нагрузки? Отстал от жизни — это уже давно сделали?
Сначала об Cisco:
> Однако настройка обойдется в приличную сумму
Можно аргументировать почему? Люди за зарплату настраивают. Никакого rocket science там нет.
> Для администрирования этой системы необходимо приобрести лицензию, а так же оплатить обучение своего специалиста, либо вызвать для наладки специалиста из Cisco, что тоже далеко не дешево.
Можно поподробнее? Впервые слышу, нет там ни лицензий, ни оплаты своего специалиста. Думаю что ваш интегратор вам наврал.
> Добавление новых пользователей, расширение количества ip-телефонов и т.д. стоит вложений, с чем, кстати, у того же Asterisk проблем не будет.
Добавление новых пользователей — нет, добавление телефонов — да — начиная с версии 5.0
> VOIP, FANSO
Что такое FANSO?
> Говорят, что вам понадобится специалист лишь в случае, если вы захотите интегрировать Cisco, а значит — понадобится.
А что значит «интегрировать Cisco»? Куда? А вообще, говорят на заборе… написано. Говорят.
> Cisco производит собственное оборудование
А также берет серверы IBM и HP вешает на них лейбл cisco и продает как платформу для CUCM и прочих Voice решений
> Cisco адекватно работают с любой АТС, но вот с АТС Cisco – работают далеко не все ip-телефоны.
Все sip телефоны скорее всего будут нормально работать с Cisco, также все обычные аналоговые телефоны будут нормально работать с Cisco. И только цифровые телефоны под конкретные АТС будут испытывать проблемы — нет соответствующих портов для Cisco у них.
> Но расширяемость ПО Cisco серьезно ограничено, когда дело доходит до интеграции единых поставщиков связи.
Раскройте тему, пожалуйста
Infinity
> Огромным минусом в моих глазах является то, что Infinity работает на Windows, в то время как остальные предпочитает более надежный Linux. Стоит ли пояснять, где багов будет больше?
Багов будет больше там, где их сделал больше программист в клиентском ПО. Windows — достаточно надежная система для серверов начиная с NTv4 (может и раньше). Windows 2000 — еще много где живет в Интернете даже и в ус не дует.
И еще. CUCM переехал на linux только с версии 5.0, Cisco Unity живет на Windows до сих пор как и некоторые другие продукты.
абсолютно точно — нет. Нужно покупать CP-7937-MIC-KIT. $350 GPL
Также, если нет PoE или он недостаточно хорош, проще поставить стандартный блок питания — PWR-CUBE-3 + CP-7937-PWR-SPL (фактически power injector)
Меня по пункту 1 смущает следующее: создать view-хи — это здорово, но можно как-то эти view-хи сделать аутентифицируемыми по радиусу/такаксу? Когда устройств много, а админы меняются хотя бы раз в три/шесть месяцев менять конфигурации, даже скриптом, становится сложно. Хочется меня пароль, и конфигурацию учетной записи из одной точки.
Я думаю что предложить. Уж лучше octave, чем ничего. После octave на матлабе все будет знакомо + будет совсем непонятно — а зачем матлабовский отладчик то нужен? Когда в octave и так научились программы легко отлаживать.
честно не могу сказать. Сам пользовался им по достаточно простой схеме. Мне коллега на matlab-е писал алгоритм. Я, ради запуска его на linux, перегонял на octave (кое-какие функции из разряда, открыть файл, записать файл отличаются), а затем писал аналог на C (для чего это все и затевалось изначально).
Насколько я помню, matlab таки имеет компилятор, а octave чисто интерпретируемая вещь.
Сам в matlab-е когда ковырялся по ощущениям — в matlab-е просто огромное количество библиотек, по сравнению с octave-где, по сути только базовые возможности языка matlab. Возможно я ошибаюсь и плохо копал octave. Вот тут на курсах будет возможность копнуть поглубже.
Я вот тоже регался. И на меня тоже забили. А вот сокурснику прислали, единственному из знакомых, приглашение. Ну а он уж с нами поделился. Почему так — непонятно — можно там у них спросить, кстати.
Сразу могу сказать что забор конфигов по tftp не лучшая идея, потому как tftp протокол не самый хороший выбор на длинном канале с ошибками. У меня на этом протоколе на моих скриптах были конфиги, которые категорически недокачивались.
Я выбрал протокол ftp. Почему не scp? Потому что из-за какой-то, уже не помню какой баги, scp на базе sshv2 с циски не ходили. Надо на цисках всех было включать ssh v1.
А еще подводный камень, в ios в окрестности 12.4.20T ошибка, такая, чтобы ftp не работает.
В итоге в моем скрипте сначала идет попытка передачи конфига по ftp, если проблема, переключаемся на scp. А я уж позаботился о том, что на хостах с проблемой в ftp стоял ssh v1.
И еще, Net::Appliance::Session у меня на FreeBSD не заработал, как и все прочее SSH из под perl-а. Удивительно хорошо и надежно работает Net::Telnet::Cisco, но канал не защищенный, не подходит.
В итоге свои скрипты я написал на базе Expect-a.
Можно было еще использовать snmp для скидывания конфига (чтобы не лезть на консоль), но Cisco ASA не позволяет этого, а ASA мне была важна.
Только я понимаю и логику руководителя. Он отнюдь не инженер и не специалист. И он не сможет понять кто тут прав, а кто виноват. Но у Cisco есть имя — это vendor и все прочее — а специалист — всего лишь специалист. Вы бы кому больше поверили, когда у вас обнаружилась плавующая ошибка (например каждый 10-100 звонок на АТС обрывался) — инженеру или cisco?
А что касается Cisco TAC у меня есть с ними свой опыт и, обычно, я просто обхожу ситуацию, когда вижу, что TAC-овец неспособен ее решить. Но в ситуации, что я описываю, у меня не было выбора. Этот тикет сменил трех инженеров (потому что первые два не особо понимали в чем вообще проблема), а третьего я получил после эскалации, и то, даже раз пришлось поговорить с начальником этого инженера. Спасибо что напомнили, пойду и я о себе напомню им.
Давно знаком с Cisco TAC и пользуюсь им.
Только как это решает вопрос ответственности?
Cisco TAC не выплатит организации деньги, потерянные на простое из-за ошибок программистов Cisco, или из-за ошибок Cisco TAC-а. Или у вас, таки выплачивает? Если так, то нужно идти за чеком в Cisco, потому как пошел уже 4-й месяц решения проблемы неработоспособности cisco phone proxy feature на cisco asa firmware 8.4.x+. После многочасового общения и демонстрации работоспособности cisco asa phoneproxy на ASA 8.2.x, и неработоспособности той же конфигурации на cisco asa phoneproxy 8.4.x инженер Cisco TAC на третьем месяце общения таки решила передать дело разработчикам (а проблема таки в том, что они теряют правильный номер порта при открытии дырки в firewall-е). Теперь я вот уже второй месяц кормлюсь обещаниями, что вот-вот проблему исправят. Надо кстати опять позвонить, послушать следующий срок, когда мне таки что-то предоставят. Последний срок было до конца марта.
И это все за деньги заказчика, теряя время специалистов заказчика. Какая-то извращенная форма садизма :) При том что прежнее решение на asterisk просто работало :) Ну или можно еще на infratel посмотреть — тоже у нас работает без особых проблем.
Ни разу не видел как бы Cisco брала на себя ответственность за какие-то ошибки своих программистов/поддержки/менеджеров. Возможно в других компаниях не так — не знаю.
1. Решение нестандартное, курсов нет, книжек нет, служба сопровождения должна быть умная. Документация на систему — хорошая.
2. Если нужно подключить много-много пользователей, скажем несколько тысяч — я не представляю как всем этим рулить на астериске
3. Я не представляю как на астериске сделать reliability? Ну там много серверов, распределение нагрузки? Отстал от жизни — это уже давно сделали?
Сначала об Cisco:
> Однако настройка обойдется в приличную сумму
Можно аргументировать почему? Люди за зарплату настраивают. Никакого rocket science там нет.
> Для администрирования этой системы необходимо приобрести лицензию, а так же оплатить обучение своего специалиста, либо вызвать для наладки специалиста из Cisco, что тоже далеко не дешево.
Можно поподробнее? Впервые слышу, нет там ни лицензий, ни оплаты своего специалиста. Думаю что ваш интегратор вам наврал.
> Добавление новых пользователей, расширение количества ip-телефонов и т.д. стоит вложений, с чем, кстати, у того же Asterisk проблем не будет.
Добавление новых пользователей — нет, добавление телефонов — да — начиная с версии 5.0
> VOIP, FANSO
Что такое FANSO?
> Говорят, что вам понадобится специалист лишь в случае, если вы захотите интегрировать Cisco, а значит — понадобится.
А что значит «интегрировать Cisco»? Куда? А вообще, говорят на заборе… написано. Говорят.
> Cisco производит собственное оборудование
А также берет серверы IBM и HP вешает на них лейбл cisco и продает как платформу для CUCM и прочих Voice решений
> Cisco адекватно работают с любой АТС, но вот с АТС Cisco – работают далеко не все ip-телефоны.
Все sip телефоны скорее всего будут нормально работать с Cisco, также все обычные аналоговые телефоны будут нормально работать с Cisco. И только цифровые телефоны под конкретные АТС будут испытывать проблемы — нет соответствующих портов для Cisco у них.
> Но расширяемость ПО Cisco серьезно ограничено, когда дело доходит до интеграции единых поставщиков связи.
Раскройте тему, пожалуйста
Infinity
> Огромным минусом в моих глазах является то, что Infinity работает на Windows, в то время как остальные предпочитает более надежный Linux. Стоит ли пояснять, где багов будет больше?
Багов будет больше там, где их сделал больше программист в клиентском ПО. Windows — достаточно надежная система для серверов начиная с NTv4 (может и раньше). Windows 2000 — еще много где живет в Интернете даже и в ус не дует.
И еще. CUCM переехал на linux только с версии 5.0, Cisco Unity живет на Windows до сих пор как и некоторые другие продукты.
Также, если нет PoE или он недостаточно хорош, проще поставить стандартный блок питания — PWR-CUBE-3 + CP-7937-PWR-SPL (фактически power injector)
Насколько я помню, matlab таки имеет компилятор, а octave чисто интерпретируемая вещь.
Сам в matlab-е когда ковырялся по ощущениям — в matlab-е просто огромное количество библиотек, по сравнению с octave-где, по сути только базовые возможности языка matlab. Возможно я ошибаюсь и плохо копал octave. Вот тут на курсах будет возможность копнуть поглубже.
Я выбрал протокол ftp. Почему не scp? Потому что из-за какой-то, уже не помню какой баги, scp на базе sshv2 с циски не ходили. Надо на цисках всех было включать ssh v1.
А еще подводный камень, в ios в окрестности 12.4.20T ошибка, такая, чтобы ftp не работает.
В итоге в моем скрипте сначала идет попытка передачи конфига по ftp, если проблема, переключаемся на scp. А я уж позаботился о том, что на хостах с проблемой в ftp стоял ssh v1.
И еще, Net::Appliance::Session у меня на FreeBSD не заработал, как и все прочее SSH из под perl-а. Удивительно хорошо и надежно работает Net::Telnet::Cisco, но канал не защищенный, не подходит.
В итоге свои скрипты я написал на базе Expect-a.
Можно было еще использовать snmp для скидывания конфига (чтобы не лезть на консоль), но Cisco ASA не позволяет этого, а ASA мне была важна.
Вот такие небольшие заметки.
Автор опять никак не вложился в рекламу (кроме как статью написать), а каков может быть эффект :)