Хм. У меня нет опыта с Juniper-ом или хуавеем. С Cisco опыт разный и опыт обширный. Давали ли они мне работающие или неработающие решения — я вспомнить не могу, к сожалению, неработающие решения я отметал сразу в процессе разговоров-рассуждений. Некомпетентность в Cisco встречал очень много раз. Например, один из самых вопиющих случаев был, когда вязал Cisco CUCM 3.x.x (уже забыл версию) и CUCM 6.0.x. Вязал h.323 транком. И в одном из условий голосовой канал не проключался в одном из направлений. wireshark-ом нашел закономерность когда это происходит. Открыл тикет в Cisco TAC. Дали инженера. На третьей неделе снятия дампов с cucm-а мне был задан вопрос — «а что же это такое h323 который я все время упоминаю?»
Я несколько шокировался вопросом, послал ссылку на wikipedia со статьей об h323 и просто перестал отдавать свое время тикету (попытался его эскалировать, но менеджер инженера мне рассказал дважды как хорошо инженер справляется со своей задачей). Потом я закрыл тикет, поняв, что проблему не решить. Этот тикет имел неожиданное продолжение. После того как я проставил инженеру неудовлетворительную оценку, звонил менеджер, интересовался чем я недоволен. Обьяснил ситуацию. И, через полтора месяца, этот же самый инженер позвонил снова и сообщил мне что Cisco выпустила внутренний релиз и не желаю ли я проверить на своем рабочем окружении, вдруг там моя проблема починиться. Я спросил о том, были ли изменении в h323 подсистеме в этом релизе, на что мне было отвечено — не знаю. Я опять закрыл тикет.
Так что автор этой статьи — это не самое плохое, что может быть. Я больше скажу — я бы хотел попасть на такого инженера.
Давайте я вам расскажу про отвратительный Cisco-вский support? Вам будет легче?
На мой взгляд, трудно найти адекватный саппорт + адекватность саппорта убывает с ростом вашей осведомленности в предметной области.
Никогда не звонили в саппорт своего провайдера? Я сначала ерепенился, отказывался проверять «лампочки» и перезагружать компьютер. Потом смирился, давал первой линии выполнить их «ритуал» чтобы меня передать второй а то и третьей линии где сидят вменяемые специалисты.
А что касается саппорта Cisco — то моя метода:
1. Просить русских инженеров. Как правило они очень осведомленные и адекватные люди.
2. Записываю имя и фамилию хорошего инженера. Потом, при открытии нового тикета прошу назначить его на мой тикет.
3. Отношусь терпимо к незнанию инженера. У него, кроме меня есть еще и другие тикеты + ему надо еще разобраться в конкретном дизайне, который может быть очень далеко от стандартного.
Потому как.
Представим любой маленький населенный пункт.
Нумерация внутри — 3 цифры телефонного номера. Их набирают чтобы позвонить «по городу». Там так привыкли. Но! Официальный городской номер это еще 3 цифры, которые стоят перед этим 3-х значным номером, и по нему также можно позвонить. Соот-но код города — 4-рех значный.
В итоге, что я хочу сказать. Я бы, на вашем месте, сконцентрировался на представлении номеров в международном формате, которые начинаются на +. А все остальное — уж очень специфично и зависит от страны и населенного пункта. Дайте программисту возможность самому изменить эту логику в вашем приложении.
P.S.: Я не критикую, я искренне хочу помочь. Сам несколько завязан на телефонные номера — нахлебался.
По длине все просто — длина телефонного номера в РФ всегда фиксирована
Номер определяется маской +7 XXX YYY-YY-YY где +7 — код страны, XXX — код региона, YYY-YY-YY номер абонента.
А какие проблемы по Челябинску. По мне там все просто.
:) Что я вижу в этом ответе:
1. Похвастался «своим» (пока дядя не отобрал) «зоопарком» (а что так не организованно)
2. Похвастался знанием «читерской» команды (причислил себя к классу _очень_ умных цискарей)
3. Продолжаешь троллить неотносящимеся к теме терминами OSPF, BFD, hello/dead и так далее.
На мой взгляд, искусство инженера как раз и состоит в том, чтобы в каждом случае найти границу разумной применимости той или иной технологии.
Я был несогласен в том, что минимум вводимых инженером команд — не есть критерий хорошести конфигурации. На мой взгляд, удобство инженера — на 10-м месте. А на первом — эффективность использования вверенных ему ресурсов.
И я, кстати, книжку приводил в подкрепление своих слов — спорьте с ее автором: Jeff Doyle
Я проще напишу.
Меньше операций, меньше греем CPU, меньше выброса тепла, больше КПД оборудования. Ну и экология. И эта экономия есть _всегда_. Ну и как приятность — мы получим меньшее время конвергенции протокола, что не есть плохо, не правда ли?
А про как удобно — мне удобно конфиги забацать в vim-е и разлить по сети скриптом. И тут время простое — одна строчка — у меня где-то одна секунда создается, а может и меньше. Но эта одна затраченная секунда (ну пускай минута, для ровного счета), будет экономить электричество, выделять меньше тепла и т.д. и т.п.
К тому же, лично для меня, отдебажить ospf с маленьким LSA1 database и большим LSA5 гораздо проще, чем наоборот.
Так что же лучше?
Сэкономить минуту работы инженера — которая стоит 1$, или сэкономить явно заведомо большую сумму денег, которая уйдет на эл-во, отвод тепла, большую загрузку control-plane, что может вылиться в покупку нового оборудования…
Ну что ж.
С моей точки зрения (вычитал где-то, да и так понятно), следует предпочитать redistributed роуты (LSA 5), потому что они быстрее обсчитываются, потому как не принимают участия в построении графа, на который потом накладывается алгоритм Дейкстры.
Соот-но нагрузка на CPU становится меньше в больших ospf сетях.
В частности про это написано в главе 7.3.2 книги: OSPF and IS-IS: Choosing an IGP for Large-Scale Networks By Jeff Doyle
Понравилось про экономию строк в конфигурации. :)
Это ж как получается, инженер не экономией ресурсов оборудования озабочен или там правильным дизайном, а количеством написанный строк :)
Вот эти файлы имеет длину 231 байт, что немного маловато для видео
recoded_videos%2Falgs4partI-2.mp4
recoded_videos%2Falgs4partI-98.mp4
recoded_videos%2Falgs4partI-95.mp4
recoded_videos%2Falgs4partI-93.mp4
recoded_videos%2Falgs4partI-91.mp4
Я сказал что perl (с его быстротой разработки и переносимостью) никак не сравним с C# и Java. То что заказчик хочет — это ортогонально (по моему мнению) к предмету спора.
Я бы понял когда переход был бы perl -> python или там perl -> ruby. Но perl-> C#,Java? Как то в голове не укладывается
Я несколько шокировался вопросом, послал ссылку на wikipedia со статьей об h323 и просто перестал отдавать свое время тикету (попытался его эскалировать, но менеджер инженера мне рассказал дважды как хорошо инженер справляется со своей задачей). Потом я закрыл тикет, поняв, что проблему не решить. Этот тикет имел неожиданное продолжение. После того как я проставил инженеру неудовлетворительную оценку, звонил менеджер, интересовался чем я недоволен. Обьяснил ситуацию. И, через полтора месяца, этот же самый инженер позвонил снова и сообщил мне что Cisco выпустила внутренний релиз и не желаю ли я проверить на своем рабочем окружении, вдруг там моя проблема починиться. Я спросил о том, были ли изменении в h323 подсистеме в этом релизе, на что мне было отвечено — не знаю. Я опять закрыл тикет.
Так что автор этой статьи — это не самое плохое, что может быть. Я больше скажу — я бы хотел попасть на такого инженера.
На мой взгляд, трудно найти адекватный саппорт + адекватность саппорта убывает с ростом вашей осведомленности в предметной области.
Никогда не звонили в саппорт своего провайдера? Я сначала ерепенился, отказывался проверять «лампочки» и перезагружать компьютер. Потом смирился, давал первой линии выполнить их «ритуал» чтобы меня передать второй а то и третьей линии где сидят вменяемые специалисты.
А что касается саппорта Cisco — то моя метода:
1. Просить русских инженеров. Как правило они очень осведомленные и адекватные люди.
2. Записываю имя и фамилию хорошего инженера. Потом, при открытии нового тикета прошу назначить его на мой тикет.
3. Отношусь терпимо к незнанию инженера. У него, кроме меня есть еще и другие тикеты + ему надо еще разобраться в конкретном дизайне, который может быть очень далеко от стандартного.
Потому как.
Представим любой маленький населенный пункт.
Нумерация внутри — 3 цифры телефонного номера. Их набирают чтобы позвонить «по городу». Там так привыкли. Но! Официальный городской номер это еще 3 цифры, которые стоят перед этим 3-х значным номером, и по нему также можно позвонить. Соот-но код города — 4-рех значный.
В итоге, что я хочу сказать. Я бы, на вашем месте, сконцентрировался на представлении номеров в международном формате, которые начинаются на +. А все остальное — уж очень специфично и зависит от страны и населенного пункта. Дайте программисту возможность самому изменить эту логику в вашем приложении.
P.S.: Я не критикую, я искренне хочу помочь. Сам несколько завязан на телефонные номера — нахлебался.
Номер определяется маской +7 XXX YYY-YY-YY где +7 — код страны, XXX — код региона, YYY-YY-YY номер абонента.
А какие проблемы по Челябинску. По мне там все просто.
www.rossvyaz.ru/activity/num_resurs/registerNum/
1. Похвастался «своим» (пока дядя не отобрал) «зоопарком» (а что так не организованно)
2. Похвастался знанием «читерской» команды (причислил себя к классу _очень_ умных цискарей)
3. Продолжаешь троллить неотносящимеся к теме терминами OSPF, BFD, hello/dead и так далее.
На мой взгляд, искусство инженера как раз и состоит в том, чтобы в каждом случае найти границу разумной применимости той или иной технологии.
Я был несогласен в том, что минимум вводимых инженером команд — не есть критерий хорошести конфигурации. На мой взгляд, удобство инженера — на 10-м месте. А на первом — эффективность использования вверенных ему ресурсов.
И я, кстати, книжку приводил в подкрепление своих слов — спорьте с ее автором: Jeff Doyle
P.S.: Прекращаю это бесполезный спор.
Меньше операций, меньше греем CPU, меньше выброса тепла, больше КПД оборудования. Ну и экология. И эта экономия есть _всегда_. Ну и как приятность — мы получим меньшее время конвергенции протокола, что не есть плохо, не правда ли?
А про как удобно — мне удобно конфиги забацать в vim-е и разлить по сети скриптом. И тут время простое — одна строчка — у меня где-то одна секунда создается, а может и меньше. Но эта одна затраченная секунда (ну пускай минута, для ровного счета), будет экономить электричество, выделять меньше тепла и т.д. и т.п.
К тому же, лично для меня, отдебажить ospf с маленьким LSA1 database и большим LSA5 гораздо проще, чем наоборот.
Так что же лучше?
Сэкономить минуту работы инженера — которая стоит 1$, или сэкономить явно заведомо большую сумму денег, которая уйдет на эл-во, отвод тепла, большую загрузку control-plane, что может вылиться в покупку нового оборудования…
Вопрос, конечно, философский.
С моей точки зрения (вычитал где-то, да и так понятно), следует предпочитать redistributed роуты (LSA 5), потому что они быстрее обсчитываются, потому как не принимают участия в построении графа, на который потом накладывается алгоритм Дейкстры.
Соот-но нагрузка на CPU становится меньше в больших ospf сетях.
В частности про это написано в главе 7.3.2 книги: OSPF and IS-IS: Choosing an IGP for Large-Scale Networks By Jeff Doyle
Это ж как получается, инженер не экономией ресурсов оборудования озабочен или там правильным дизайном, а количеством написанный строк :)
А что про Type:4? Без него Type:5 чувствует себя не по себе.
recoded_videos%2Falgs4partI-2.mp4
recoded_videos%2Falgs4partI-98.mp4
recoded_videos%2Falgs4partI-95.mp4
recoded_videos%2Falgs4partI-93.mp4
recoded_videos%2Falgs4partI-91.mp4
tools.ietf.org/html/rfc1518 В 1993 году еще RFC выпустили.
А что касается IPv6 «проще» — так в IPv6 просто в разы сложнее чем IPv4.
Я сказал что perl (с его быстротой разработки и переносимостью) никак не сравним с C# и Java. То что заказчик хочет — это ортогонально (по моему мнению) к предмету спора.
Я бы понял когда переход был бы perl -> python или там perl -> ruby. Но perl-> C#,Java? Как то в голове не укладывается