Так уж вышло, что последние 3 года я исключительно решаю проблемы пользователей. Не как эникейщик, на более высоком уровне, но это не меняет самого факта.
Проблемы бывают разные. Те, которые связаны с багами софта, железа или мозга клиента приходится локализовывать и передавать кому следует. Это не так интересно.
Гораздо интереснее заморочистые задачки.
Как то:
OSPF пиринг поднимается и падет через некоторое время.
Маршруты, полученные Route Reflector'ом по BGP не анонсируются клиентам.
Не работает Inter-AS Option C.
Это проблемы конфигурации, как правило. Я смотрю на формулировку запроса, понимаю, что я в этом абсолютно ничерта не смыслю, руки опускаются. Это нормальная ситуация, когда задача кажется огромной и не знаешь, с какой стороны к ней подойти.
Самое сложное — это взять телефон и позвонить заказчику. Он ведь заведомо опытнее меня, раз уж он это настраивал, а я ещё нет.
Ну давайте, в качестве иллюстрации возьмём какой-нибудь несложный тикет.
Не работает MPLS TE FastReroute (FRR). Это технология, которая позволяет переключиться трафику на другой путь в течение несольких миллисекунд, пока IGP не простроит новый маршрут.
Я не знаю, какой вопрос ему задать? Как понять суть проблемы, если я даже работу этого механизма ещё не представляю.
Это первый этап — беру документацию и начинаю курить. Что там у нас? Traffic engineering?? Ок :( 3-4 часа на чтение и вникание (ну тут нужно отметить, что это всё-таки не первое знакомство с темой — в общих чертах я знаком со всем).
Запрос с приоритетом Minor, поэтому я могу себе позволить такое расточительство по времени.
Когда поимел представление, уже можно позвонить заказчику и осторожно разузнать детали. Звонок — второй этап.
В этот момент он начинает сыпать терминами, рассказывать про свою сеть, о которой на данном этапе я ещё имею очень смутные представления. Если я в этой теме хоть сколько-то разбираюсь, задаю вопросы, наводящие меня и инженера на правильное русло.
Нужно не бояться показаться глупым. Я боюсь, но вопрос-то решать надо).
Когда проблема прояснилась, повторяю её инженеру так, как я понял и жду подтверждения, что я прав.
Тут кроется интерсная проблема: не все готовы меня слушать или понимать:
Одни перебивают и снова рассказывают своё видение, которое в целом совпадает с моим, но хотелось бы придерживаться правила двойного рукопожатия — 1) я понял его, 2) он понял, что я правильно понял.
Другие говорят: «Да, да, всё верно» и после этого объясняют что-то явно противоречащее. После уточняющих вопросов они снова говорят «Да» и опять объясняют всё иначе.
Тут важно не поддаться слабости и добиться полного понимания с обеих сторон, иначе я буду решать другую проблему или уйду в неверное русло.
В случае моего примера была вот такая схема:
И мне важно было понять, что FRR не работает именно между указанными двумя узлами, а внутри кольца вполне себе работает. После моих вопросов инженер подтвердил это.
В конце разговора, я прошу выслать какую-нибудь информацию мне (схему сети, диагностическую информацию, логи и т.д.).
Обязательно после звонка нужно написать письмо, где повторить свои мысли и просьбы. Потому что телефоный разговор — это телефонный разговор, а почта хоть как-то протоколируется и остаётся на экране инженера.
В противном случае он вообще забудет выслать или вышлет не всё.
Кроме того, это очень важно для сохранения истории запроса. Я мог бы вести экселевский файлик со всей информацией по тикету: когда писал, кому, что ответили, когда эскалировал или замораживал. Но у меня не хватает собранности — слишком много ему надо внимания.
Зато история переписки хранится годы. И если через 9 месяцев менеджер спросит меня, почему была такая задержка при решении, я открою архив и покажу, что запросил данные я 01.01.2013 в 00:20, а инженер мне ответил только 10.01.2013.
Но и тут опять есть место фейспалму. Пишешь в письме по пунктам, например:
В ответ приходит:
Во вложении один файл с диагностикой и всё. Что он полезного мне дал? Только понимание, что будет тяжело и надо снова ему звонить.
Слава IP, таких немного.
В примере инеженер оперативно выслал и конфигурацию, и схему, и желаемый алгоритм работы.
Итак, сейчас, у меня есть общее представление о проблеме, схеме сети и желаниях клиента.
Третий этап — более подробное вычитывание документации, примеров конфигурации. Поиск информации по теме в кейсах, которые писали другие инженеры для упрощения нашей жизни, и общая информация из гугла для общего развития и посмотреть, как это реализовано у других вендоров.
Обычно после этого возникают новые вопросы, повторяем итерацию со звонком и письмами, если нет удалёнки.
Часто на этом этапе проблема решается. Найдена ошибка в конфигурации или (надо признать, значительно реже) дыра в головном мозге инженера.
Но бывают и совсем сложные проблемы — настроено всё правильно, по всем данным, логам и статистикам всё в порядке, но проблема есть.
И вот тогда начинается TShoot — четвёртый этап.
Отлично, если есть удалёнка. Но иногда заказчики отвечают: «мы вам уже не в первый раз говорим — никакой удалёнки нет. Мы вам предоставили конфигурацию и диагностику.»
Помимо копаний в чужой консоли, подключаю программный симулятор оборудования.
Смотрю, как бегут пакеты, снимаю дампы, проверяю, на каком этапе сбоит протокол.
Если проблема фиксируется только на определённом оборудовании или версии софта, обращаюсь к реальной лабе с настоящим железом.
Случается, что для воспроизведения проблемы нужно задействовать восемь устройств, обновить на них софт, залить лицензии.
В примере явная зацепка — наличие деления OSPF на зоны. При этом у заказчика FRR работает нормально внутри зоны и не работает между Area 0 и 1
Тут включаю психологию — открываю аутлук и начинаю писать заказчику письмо с подробным объяснением того, что происходит и что я обнаружил. Расписываю всё словами, с выдержками из логов, конфигурации и вайршарка.
Описывая, я упираюсь в какой-то непонятный вопрос, который я не могу объяснить заказчику. Тогда я колупаю симуляцию дальше, читаю мануалы, пока не получится разрешить трудность. Описываю её и новый цикл.
В итоге письмо я часто не отправляю, но значительно приближаюсь к корню проблемы.
Логикой я понимаю, что CSPF (Constrained Shortest Path First) опирается в своей работе на алгоритм SPF, который, как известно работает только в пределах одной зоны. Про остальные зоны он знает только суммаризированые маршруты — не топологию. Соответственно, он не может простроить кратчайший end-to-end путь.
Эту схему я собрал, проверил, что всё действительно так. Нашёл в документации упоминание об этом и выслал заказчику.
Ну а потом:
Я: «выполните следующую команду: [R1]Make me feel good»
Заказчик:
Однако не всегда озвученный в тикете запрос — суть. Ответив «нет, так работать не будет» нужно предложить решение. И итерации по новой.
Решение по моему запросу: вместо FRR применять в рамках одного TE-туннеля два LSP — основной и резервный. Для этого строятся explicit-path в режиме loose. Это является end-to-end защитой между двумя узлами.
Вот парочка запросов, которые решались таким путём:
1) Не строятся новые LSP.
Примечение: до сегодняшнего утра всё работало и строилось. Старые LSP также функционируют и не флапают.
2) Через сеть MPLS организован L2VPN. Со стороны клиента не пропускаются пакеты размером более 1546 байтов.
3) Имеется сеть, по которой передаётся видео через мультикаст. При настройке VRRP на двух маршрутизаторах клиент, для которого они являются шлюзами, получает две копии видеотрафика (по одной с каждого маршрутизатора).
Проблемы бывают разные. Те, которые связаны с багами софта, железа или мозга клиента приходится локализовывать и передавать кому следует. Это не так интересно.
Гораздо интереснее заморочистые задачки.
Как то:
OSPF пиринг поднимается и падет через некоторое время.
Маршруты, полученные Route Reflector'ом по BGP не анонсируются клиентам.
Не работает Inter-AS Option C.
Это проблемы конфигурации, как правило. Я смотрю на формулировку запроса, понимаю, что я в этом абсолютно ничерта не смыслю, руки опускаются. Это нормальная ситуация, когда задача кажется огромной и не знаешь, с какой стороны к ней подойти.
Самое сложное — это взять телефон и позвонить заказчику. Он ведь заведомо опытнее меня, раз уж он это настраивал, а я ещё нет.
Ну давайте, в качестве иллюстрации возьмём какой-нибудь несложный тикет.
Не работает MPLS TE FastReroute (FRR). Это технология, которая позволяет переключиться трафику на другой путь в течение несольких миллисекунд, пока IGP не простроит новый маршрут.
Я не знаю, какой вопрос ему задать? Как понять суть проблемы, если я даже работу этого механизма ещё не представляю.
Это первый этап — беру документацию и начинаю курить. Что там у нас? Traffic engineering?? Ок :( 3-4 часа на чтение и вникание (ну тут нужно отметить, что это всё-таки не первое знакомство с темой — в общих чертах я знаком со всем).
Запрос с приоритетом Minor, поэтому я могу себе позволить такое расточительство по времени.
Когда поимел представление, уже можно позвонить заказчику и осторожно разузнать детали. Звонок — второй этап.
В этот момент он начинает сыпать терминами, рассказывать про свою сеть, о которой на данном этапе я ещё имею очень смутные представления. Если я в этой теме хоть сколько-то разбираюсь, задаю вопросы, наводящие меня и инженера на правильное русло.
Нужно не бояться показаться глупым. Я боюсь, но вопрос-то решать надо).
Когда проблема прояснилась, повторяю её инженеру так, как я понял и жду подтверждения, что я прав.
Тут кроется интерсная проблема: не все готовы меня слушать или понимать:
Одни перебивают и снова рассказывают своё видение, которое в целом совпадает с моим, но хотелось бы придерживаться правила двойного рукопожатия — 1) я понял его, 2) он понял, что я правильно понял.
Другие говорят: «Да, да, всё верно» и после этого объясняют что-то явно противоречащее. После уточняющих вопросов они снова говорят «Да» и опять объясняют всё иначе.
Тут важно не поддаться слабости и добиться полного понимания с обеих сторон, иначе я буду решать другую проблему или уйду в неверное русло.
В случае моего примера была вот такая схема:
И мне важно было понять, что FRR не работает именно между указанными двумя узлами, а внутри кольца вполне себе работает. После моих вопросов инженер подтвердил это.
В конце разговора, я прошу выслать какую-нибудь информацию мне (схему сети, диагностическую информацию, логи и т.д.).
Обязательно после звонка нужно написать письмо, где повторить свои мысли и просьбы. Потому что телефоный разговор — это телефонный разговор, а почта хоть как-то протоколируется и остаётся на экране инженера.
В противном случае он вообще забудет выслать или вышлет не всё.
Кроме того, это очень важно для сохранения истории запроса. Я мог бы вести экселевский файлик со всей информацией по тикету: когда писал, кому, что ответили, когда эскалировал или замораживал. Но у меня не хватает собранности — слишком много ему надо внимания.
Зато история переписки хранится годы. И если через 9 месяцев менеджер спросит меня, почему была такая задержка при решении, я открою архив и покажу, что запросил данные я 01.01.2013 в 00:20, а инженер мне ответил только 10.01.2013.
Но и тут опять есть место фейспалму. Пишешь в письме по пунктам, например:
1) Когда возникла проблема впервые? Производились ли перед этим какие-то изменения?
2) Предоставьте схему сети с указанием IP-адресов и интерфейсов
3) Вышлите файл логов с карты памяти
4) Вышлите диагностическую информацию.
5) Есть ли возможность удалённого доступа?
В ответ приходит:
Схему я описал вам по телефону: роутер-коммутатор-роутер2-коммутатор2-(STP)-клиент.
Во вложении один файл с диагностикой и всё. Что он полезного мне дал? Только понимание, что будет тяжело и надо снова ему звонить.
Слава IP, таких немного.
В примере инеженер оперативно выслал и конфигурацию, и схему, и желаемый алгоритм работы.
Итак, сейчас, у меня есть общее представление о проблеме, схеме сети и желаниях клиента.
Третий этап — более подробное вычитывание документации, примеров конфигурации. Поиск информации по теме в кейсах, которые писали другие инженеры для упрощения нашей жизни, и общая информация из гугла для общего развития и посмотреть, как это реализовано у других вендоров.
Обычно после этого возникают новые вопросы, повторяем итерацию со звонком и письмами, если нет удалёнки.
Часто на этом этапе проблема решается. Найдена ошибка в конфигурации или (надо признать, значительно реже) дыра в головном мозге инженера.
Что касается последнего пункта, яркий пример:
Я: «У вас одинаковые Router ID в OSPF»
Инженер: «Ну да, и что? Они же в разных зонах»
Я: «Router ID должны быть уникальны в пределах всего домена OSPF»
Инженер: «Да нет же. Конечно же, в разных Area могут быть одинаковые Router ID».
Я: Ссылка на документацию и википедию.
Инженер: «я проверю, но раньше я так делал — проблем не было».
Но бывают и совсем сложные проблемы — настроено всё правильно, по всем данным, логам и статистикам всё в порядке, но проблема есть.
И вот тогда начинается TShoot — четвёртый этап.
Отлично, если есть удалёнка. Но иногда заказчики отвечают: «мы вам уже не в первый раз говорим — никакой удалёнки нет. Мы вам предоставили конфигурацию и диагностику.»
Помимо копаний в чужой консоли, подключаю программный симулятор оборудования.
Смотрю, как бегут пакеты, снимаю дампы, проверяю, на каком этапе сбоит протокол.
Если проблема фиксируется только на определённом оборудовании или версии софта, обращаюсь к реальной лабе с настоящим железом.
Случается, что для воспроизведения проблемы нужно задействовать восемь устройств, обновить на них софт, залить лицензии.
В примере явная зацепка — наличие деления OSPF на зоны. При этом у заказчика FRR работает нормально внутри зоны и не работает между Area 0 и 1
Тут включаю психологию — открываю аутлук и начинаю писать заказчику письмо с подробным объяснением того, что происходит и что я обнаружил. Расписываю всё словами, с выдержками из логов, конфигурации и вайршарка.
Описывая, я упираюсь в какой-то непонятный вопрос, который я не могу объяснить заказчику. Тогда я колупаю симуляцию дальше, читаю мануалы, пока не получится разрешить трудность. Описываю её и новый цикл.
В итоге письмо я часто не отправляю, но значительно приближаюсь к корню проблемы.
Логикой я понимаю, что CSPF (Constrained Shortest Path First) опирается в своей работе на алгоритм SPF, который, как известно работает только в пределах одной зоны. Про остальные зоны он знает только суммаризированые маршруты — не топологию. Соответственно, он не может простроить кратчайший end-to-end путь.
Эту схему я собрал, проверил, что всё действительно так. Нашёл в документации упоминание об этом и выслал заказчику.
Ну а потом:
Я: «выполните следующую команду: [R1]Make me feel good»
Заказчик:
Однако не всегда озвученный в тикете запрос — суть. Ответив «нет, так работать не будет» нужно предложить решение. И итерации по новой.
Решение по моему запросу: вместо FRR применять в рамках одного TE-туннеля два LSP — основной и резервный. Для этого строятся explicit-path в режиме loose. Это является end-to-end защитой между двумя узлами.
Вот парочка запросов, которые решались таким путём:
1) Не строятся новые LSP.
Примечение: до сегодняшнего утра всё работало и строилось. Старые LSP также функционируют и не флапают.
2) Через сеть MPLS организован L2VPN. Со стороны клиента не пропускаются пакеты размером более 1546 байтов.
3) Имеется сеть, по которой передаётся видео через мультикаст. При настройке VRRP на двух маршрутизаторах клиент, для которого они являются шлюзами, получает две копии видеотрафика (по одной с каждого маршрутизатора).
