Pull to refresh

Comments 9

Поменяйте заголовок — никакой баг вы не исправили, просто последовали рекомендациям tac, а вопите так, как будто всю ночь дебаггером ковырялись и сами патч для ios написали. Что в прошлый раз была история из раздела «слабоумие и отвага», что в этот раз «доблестные сетевые админы в неравной схватке победили ACL».
Я нигде не писал, что мы исправили баг. Баг якобы был исправлен в нашей версии ios. И я не воплю, а рассказываю о сложностях с которыми пришлось столкнуться на деле. Возможно, кому-то это поможет избежать неприятностей.
1. Вы столкнулись не с тем багом, описание которого привели, впрочем это думаю недоработка инженера, не надо выдавать клиентам непроверенную информацию, но и его можно понять из-за пункта 2. Доказательства? Попробуйте воспроизвести conditions на вашей версии, и поймете что это не оно. Откуда я знаю? Потратил 2 месяца гоняясь за этим багом. Во всем мире только два задокументированных случая, один из них ваш. Что при этом было с коробками ни кто не знает. И правильно аккаунтинг придумали дураки, он не нужен…
2. Поддержка разработчиками SXJ окончена пол года назад. Я бы не ждал ответов на вашем месте, впрочем как и не задовал бы. И уж тем более бесполезно (пока) задавать проактивные вопросы: «что если бы да кабы...» Для этого существуют специальные службы и в зону обязаностей TAC не входит. Инженеры, конечно стараются, но результат бывает разный. Вместо этого не плохо было бы вместе с чисткой от пыли включить в регламент и поддержание актуальной версии IOS.
3. Как и предыдущий пост, этот слишком экспрессивен. VSS и сделан для того чтобы, если одно шасси выходит из строя, второе продолжало работать. Я бы вот радовался, что как круто, что не было ни какого импакта и прочитав логи можно исправить ситуацию за пару минут, причем самостоятельно, не прибегая к помощи интегратора и TAC.
Если это не описанный баг, то какой? Вам удалось это выяснить? И есть ли ссылка на второй случай, про который Вы упомянули?

Почему ответы на проактивные вопросы не входят в зону обязанностей CTAC? Разве эта инженерная служба не создана для поддержки их же оборудования и не должна обладать знаниями о поведении их железок в различных ситуациях?
Увы, установить RC не удалось из-за недостатка информации. Если сможете повторить или знаете шаги, которые привели к этой ситуации, то можем решим этот вопрос. Опять же если воспроизводится на поддерживаемых релизах. Анализ кода тоже ни чего не дал. Ссылка конечно есть, но доступна только сотрудникам.

Более того, проверял все хоть сколь-нибудь похожие дефекты на предмет регресии. CSCtx12231 очень похож, но не повторяется на sxj6. Так же проверил более старыe CSCtz90517, CSCtx01476, CSCtx12231. Без результатов…

По поводу рассуждений что должна и чего не должна конкретная служба написано в договоре. В данном случае SMARTNET. Почитайте чтобы у вас были правильные ожидания и понимание. Так же есть хорошие документа о том как работать с TAC на cisco support community русской. где-то здесь
Спасибо за статью. Мучаешься, мучаешься, а чувак из TAC даже в конфиги не лезет. Сразу show version и говорит, что баг.
А вот когда написано, что исправлено, а оно не исправлено — это жесть.
Да какая это жесть. Это так, вершина айсберга. Там еще столько жести есть — успевай записывать.
Cisco Bug Toolkit никто не отменял. Там же куда не плюнь, что не баг, то фича.
Из позитивного, задокументировано это весьма неплохо.
Я в своё время уже сталкивался с этими: «Known fixed». И приставал в поддержку. В общем, там история такая, что это следует читать так: «К этой версии есть патч, который решает данную проблему». В принципе, этот патч может дать инженер через тикет. Только поскольку это очень узкий патч, то он особо без регрессии тестируется, и бывает, что ломает что-то другое. Поэтому мне один из питерских инженеров говорил так: «Лучше апгрейд до следующей интересной версии, чем такой патч». Я с этим полностью согласен. :)
Sign up to leave a comment.

Articles