Приветствую, и сперва немного лирики. Я иногда завидую коллегам, работающим удалённо — ведь это прекрасно иметь возможность работать из любого конца подключённого к Internet мира, каникулы в любое время, ответственность за проекты и дедлайны, а не нахождение в офисе с 8 до 17. Моя позиция и рабочие обязанности практически исключают возможность долгого отсутствия в датацентре. Однако — периодически случаются интересные кейсы, подобные описанному ниже — и я понимаю, что существует мало позиций, где есть такой простор для творческого выражения внутреннего troubleshooter'а.

В качестве предисловия: вчера представил приведенные ниже идеи на локальной сходке администраторов. После презентации ко мне подошел представитель компании, занимающейся производством сетевого оборудования и спросил: «Ты публиковал это где-то? Поделись презентацией, я отправлю коллегам посмотреть.» Собственно, а почему бы и не опубликовать? Как говорят у нас в Украине «i ми, Химко, люди». Если уж кто-то из вендоров, хотя бы отдаленно, но заинтересовался, то и в коммьюнити найдется человек, которому идеи тоже покажутся интересными. Кроме этого, я и сам планирую использовать это решение. Сразу скажу, что 100% готового результата не будет, но будет некий промежуточный, которого достаточно для эрзац-роутинга и немного информации для продолжения работ в данном направлении. Поехали!

Итак, не откладывая дело в долгий ящик, публикую вторую часть приведенного ранее поста. Выражаю благодарность за публикацию — приятно, что статья вас заинтересовала и тема нашла продолжение.

Напомню, что в прошлой части я остановился на том, что после перезагрузки одно из устройств VC не заработало должным образом. Как было справедливо замечено в одном из комментариев, получается, что я после всего этого пошел домой. Нет, первая часть описывает примерно 20 минут моей почти пятичасовой эпопеи. Пристегнулись? Поехали!

Поискав на Хабре, не нашел статью, освещающей данную тему в необходимом объеме, отсюда данный пост. Будет две части, так как для пробной статьи объема многовато.

Так как я здесь новичок, разрешите представиться: меня зовут Юра и на данный момент я работаю сетевым инженером в компании сервис-провайдере. За плечами преподавание в Сетевой Академии Cisco, достаточно плотное знакомство с нижней/средней линейкой их устройств и последние четыре года – с устройствами Juniper. Долгое время не мог собраться с мыслями по поводу данного поста, но в итоге жажда эпистолярного признания и желание помочь коллегам взяли вверх.

В качестве вступления могу сказать, что принцип обновления и приведенные выкладки справедливы для большинства (если не всех) устройств Juniper. В моем случае это два коммутатора EX4500, работающих в VirtualChassis (виртуальное шасси/VC). Сама технология VirtualChassis мною рассмотрена не будет, так как это раздует пост до неприличных размеров. Кроме этого, тема была рассмотрена ранее на Хабре здесь. Отмечу лишь, что она отдаленно напоминает VSS от Cisco: несколько физических устройств объединяются в одно логическое с общей панелью управления, конфигурацией, протоколами, таблицами и т.д. Не буду сильно занудствовать и размышлять о достоинствах/недостатках, реализации и прочих внутренних тонкостях – приведенное сравнение здесь больше как опорная метка, различия между VC и VSS большие, равно как и между Cisco IOS и JunOS.

Мой пациент – два физических коммутатора EX4500, объединенные в упомянутый VC (то есть, одно логическое устройство) и стоящие в ядре сети. Выше в сети стоят два независимых BGP маршрутизатора, каждый из которых подключен к своему физическому EX4500 («member» в виртуальном шасси) одним линком и высылает дефолтный маршрут, суммируя Full View таблицу. Ниже в сети – парк серверов с виртуалками и физическими серверами, которые используют VC как шлюз по-умолчанию. Исходная версия JunOS 11.1R3.5, аптайм – с установки, около 800 дней.