Comments 152
Мне кажется, с такой работой, интерес к квестовым играм для Вас потерян навсегда.
Так уж вышло, что последние 3 года я исключительно решаю проблемы пользователей. Не как эникейщик, на более высоком уровне, но это не меняет самого факта.
Ты так говоришь, будто это что-то плохое :) А между тем, работа в саппорте — возможность стремительно наращивать скиллы по массе направлений. Из саппортеров выходят лучшие сетевики.
Тут, кстати, начинаешь осознавать ценность CCIE. Это ведь по сути и есть сертификация инженера техподдержки. Первая часть — быстро вникнуть в новую для себя топологию и решить 10 проблем в темпе «в среднем 12 минут на проблему» (как раз демонстрация навыков грамотного траблшутинга). Можно пользоваться почти всей документацией, но часики-то тикают…
Мне проктор рассказывал, что 90% вопросов раздела TS — реальные кейсы, когда-то взрывавшие мозги сотрудникам TAC.
И экзамен вовсе не такой моновендорный, как кажется.
Так что рекомендую изучить курс CCIE SP, там много чего интересного (и полезного).
О, вовсе нет) Если бы это было так, я не позволил бы этому продлиться 3 года :)
Про экстремальный рост опыта ты прав. Устраиваясь на эту позицию я не ожидал, что уже через полгода придётся искать ответы на некоторые рабочие вопросы в материалах уровня CCIE.
Я вот другому поражаюсь, откуда у тебя столько времени, чтобы успевать всё это изучать и быть в курсе всех последних веяний :)
А до CCIE ещё рано, элементарные вопросы роутинга ещё не все знаю)
Про экстремальный рост опыта ты прав. Устраиваясь на эту позицию я не ожидал, что уже через полгода придётся искать ответы на некоторые рабочие вопросы в материалах уровня CCIE.
Я вот другому поражаюсь, откуда у тебя столько времени, чтобы успевать всё это изучать и быть в курсе всех последних веяний :)
А до CCIE ещё рано, элементарные вопросы роутинга ещё не все знаю)
а я уже который год только мечтаю о «лабе с настоящим железом», чтобы решать свои тикеты…
Вот по-доброму завидую, правда :) И с радостью бы поработал в таком саппорте. Ну и лаба с железом решает, хотя далеко не главное. Кстати, а в лабе только Хуавей, или она мультивендорная?
не понятно причем тут хуавей?
про него нислова. на скриншоте только видно окно securecrt и кусок конфига циски.
про него нислова. на скриншоте только видно окно securecrt и кусок конфига циски.
Лаба с железом, откровенно говоря пригождается в основном в тех случаях, когда подозреваешь проблемы с софтом или надо проверить, как пройдёт апгрейд.
В основном для проверки работы протоколов хватает симуляторов.
В основном для проверки работы протоколов хватает симуляторов.
Пока в ней чисто наше оборудование и то не всё. Поэтому тесты на совместимость проводить мы — инженеры первой линии — не можем.
Если у вас такая первая линия, то боюсь подумать, кто сидит на второй… Просто общаясь с тем же джунипером — там на первой линии такие индусы сидят, что ой)
Ну мы колцентр не считаем первой линией, как некоторые. Там и правда сидят ребята которые должны разбираться понемногу но во всём, чтобы правильно смаршрутизировать тикет.
Ну я не про коллцентр, просто сравниваю с ISP, где сейчас работаю, ну и JTAC джунипера, которым сдаем кейсы.
И там и там есть колл-центр, но по почте обычно все же общается саппорт.
И там и там есть колл-центр, но по почте обычно все же общается саппорт.
Ну, не скажите, я в HP дальше первой линии ухожу с большим сожалением. На ней сидят русские — а они ребята и адекватные и знают предмет и проверить в единицу времени успевают много. Когда это всё проваливается на L2 и дальше — там адъ, там iндусы сидят. Они однозадачные, и их надо долго врубать в тему. У меня были феерические кейсы, которые вели одновременно HP и Cisco, и один из них тянулся год(!) и он кончился ничем.
Не всё так плохо, при катастрофических падежах — однажды рухнул в кору 5412zl по причине оставленной ssh-сессии putty, патч сделали и прислали на следующий день.
Не всё так плохо, при катастрофических падежах — однажды рухнул в кору 5412zl по причине оставленной ssh-сессии putty, патч сделали и прислали на следующий день.
Признаюсь, когда кейс уходит на L2 по официальным каналам, он действительно может зависнуть на долгий срок. А L1 работает и правда максимально оперативно, насколько того требует SLA.
Когда кейсы тянутся год, это, скорее всего, проблема случилась однажды, и вы ходите знать причины. Бывает что по логам и диагностической информации это уже не восстановиться. И тогда: «выполните эти команды при повторении проблемы».
Когда кейсы тянутся год, это, скорее всего, проблема случилась однажды, и вы ходите знать причины. Бывает что по логам и диагностической информации это уже не восстановиться. И тогда: «выполните эти команды при повторении проблемы».
Ну в циске кейс иногда сходу попадает на комрада с подписью вроде такой:
Тоже суровая первая линия :) Хотя ходят слухи, что данный конкретный товарищ все-таки инженер эскалации.
CCIEx4 #20393 Voice/Security/RS/SP, CCDE 20120010
CISSP, MCSE 2003, ACA, IP Contact Center Express Specialist
Vmware Certified Professional
Тоже суровая первая линия :) Хотя ходят слухи, что данный конкретный товарищ все-таки инженер эскалации.
Ах, как звучит-то! «инженер эскалации» :)
А такое хвастовство в подписи к письму идёт?
А такое хвастовство в подписи к письму идёт?
Ага :) Обычно они указывают буквы «CCIE» (почти все такие).
И ты еще спрашиваешь меня, откуда у меня берется время что-то там почитывать…
И ты еще спрашиваешь меня, откуда у меня берется время что-то там почитывать…
Ну, таких, ведь единицы? Успокой меня :) Иначе можно считать себя совершенным лентяем и бездельником со своим единственным сертификатом Huawei)
Ну там почти все CCIE (Сергей Мороз из security team где-то на форумах писал, что нет формального требования наличия CCIE для трудоустройства в TAC, но в среднем CCIE будут уровнем повыше, чем не-CCIE), некоторые — дважды, но квад вроде лишь один. Их, насколько я знаю, по всей стране двое, второй в основном преподает…
Ну будучи в циске, получить сертификат, очевидно, проще.
Смотря с какой стороны посмотреть. Они сдают на правах случайного прохожего, без всяких привилегий. С другой стороны, у них уже есть мощный опыт и отличное обучение на внутренних тренингах (не под экзамен, а под работу, но и для экзамена полезно).
Вроде им и премии платят за каждую шайбу. То есть тем более нет смысла делать им поблажки.
Вроде им и премии платят за каждую шайбу. То есть тем более нет смысла делать им поблажки.
Не, это понятно, но есть три «но»:
1) хорошая практическая база
2) внутренние тренинги
3) близость к месту сдачи практического CCIE)
1) хорошая практическая база
2) внутренние тренинги
3) близость к месту сдачи практического CCIE)
3) Тоже не факт. TAC вроде не в Крылатском работает.
Так ведь практический экзамен в России вообще не принимается, какая разница Крылатское или нет?
Однако, это МСК и, возможно, поездка на сдачу, вообще как командировка оформляется :)
Удаление от политического центра страны увеличивает стоимость примерно на 20 тысяч рублей.
Однако, это МСК и, возможно, поездка на сдачу, вообще как командировка оформляется :)
Удаление от политического центра страны увеличивает стоимость примерно на 20 тысяч рублей.
У вас правильный и фундаментальный подход к решению сетевых проблем.
Красиво расписано. Только вот рекомендации как сделать, чтобы работало, в принципе инженер давать не обязан. Хорошо об этом просто подумать. Тогда может в следующий раз заказчик подумает о дизайне по лучше.
Не обязан, но степень его удовлеторения будет явно выше, если натолкнуть его на путь.
Инженеру ТАСа же это тоже полезно — добрый заказчик — проще решать с ним запросы и сам разобрался с тем, как это работает.
Плюс, если он не сможет настроить, то он в тот же ТАС опять и придёт со своими вопросами.
Инженеру ТАСа же это тоже полезно — добрый заказчик — проще решать с ним запросы и сам разобрался с тем, как это работает.
Плюс, если он не сможет настроить, то он в тот же ТАС опять и придёт со своими вопросами.
Полезно инженеру — 100%. Заказчику — не всегда. Новый тикет — плюс в KPI, нет? :) Заказчик добрится, как правило, когда видит, что его не бросили и по его проблеме работают и когда он получает адекватный ответ почему так произошло. В этих случаях иногда он даже может закрыть глаза на сроки. Ну, по личному опыту.
Ну я согласен, есть доля правды в ваших словах.
Разумеется, я не всегда даю альтернативные решения, но только когда случай того требует.
Вообще у нас действует простое правило: одна проблема, одно устройство — один тикет. Так что для KPIев их хватает. :)
Разумеется, я не всегда даю альтернативные решения, но только когда случай того требует.
Вообще у нас действует простое правило: одна проблема, одно устройство — один тикет. Так что для KPIев их хватает. :)
У заказчика не работает бизнес, так что он крайне не заинтересован в возникновении проблем.
Читал и чувствовал как будто кто-то мои мысли вытащил из башки и вылил в хабр :)
Если хочешь учить CCIE — найди кого-то, кто будет делать его с тобой паралельно.
Я начинал учиться один, откладывал каждый раз когда натыкался на явное несоответствие реальности моим понятиям о ней :) В основном, просто нужно было показать проблему кому-то ещё и всё прояснялось само собой (как с письмом клиенту).
Сейчас учимся втроём. Да, жизни нет, но во-первых — интересно! А во-вторых — оно того вполне стоит.
Если хочешь учить CCIE — найди кого-то, кто будет делать его с тобой паралельно.
Я начинал учиться один, откладывал каждый раз когда натыкался на явное несоответствие реальности моим понятиям о ней :) В основном, просто нужно было показать проблему кому-то ещё и всё прояснялось само собой (как с письмом клиенту).
Сейчас учимся втроём. Да, жизни нет, но во-первых — интересно! А во-вторых — оно того вполне стоит.
В идеале и жить надо втроем тогда :)
А начальство знает, как вы их решаете? Что ориентируетесь на ходу и по ходу? Не, я все понимаю, смелость города берет и все такое и если получается, то здорово. Но я на месте руководителя предпочел бы знать этот ньюанс. А то берешь на работу человека с гордым перечнем в резюме, а он потом это все читает по пути на работу-с-работы. И это еще повезет, если ты (руководитель) об этом не догадываешься, т.к. все гладко.
Вы же не думаете всерьёз, что я единственный специалист технической поддержки, что меня не собеседовали и в хвост и в гриву 3-4 бывалых, что критические запросы с SLA в 4 часа я решаю таким же образом?
И, конечно, начальство в курсе — вся система ведения тикетов вполне доступна моему руководству.
И, конечно, начальство в курсе — вся система ведения тикетов вполне доступна моему руководству.
Ну что не единственный — понятно. Все остальное — зачем гадать? Всякое бывает.
Все же странно это. У вас понимающее и весьма лояльное руководство.
Все же странно это. У вас понимающее и весьма лояльное руководство.
Объясните ваше представление о становлении специалиста? Очевидно, он не вылупляется из синтетической скорлупы со знанием MPLS TE? Что ещё, как не вдумчивое чтение и практика поможет в этом?
Крутя свое текущее хозяйство он учит MPLS TE/нужное_подставить. Может даже что-то пробует по мере возможностей. Что бы руку набить в азах. Меняя работу он честно говорит — по верхам и на уровне концепций, а так же основные теоретические моменты дизайна знаю, глубже изучить не было возможности из-за отсутствия практики. Когда лет 15 назад я был в похожем положении, но немного в другой специфике (да и время было другое, все только начиналось), я именно что в синтетической скорлупе сидел и ковырял маршрутизацию в linux, iptables, ip route, tc, все дела. Отлаженность процессов на текущем месте позволяла, время было. Потом в час Х сорвался и следующий работодатель получил не скажу, что готового специалиста, но все или почти все, чем пришлось заниматься было в теории знакомо в той или иной степени, что-то по несложной настольной практике. Опыта не хватало. Хотя я же не обвиняю вас. Если справляетесь и все получается — здорово, как я уже и говорил. Успехов :)
Ну, крутить своё хозяйство в ТАС-е не получается, знаете ли) А вот в свободное время читать документацию, стандарты и колупаться в лабе вполне.
Я не вижу тут обвинения в свой адрес, но в адрес работодателя. Такие должны быть, у них есть возможность обучать таких специалистов, какие вам нужны: готовых на второй день на интеграцию поехать.
Они лояльны, я согласен, но это неплохо, когда страхуют более опытные коллеги.
Я не вижу тут обвинения в свой адрес, но в адрес работодателя. Такие должны быть, у них есть возможность обучать таких специалистов, какие вам нужны: готовых на второй день на интеграцию поехать.
Они лояльны, я согласен, но это неплохо, когда страхуют более опытные коллеги.
Ну я бы на месте руководства ценил человека, который даже по пути на работу-с-работы изучает матчасть, старается развиваться. Большинство так не может.
Странные вещи вы говорите. По моему опыту, больше ценится не специалист, обладающий теоретическими знаниями в ваккууме, а спец, который умеет эти знания применять на практике, а что не знает — изучить и освоить в сжатые сроки. Это только в плюс, если человек любит и умеет учиться, причем постоянно.
У каждого специалиста есть своя цена, важно иметь несколько крутых специалистов на подстраховке/обучении и больше обучаемых на основной работе.
UFO just landed and posted this here
Да уж. Обычно телеком-тематика вне милости на хабре. Хорошие глубокие статьи остаются обделёнными вниманием.
Тут давеча на кспрадио обсуждали необходимость отдельного ресурса для связистов. Пришли к выводу, что не нужно)
Тут давеча на кспрадио обсуждали необходимость отдельного ресурса для связистов. Пришли к выводу, что не нужно)
Кстати а что у связистов кроме нага в почете? У программистов вон и Хабр, и RSDN (хотя там виндовые больше тусуются, но тем не менее).
Насколько мне известно.
NAG — как новостной портал.
и несколько форумов:
opennet
sysasmyns.
NAG — как новостной портал.
и несколько форумов:
opennet
sysasmyns.
Ну на НАГе весьма мощный форум, особенно что касается чисто прикладных вопросов. Ну и про opennet/sysadmins знаю, да. Просто думал, вдруг чего еще интересного пропустил)
К сожалению, нет.
Я бы хотел на хабре развить это направление, но нас здесь слишком мало.
Я бы хотел на хабре развить это направление, но нас здесь слишком мало.
Я бы тоже не против (можно, наверное, даже в личке обсудить?), но проблема в том, что Хабр уже такой, какой он есть. А нужно либо дотягивать что-то существующее, либо развивать с нуля… и то, и другое, требует прорву времени и сил)
вы пишите, мы поддержим. я всегда готов плюсануть телеком тему, если она не рекламная, а на хабре главное выйти за+7, далее тему поднимут
А KB по кейсам не планируете в чём-то помимо почты собирать?
Я тоже имею дело в саппортом хуавей, только не в России. И работают там, похоже, такие же «специалисты» как и автор. Результатом становится то, что они на ходу изучают новую для них фичу, а потом пытаются решить мою проблему предлагая свои зачастую заведомо нерабочие решения. Доходит до того, что я сам начинаю им объяснять почему их решение не поможет исправить проблему. Второй уровень поддержки — уже на уровне континента, чуть получше выполняют свою работу, но протестировать решение где-нибудь в лабе до того как предлагать внедрить клиенту тоже не удосуживаются. И только последний уровень, он же R&D расположеный в китае действтиельно знают свое дело, но чтобы до них добраться нужно сначала потратить несколько дней на 1 и второй уровень.
На мой взгляд, специалист поддержки должен сначала изучить технологию сдать экзамены, сертификаты и т.п. и только после этого начинать заниматься тикетами по этой технологии. Автор поступает наоборот в результате чего часто могут пострадать конечне пользователи.
Извините, наболело, Хуавеевский суппорт просто отвратителен :(
На мой взгляд, специалист поддержки должен сначала изучить технологию сдать экзамены, сертификаты и т.п. и только после этого начинать заниматься тикетами по этой технологии. Автор поступает наоборот в результате чего часто могут пострадать конечне пользователи.
Извините, наболело, Хуавеевский суппорт просто отвратителен :(
Я прощаю вам ваш необоснованный выпад в мой адрес.
Сказать в защиту неРоссийского офиса ничего не могу, ибо не имел с ними дело. Если они не проверяют свои рекомендации перед предоставлением, это их недостаток, я согласен.
Но, чёрт возьми, нельзя ставить в вину инженеру, что он учится вместе с вами. Понимаете, нельзя знать совершенно всего. Даже наш самый продвинутый инженер может впасть в ступор от некоторых вопросов по MVPN или реализации MPLS DS-TE.
Или вы ожидаете с обратной стороны увидеть интеллектуальную телекоммуникационную википедию?
Сказать в защиту неРоссийского офиса ничего не могу, ибо не имел с ними дело. Если они не проверяют свои рекомендации перед предоставлением, это их недостаток, я согласен.
Но, чёрт возьми, нельзя ставить в вину инженеру, что он учится вместе с вами. Понимаете, нельзя знать совершенно всего. Даже наш самый продвинутый инженер может впасть в ступор от некоторых вопросов по MVPN или реализации MPLS DS-TE.
Или вы ожидаете с обратной стороны увидеть интеллектуальную телекоммуникационную википедию?
Не хотел конкретно вас оскорблять, прошу прощения. Я лишь хочу сказать, что обращаясь за поддержкой я ожидаю что моей проблемой будет заниматься специалист, который уже хорошо разбиратеся в технологии, а не читает мануалы вместе со мной.
Проведем аналогию, вы вызываете электрика, который должен выполнить работы в вашей квартире. К вам приходит свежий «специалист» и читает учебник у вас дома пытаясь сделать работу так чтобы ваша квартира не сгорела на следующий день из-за того что он совершил ошибку? Какие будут ваши чувства? Обратитесь ли вы в к этому электрику еще раз?
Поэтому, я считаю, что решением клиентских тикетов должен заниматься реальный специалист, а остальные обучающиеся специалисты потом могут использовать уже решенный тикет как кейс для изучения. Ваш рассказ лишь подтверждает то, что политика хуавея относительно их саппорта одинакова для разных стран. При этом я ничего не имею против вас конкретно, возможно вы делаете свою работу хорошо, но с точки зрения бизнеса так делать нельзя, имхо.
Проведем аналогию, вы вызываете электрика, который должен выполнить работы в вашей квартире. К вам приходит свежий «специалист» и читает учебник у вас дома пытаясь сделать работу так чтобы ваша квартира не сгорела на следующий день из-за того что он совершил ошибку? Какие будут ваши чувства? Обратитесь ли вы в к этому электрику еще раз?
Поэтому, я считаю, что решением клиентских тикетов должен заниматься реальный специалист, а остальные обучающиеся специалисты потом могут использовать уже решенный тикет как кейс для изучения. Ваш рассказ лишь подтверждает то, что политика хуавея относительно их саппорта одинакова для разных стран. При этом я ничего не имею против вас конкретно, возможно вы делаете свою работу хорошо, но с точки зрения бизнеса так делать нельзя, имхо.
Ну смотрите, можно я расскажу, как работаю я, чтобы было понятно.
Для простоты возьмём запрос важности Minor и SLA 30 дней?
Минор предполагает наличие сервисов в полном объёме. Не работает некритичный функционал. Это развязывает руки в плане времени.
В Хуавэе действует некое ограничение на время эскалации. Оно не строгое, но рекомендуется к выполнению — если не смог решить за такой-то период, лучше эскалируй — займётся L2.
Итак, это время я распределяю на получение всех данных, удалёнки, изучение матчасти, моделирование в лабе. Если есть сомнения по рекомендациям, консультируюсь с китайскими коллегами (местными или из R&D) и с более опытными русскими инженерами.
Да, я могу иметь меньше опыта и знаний, чем инженер заказчика — обычно так и бывает, но и заказчик должен иметь снисхождение, если я не советую откровенную ерунду. В конце концов — я лишь L1. Моя задача отсеить элементарные тикеты, исключить возможные описанные прежде проблемы и приложить все усилия, чтобы решить проблему, если она связана с настройкой.
Не хочу быть адвокатом Хуавэй, но и такой крайней строгости пополам с негативом не ожидал.
Откуда должен браться готовый специалист? Если запрос упал на инженера он решает его независимо от того, был ли подобный кейс прежде или нет. Или должен перебрасывать сразу не более опытного?
Для простоты возьмём запрос важности Minor и SLA 30 дней?
Минор предполагает наличие сервисов в полном объёме. Не работает некритичный функционал. Это развязывает руки в плане времени.
В Хуавэе действует некое ограничение на время эскалации. Оно не строгое, но рекомендуется к выполнению — если не смог решить за такой-то период, лучше эскалируй — займётся L2.
Итак, это время я распределяю на получение всех данных, удалёнки, изучение матчасти, моделирование в лабе. Если есть сомнения по рекомендациям, консультируюсь с китайскими коллегами (местными или из R&D) и с более опытными русскими инженерами.
Да, я могу иметь меньше опыта и знаний, чем инженер заказчика — обычно так и бывает, но и заказчик должен иметь снисхождение, если я не советую откровенную ерунду. В конце концов — я лишь L1. Моя задача отсеить элементарные тикеты, исключить возможные описанные прежде проблемы и приложить все усилия, чтобы решить проблему, если она связана с настройкой.
Не хочу быть адвокатом Хуавэй, но и такой крайней строгости пополам с негативом не ожидал.
Откуда должен браться готовый специалист? Если запрос упал на инженера он решает его независимо от того, был ли подобный кейс прежде или нет. Или должен перебрасывать сразу не более опытного?
Специалисты обычно готовятся внутри компании, либо нанимаются со стороны. Инженер L1 должен собрать всю необходимую информацию и, если не знает как решать, передать на уровень выше. Конечно, в случае, который вы описали(minor, sla 30 дней), у вас есть полно времени и никто не возражает чтобы вы изучали что-либо и пытались решить проблему самостоятельно.
Я лишь рассказываю про мой опыт работы с Хуавей и я в нем заметил некоторые схожие черты в вашем рассказе. После ваших пояснений я вижу, что у вас всё происходит значительно разумнее. В моих случаях я могу получать бесполезные советы от неопытных L1 даже в случае критичной проблемы.
Я лишь рассказываю про мой опыт работы с Хуавей и я в нем заметил некоторые схожие черты в вашем рассказе. После ваших пояснений я вижу, что у вас всё происходит значительно разумнее. В моих случаях я могу получать бесполезные советы от неопытных L1 даже в случае критичной проблемы.
нельзя ставить в вину инженеру, что он учится вместе с вами. Понимаете, нельзя знать совершенно всего. Даже наш самый продвинутый инженер может впасть в ступор от некоторых вопросов по MVPN или реализации MPLS DS-TE.
Немного поработаю адвокатом дьявола.
Вот у меня есть некоторая проблема, которую я не в силах решить, или на решение которой мне лень тратить много часов рабочего времени. Допустим, направление — распространеннее некуда, что-то с маршрутизацией, но вопрос нетривиальный. В случае циски кейс попадает на Data Network Group — работающую конкретно по протоколам маршрутизации. Я наверняка знаю все, что связано с голосом, безопасностью/VPN и т.д. больше многих из них, ибо каждый день с этим сталкиваюсь. Но вот по части роутинга они знают примерно всё, вплоть до таких глубин CEF, о которых ни в каких публичных доках не рассказывается.
Был опыт: один инженер (CCIE) из интегратора, которому ради пробы поручили траблшутинг одной проблемы на стыке MPLS и GRE (почему-то пакеты с одной стороны в роутер входили, а с другой отказывались выходить, а я тогда еще маленький был). Пара месяцев — никакого результата. Но сотрудник TAC, которому я как-то мимоходом об этом упомянул в телефонном разговоре, за пару секунд выдал команду, исправляющую проблему. Т.е. есть вещи, которые надо просто знать. Если заранее не знаешь, то можно очень долго копать в неправильном направлении, гадая, почему по докам оно работать должно, а по факту не работает.
Были кейсы по довольно редким системам, с которыми у TAC мало опыта. Я как заказчик испытывал легкий разрыв шаблона, когда оказывалось, что инженер знает не больше моего, и вместе со мной изучает систему вместо того, чтобы взглянуть на имеющиеся данные, запросить уточнение и выдать результат. К счастью, в этом случае кейс довольно быстро эскалируют до девелопера.
Так что я, запрашивая вендора по поводу MPLS, ожидаю, что мне ответит сотрудник группы «service provider» (или как ее там), обладающий глубочайшими знаниями по всему, что связано с MPLS (в том числе и с мультикастом поверх него), и, возможно, при этом не знающий внутренних различий между CST и RSTP (не его профиль, для этого есть группа LAN switching, которая при этом запросто может плохо понимать MPLS).
Давайте я вам расскажу про отвратительный Cisco-вский support? Вам будет легче?
На мой взгляд, трудно найти адекватный саппорт + адекватность саппорта убывает с ростом вашей осведомленности в предметной области.
Никогда не звонили в саппорт своего провайдера? Я сначала ерепенился, отказывался проверять «лампочки» и перезагружать компьютер. Потом смирился, давал первой линии выполнить их «ритуал» чтобы меня передать второй а то и третьей линии где сидят вменяемые специалисты.
А что касается саппорта Cisco — то моя метода:
1. Просить русских инженеров. Как правило они очень осведомленные и адекватные люди.
2. Записываю имя и фамилию хорошего инженера. Потом, при открытии нового тикета прошу назначить его на мой тикет.
3. Отношусь терпимо к незнанию инженера. У него, кроме меня есть еще и другие тикеты + ему надо еще разобраться в конкретном дизайне, который может быть очень далеко от стандартного.
На мой взгляд, трудно найти адекватный саппорт + адекватность саппорта убывает с ростом вашей осведомленности в предметной области.
Никогда не звонили в саппорт своего провайдера? Я сначала ерепенился, отказывался проверять «лампочки» и перезагружать компьютер. Потом смирился, давал первой линии выполнить их «ритуал» чтобы меня передать второй а то и третьей линии где сидят вменяемые специалисты.
А что касается саппорта Cisco — то моя метода:
1. Просить русских инженеров. Как правило они очень осведомленные и адекватные люди.
2. Записываю имя и фамилию хорошего инженера. Потом, при открытии нового тикета прошу назначить его на мой тикет.
3. Отношусь терпимо к незнанию инженера. У него, кроме меня есть еще и другие тикеты + ему надо еще разобраться в конкретном дизайне, который может быть очень далеко от стандартного.
Да, у циски и джунипера тоже бывают косяки, но такого чтобы они давали мне заведомо неработающее решение только из-за своей некомпетентности — никогда. А с Хуавеем такое бывает частенько.
В ISP я работаю уже 6 лет :) и про их саппорт знаю много и прекрасно понимаю зачем нужно проходить все тривиальные процедуры с L1, но когда L1 начинает заниматься тем, что ему не под силу — это неправильно, клиент не должен страдать из-за того что кто-то из сотрудников хочет потренироваться на живом клиенте. И уж тем более такое нельзя поощрять.
В ISP я работаю уже 6 лет :) и про их саппорт знаю много и прекрасно понимаю зачем нужно проходить все тривиальные процедуры с L1, но когда L1 начинает заниматься тем, что ему не под силу — это неправильно, клиент не должен страдать из-за того что кто-то из сотрудников хочет потренироваться на живом клиенте. И уж тем более такое нельзя поощрять.
Хм. У меня нет опыта с Juniper-ом или хуавеем. С Cisco опыт разный и опыт обширный. Давали ли они мне работающие или неработающие решения — я вспомнить не могу, к сожалению, неработающие решения я отметал сразу в процессе разговоров-рассуждений. Некомпетентность в Cisco встречал очень много раз. Например, один из самых вопиющих случаев был, когда вязал Cisco CUCM 3.x.x (уже забыл версию) и CUCM 6.0.x. Вязал h.323 транком. И в одном из условий голосовой канал не проключался в одном из направлений. wireshark-ом нашел закономерность когда это происходит. Открыл тикет в Cisco TAC. Дали инженера. На третьей неделе снятия дампов с cucm-а мне был задан вопрос — «а что же это такое h323 который я все время упоминаю?»
Я несколько шокировался вопросом, послал ссылку на wikipedia со статьей об h323 и просто перестал отдавать свое время тикету (попытался его эскалировать, но менеджер инженера мне рассказал дважды как хорошо инженер справляется со своей задачей). Потом я закрыл тикет, поняв, что проблему не решить. Этот тикет имел неожиданное продолжение. После того как я проставил инженеру неудовлетворительную оценку, звонил менеджер, интересовался чем я недоволен. Обьяснил ситуацию. И, через полтора месяца, этот же самый инженер позвонил снова и сообщил мне что Cisco выпустила внутренний релиз и не желаю ли я проверить на своем рабочем окружении, вдруг там моя проблема починиться. Я спросил о том, были ли изменении в h323 подсистеме в этом релизе, на что мне было отвечено — не знаю. Я опять закрыл тикет.
Так что автор этой статьи — это не самое плохое, что может быть. Я больше скажу — я бы хотел попасть на такого инженера.
Я несколько шокировался вопросом, послал ссылку на wikipedia со статьей об h323 и просто перестал отдавать свое время тикету (попытался его эскалировать, но менеджер инженера мне рассказал дважды как хорошо инженер справляется со своей задачей). Потом я закрыл тикет, поняв, что проблему не решить. Этот тикет имел неожиданное продолжение. После того как я проставил инженеру неудовлетворительную оценку, звонил менеджер, интересовался чем я недоволен. Обьяснил ситуацию. И, через полтора месяца, этот же самый инженер позвонил снова и сообщил мне что Cisco выпустила внутренний релиз и не желаю ли я проверить на своем рабочем окружении, вдруг там моя проблема починиться. Я спросил о том, были ли изменении в h323 подсистеме в этом релизе, на что мне было отвечено — не знаю. Я опять закрыл тикет.
Так что автор этой статьи — это не самое плохое, что может быть. Я больше скажу — я бы хотел попасть на такого инженера.
Просить русских инженеров. Как правило они очень осведомленные и адекватные люди.
О да…
Когда CSS (балансировщик) отказывался качать софт с FTP сервера, мне один йеменец несколько часов предлагал проверить настройки аутентификации на FTP сервере. Даже когда я послал ему дамп пакетов, в котором было «SYN — SYN ACK — RST». Через пару дней выяснилось, что CSS просто не поддерживает закачку софта по FTP с серверов в других VLANах…
Я поставил вам минус за неадекватный выпад.
Почему вы думаете, что специалист поддержки должен знать больше вас.
Как же вас вообще допустили к настройке оборудования, если вы не знаете всего?
Вы в ходе решения этой проблемы выбирали только заведомо рабочие варианты?
Если все ваши проблемы будет решать R&D то вашей компании будет проще олачивать поддержку высокого уровня чем держать вас.
Почти во всех компаниях(по крайней мере в моей области — встраиваемые системы) есть опция сильно платной тех-поддержки, степень вовлеченности инженера которой в ваш проект может доходить до «сделаю все за вас». Из моих клиентов _никто_ ей ниразу не воспользовался.
Я зашел в ваш профиль и вы не написали ни одной статьи — вообще зачем вы здесь?
Человек поделился своим опытом а вы что сделали?
Почему вы думаете, что специалист поддержки должен знать больше вас.
Как же вас вообще допустили к настройке оборудования, если вы не знаете всего?
Вы в ходе решения этой проблемы выбирали только заведомо рабочие варианты?
Если все ваши проблемы будет решать R&D то вашей компании будет проще олачивать поддержку высокого уровня чем держать вас.
Почти во всех компаниях(по крайней мере в моей области — встраиваемые системы) есть опция сильно платной тех-поддержки, степень вовлеченности инженера которой в ваш проект может доходить до «сделаю все за вас». Из моих клиентов _никто_ ей ниразу не воспользовался.
Я зашел в ваш профиль и вы не написали ни одной статьи — вообще зачем вы здесь?
Человек поделился своим опытом а вы что сделали?
Почему вы думаете, что специалист поддержки должен знать больше вас.
Чтобы решить ту проблему, которую я не осилил, раз я обратился к нему :) Логично?
Если все ваши проблемы будет решать R&D то вашей компании будет проще олачивать поддержку высокого уровня чем держать вас.
1) R&D не относится к поддержке.
2) Поддержка работает только когда возникают проблемы. Она не занимается штатным сопровождением систем, это было бы аутсорсингом.
3) Во время факапа инженер должен сам уметь закрыть хотя бы костылем любую проблему и устранить внешние проявления аварии — так как каким бы гениальным ни был инженер техподдержки, ему придется с нуля вникать в структуру вашей сети, а я ее уже знаю, что может сэкономить очень много времени. Да и заведение заявки — дело вовсе не мгновенное.
4) У нас очень многое на аутсорсе (когда сотрудник другой компании в буквальном смысле делает всё за нас). Только это не поддержка вендора. Они именно что сопровождают системы, выполняя рутинные операции. И да, сейчас почти в любой компании найдется что-то на аутсорсе. Особенно это касается крупных компаний.
Знаю пример, когда инженер из хуавея натурально работал на территории клиента продолжительное время и помогал с косяками/настройкой. Это саппорт или аутсорс?)
Это вполне типичная ситуация, когда идёт интеграция или какие-то иные on-site работы.
Все знают. Но это — неправильный саппорт. Правильный саппорт — решение проблем удаленно. Хотя есть и «configuration assistance», но тут есть закономерные ограничения.
И важный момент: обычно инженер TAC сам не работает с железом, а говорит клиенту, что вводить. Хотя в особо интересных случаях он по webex сессии может захватить управление. Однако, суть не меняется: саппорт дает рекомендации, а не занимается настройкой чего-либо, в то время как аутсорс — именно полноценное сопровождение.
И важный момент: обычно инженер TAC сам не работает с железом, а говорит клиенту, что вводить. Хотя в особо интересных случаях он по webex сессии может захватить управление. Однако, суть не меняется: саппорт дает рекомендации, а не занимается настройкой чего-либо, в то время как аутсорс — именно полноценное сопровождение.
про R&D ответ был на:
И только последний уровень, он же R&D расположеный в китае действтиельно знают свое дело, но чтобы до них добраться нужно сначала потратить несколько дней на 1 и второй уровень.
И к сожалению(или наоборот) иногда может относиться к поддержке, по крайней мере в моей области.
Штатным сопровождением поддержка не занимается, но проблема это для всех разное понятие, например если проблема в настройке оборудования, а эта процедура описана в мануле, то вроде это и не проблема ведь? RTFM. Оказывается это не так.
С остальными согласен, единственное: по уровню специлиста — это было бы действительно здорово, если бы все были супер спецами, в том числе и клиенты :-)
И только последний уровень, он же R&D расположеный в китае действтиельно знают свое дело, но чтобы до них добраться нужно сначала потратить несколько дней на 1 и второй уровень.
И к сожалению(или наоборот) иногда может относиться к поддержке, по крайней мере в моей области.
Штатным сопровождением поддержка не занимается, но проблема это для всех разное понятие, например если проблема в настройке оборудования, а эта процедура описана в мануле, то вроде это и не проблема ведь? RTFM. Оказывается это не так.
С остальными согласен, единственное: по уровню специлиста — это было бы действительно здорово, если бы все были супер спецами, в том числе и клиенты :-)
если проблема в настройке оборудования, а эта процедура описана в мануле, то вроде это и не проблема ведь?
Почему не проблема? Клиент пытается что-то настроить, у него не получается. Нормальный повод для открытия кейса класса «configuration assistance», и TAC подскажет, что не так: то ли проблема в ДНК клиента, то ли в багах, то ли в документации. Я сталкивался со всеми этими случаями не раз и не два.
А вот кейс «как сделать, чтобы получилось вот эдак», или тем более «настройте мне вот это» может быть сходу закрыт, если у инженера техподдержки плохое настроение, и он будет прав.
На практике не может он быть закрыт инженером. Во всяком случае не у нас. На закрытие нужно согласие клиента. Если там проблема «в ДНК», то решается на уровень выше. Но сам просто так не можешь закрыть.
Ну в моем случае, когда инженер аргументированно говорит «это вне компетенции TAC», я не пробовал с ним спорить (хотя могу очень вежливо попросить намекнуть, куда копать, и обычно они подскажут). Наверное, если начать спорить, на свет выйдет менеджер, только с тем же результатом.
Под «в ДНК» имелось в виду «клиент криво настроил, а софт и документация в порядке».
Под «в ДНК» имелось в виду «клиент криво настроил, а софт и документация в порядке».
Мне кажется между «я делал так и так — не работает», и «я хочу чтобы было так» граница довольно тонкая. И чем меньше клиент потратил времени на размышления «как сделать чтобы работало» тем это ближе к «я хочу чтобы было так».
например если проблема в настройке оборудования, а эта процедура описана в мануле, то вроде это и не проблема ведь?
Мне кажется, тут решает уровень саппорта, оплаченный клиентом
А почему не может быть в разных зонах роутеров с одинаковыми router-id?
Если зоны не смежные, то, мне кажется, проблем не будет. Главное — чтобы никто не получал одновременно LSA с обоих.
Если зоны не смежные, то, мне кажется, проблем не будет. Главное — чтобы никто не получал одновременно LSA с обоих.
Могут возникнуть очень забавные глюки. Например, если ID ASBR'а совпадает с ID роутера в любой другой области.
Можно разного наворотить и это будет работать, но это же не значит, что так следует делать — рано или поздно это рванёт.
Была у нас ситуация: заказчик хотел такую сеть:
Марш-р----192.168.0.0/24----Марш-р-----192.168.0.0/24.
На закономерный вопрос: «Зачем?» он ответил: У нас раньше так было и работало с другим оборудованием, а ваше НЕ РАБОТАЕТ. :)
Была у нас ситуация: заказчик хотел такую сеть:
Марш-р----192.168.0.0/24----Марш-р-----192.168.0.0/24.
На закономерный вопрос: «Зачем?» он ответил: У нас раньше так было и работало с другим оборудованием, а ваше НЕ РАБОТАЕТ. :)
Вот насчет «у меня раньше работало, а у вас не работает» это долгая и печальная тема) Бо клиент обычно предлагает такое, что волосы на затылке шевелятся…
Вот уж это точно. Но самые фиговые запросы — 3 дня назад упал протокол. Сейчас всё работает. Что было? ))
Честно говоря, я сам нередко такое завожу. Ну не 3 дня, а несколько часов, только это ничего не меняет.
Вот случается авария, которой не должно было быть — скажем, с маршрутизацией. Разумеется, я сам ее устраняю — это быстрее, чем заводить кейс. Но когда проблема уже устранена, я пытаюсь разобраться, и не понимаю, в чем причина факапа и как исключить его повторение. Тогда я завожу кейс в надежде, что в базе знаний вендора есть что-то подобное, или что более опытный инженер TAC заметит нечто пропущенное мной, и прикрепляю логи своих сессий с детальным описанием сценария и своих действий. В 2/3 случаев кейс закрывается как невоспроизводимый с пометкой вроде «повторится — меняем железку», но в одном случае из трех причину удается выяснить.
Вот случается авария, которой не должно было быть — скажем, с маршрутизацией. Разумеется, я сам ее устраняю — это быстрее, чем заводить кейс. Но когда проблема уже устранена, я пытаюсь разобраться, и не понимаю, в чем причина факапа и как исключить его повторение. Тогда я завожу кейс в надежде, что в базе знаний вендора есть что-то подобное, или что более опытный инженер TAC заметит нечто пропущенное мной, и прикрепляю логи своих сессий с детальным описанием сценария и своих действий. В 2/3 случаев кейс закрывается как невоспроизводимый с пометкой вроде «повторится — меняем железку», но в одном случае из трех причину удается выяснить.
Ну да, понятно, и это правильно. Просто такой тип запросов действительно сложен для решения. Уж лучше критикал отработать. :)
Но зачастую по логам можно восстановить хронологию. Многие инженеры заказчика просто даже не заглядывают в подробные логи — деньги же заплатили.
Но зачастую по логам можно восстановить хронологию. Многие инженеры заказчика просто даже не заглядывают в подробные логи — деньги же заплатили.
Но зачастую по логам можно восстановить хронологию. Многие инженеры заказчика просто даже не заглядывают в подробные логи
Я заглядываю. И хронология обычно понятна. А вот триггер — то, с чего все началось — часто неведом. Ну например было: лупбек на ровном месте без всякой видимой причины перестал анонсироваться в EIGRP, из-за этого сломался LDP до соседей и развалились LSP, и посреди сети образовалась черная дыра, в которую затягивало часть пакетов между VRFами. Единственное, что помогло — скопировать конфиг лупбека, удалить его целиком, потом средствами ctrl+insert воссоздать в первозданном виде. После этого он засветился, и LDP состыковался.
Т.е. с хронологией-то проблем никаких, но… чо это было? :)
Если мне память не изменяет, эта проблема попала в те самые неудачливые 2/3. И она ни разу не повторялась.
По секрету скажу, у Хуавэй триггеры бывают очень замудрённые:
Через 59 дней после выполнения команды display interfaces падает OSPF-пиринг.
Или:
В случае если резетнулась резервная управляющая плата, меняется какой-то флаг в мульткастовой таблице маршрутизации для одной записи и дальше она не передаётся.
Что-то похожее бывает в реале. Это баги софта. И да, их бывает крайне сложно отловить. Согласен.
Через 59 дней после выполнения команды display interfaces падает OSPF-пиринг.
Или:
В случае если резетнулась резервная управляющая плата, меняется какой-то флаг в мульткастовой таблице маршрутизации для одной записи и дальше она не передаётся.
Что-то похожее бывает в реале. Это баги софта. И да, их бывает крайне сложно отловить. Согласен.
Вот говорите, что у Cisco всё плохо, попробуйте добиться саппорта у Avaya, при том что оборудование свежекупленное, а дилер в этом оборудовании ничего не понимает и прячется от заказчика, а в Avaya просто не берут трубку. Техсаппорт через конференцию Комптека — хорошо там люди адекватные сидят. В общем, железо хорошее, но качество поддержки в РФ ниже плинтуса.
В топике и комментариях речь о техподдержке на основе контракта со многими ноликами. А у вас, насколько я понял, его с Аваей нет.
Если бы был, то они бы никак не отвертелись, принимали бы запросы и работали бы (другой вопрос как).
А вообще и Авая и телефония в общем — это отдельная песня. Материала очень мало и такое ощущение, что знания от отца к сыну передаются)
Если бы был, то они бы никак не отвертелись, принимали бы запросы и работали бы (другой вопрос как).
А вообще и Авая и телефония в общем — это отдельная песня. Материала очень мало и такое ощущение, что знания от отца к сыну передаются)
Много разного слышал про саппорт Алкателя (грустного). У Хуавея очень выросла компетенция и по саппорту и по мануалам, правда внутри пока все еще черти что твориться, народу мало, работы много :)
Материала по Avaya, как раз очень много. Родной документации — около нескольких тысяч страниц. Другое дело, что она написана вообще — для самых разных случаев, продуктов, сигнализаций, стран и конфигураций. Вычленить что относится к самому себе — не так просто, особенно когда из года в год меняются названия продуктов. Очень часто документация представляет собой очевидное описание меню, вместо принципов того, что делается внутри.
Надо отдать должное — у Avaya хорошие application notes, там очень многое можно подсмотреть, уже если не в точности под нужное оборудование, то хотя бы под подобное.
P.S. Контракт, он разный бывает. На новое оборудование обычное есть дефолтный контракт на полгода/год — как раз на то, чтобы решить неотложные вопросы на запуске. У HP на его железо Procurve вообще пожизненное — они могут себе это позволить
Надо отдать должное — у Avaya хорошие application notes, там очень многое можно подсмотреть, уже если не в точности под нужное оборудование, то хотя бы под подобное.
P.S. Контракт, он разный бывает. На новое оборудование обычное есть дефолтный контракт на полгода/год — как раз на то, чтобы решить неотложные вопросы на запуске. У HP на его железо Procurve вообще пожизненное — они могут себе это позволить
Спасибо за статью!
Отвлеченный вопрос: Когда же выйдет первый выпуск подкаста для связистов? :)
Отвлеченный вопрос: Когда же выйдет первый выпуск подкаста для связистов? :)
Хочу обрадовать, через примерно 2 недели. Он уже записан, ждём только музыку, с которой пока проблемы.
оО, а где подписываться? страница подкаста?
linkmeup.ru
Там же и все выпуски СДСМ. Ну так, на всякий случай)
Там же и все выпуски СДСМ. Ну так, на всякий случай)
Отличная новость, спасибо!
Это примеры из головы? Если кто-то действительно так строит, то таким надо запрещать занимать инженерные позиции в телекомах. И 3 года исправительных работ в саппорте 1-ой линии.
В топике примеры реальных кейсов. Но простите, что не так в них?
Мультиария в оспф например.
Ну это как бы фунцкионал OSPF и не костыль, вроде виртуального линка. Когда счёт узлов в сети идёт на сотни, над такими вещами начинаешь задумываться. И тут спорный вопрос использовать зоны или нет, учитывая желания MPLS TE.
Но говорить о «запрещать занимать инженерные позиции» как-то лихо, не находите?
Но говорить о «запрещать занимать инженерные позиции» как-то лихо, не находите?
Ну покажите мне сеть, где сотни узлов не лезут в одну арию?
Не лихо, все рписано в умных книжках. Но в 99% случаев инженер не исследует вопрос, а лепит так, что бы «было круто». Спрашиваешь: «зачем? нахуя?». Молчат.
Не лихо, все рписано в умных книжках. Но в 99% случаев инженер не исследует вопрос, а лепит так, что бы «было круто». Спрашиваешь: «зачем? нахуя?». Молчат.
Ну что значит, не лезут? Конечно лезут, но зачем тупиковым аксессным железкам со слабой проивзодительностью, знать тысячи маршрутов и сотни роутеров топологии, когда у них есть один гейтвей?
Я не буду спорить, потому что дизайн бывает разный. Но судить об уровне инженера только по использованию зон OSPF, как минимум поверхностно.
Я не буду спорить, потому что дизайн бывает разный. Но судить об уровне инженера только по использованию зон OSPF, как минимум поверхностно.
Но судить об уровне инженера только по использованию зон OSPF, как минимум поверхностно.
Ну если он бьет сеть на зоны, зная про потребность в TE, и внезапно для себя сталкивается с довольно предсказуемой проблемой — это уже о чем-то говорит.
А что не так с TE в случае с несколькими area в ospf? Работает же, судя по документации? В реальности не пробовал.
Только вот может в этом разобраться, а сам он нет. Вывод: профнепригоден.
Ну собственно, сеть на зоны могла быть разбита прежде, а потребнось в TE появилась недавно.
Не хочу выгораживать конкретного человека — просто стараюсь быть объективным в оценке человека на основании одного факта.
Не хочу выгораживать конкретного человека — просто стараюсь быть объективным в оценке человека на основании одного факта.
ТЕ через мультиарию и появилось как костыль для тех, кто давно-давно понастроил сетей и никак не хочет редизайнить.
Опять же, зачем им ТЕ? Файловер? Именно инжиниринг трафика?
Опять же, зачем им ТЕ? Файловер? Именно инжиниринг трафика?
В данном случае есть решение в виде explicit-path loose mode. Насколько мне известно, это не является костылём для мультиарии.
На вопрос зачем провайдеру TE я теряюсь что ответить. Собственно управление трафиком, FRR, не для того, чтобы было круто — у заказчика вполне конкретные бизнес задачи.
На вопрос зачем провайдеру TE я теряюсь что ответить. Собственно управление трафиком, FRR, не для того, чтобы было круто — у заказчика вполне конкретные бизнес задачи.
На вопрос зачем провайдеру TE я теряюсь что ответить.
По опыту работы со многими крупными провайдерами — при авариях трафик если и перемаршрутизируется за десятки миллисекунд, то одновременно с кучей других логических каналов других заказчиков, которые все вместе упрутся в емкость физики, и в результате всем будет куда хуже, чем если бы канал просто упал. Заказчику приходится городить свои костыли на базе IP SLA, а не полагаться на наличие кипалайвов IGP.
Гибкое управление трафиком — возможно. Только это используется для повышения уровня переподписки на транспортной сети оператора, что с точки зрения клиента плохо.
Ну это вопрос планирования сети и сервисов. При внедрении TE нужно учитывать рост объёма трафика на резервных линках в случае падения основных. Это базис, и он написан в любой книге про MPLS.
А заказчик так или иначе всегда сам должен перестраховаться. Иначе это как с пешеходным переходом. Автомобилист обязан пропустить пешехода, но если он не пропустит, а пешеход не проверит, кому будет хуже?
Что имеешь ввиду?
А заказчик так или иначе всегда сам должен перестраховаться. Иначе это как с пешеходным переходом. Автомобилист обязан пропустить пешехода, но если он не пропустит, а пешеход не проверит, кому будет хуже?
Только это используется для повышения уровня переподписки на транспортной сети оператора
Что имеешь ввиду?
Что имеешь ввиду?
Средствами IGP сложно выровнять нагрузку по всем линкам и довести ее, скажем, до 80-90% без дропов. Потому надо иметь больше емкости в запасе на магистралях и меньше абонентского трафика. TE дает гибкость, можно при штатном состоянии сети выжать из нее почти все соки, но вот кто-то хронически забывает, что при отказе одного линка трафик, шедший через него, надо грамотно размазать по остальной сети. Желательно не по autotunnel, а по-человечески… Но вот почему-то не получается.
Если NH один, то там вообще ospf ненужен.
Добавим в мультиарию одинаковые router id и уже картина маслом. Человек даже Халаби видимо не читал.
Добавим в мультиарию одинаковые router id и уже картина маслом. Человек даже Халаби видимо не читал.
А если выхода два — топология кольцо, как это чаще всего и бывает?
Добавлять одинаковые Router ID. Это уже не из дизайна сетей, а из знания протоколов. И это уже, да, было бы поводом говорить о компетенции инженера.
Добавлять одинаковые Router ID. Это уже не из дизайна сетей, а из знания протоколов. И это уже, да, было бы поводом говорить о компетенции инженера.
Случаи бывают самые разные, далеко не всегда над развитием сети работает жирная проектная группа интегратора с большим именем, котоаиногда решение о дополнении принимается на уровне — типовое решение работало? работало, давайте поставим еще одну железяку и всё будет работать и дальше. А вот и нет, где-то чуть не хватает производительности, что-то не так прописали, на железяки Х обновили фирмварь, но не обновляли на железяки Y, здесь подключение сделали с чуть другими параметрами — и понеслось. Side-effects бывают волшебными и непредсказуемыми. «Щёлкнешь кобылу в нос — она махнет хвостом» (С) К.Прутков
Почему у некоторых инженеров даже без интеграторов не возникают проблемы с дизайном? И производительность железок не кончается ВНЕЗАПНО.
Сеть — единый живой организм, работать с ней надо системно, а не так как у вас написано («а давайте»).
А у нас в половине крупных операторов какие-то недоигравшие дети работают. Пичаль.
Сеть — единый живой организм, работать с ней надо системно, а не так как у вас написано («а давайте»).
А у нас в половине крупных операторов какие-то недоигравшие дети работают. Пичаль.
Случаи бывают самые разные, далеко не всегда над развитием сети работает жирная проектная группа интегратора с большим именем (которая может учесть многое, но не всё), а иногда решение о дополнении принимается на уровне — типовое решение работало? работало, давайте поставим еще одну железяку и всё будет работать и дальше. А вот и нет, где-то чуть не хватает производительности, что-то не так прописали, на железяке Х обновили фирмварь, но не обновляли на железяке Y, здесь подключение сделали с чуть другими параметрами — и понеслось. Side-effects бывают волшебными и непредсказуемыми. «Щёлкнешь кобылу в нос — она махнет хвостом» (С) К.Прутков
Sign up to leave a comment.
Как я решаю тикеты